I'm in need for an embedded database for a Clojure application. Maybe it's the same criteria as for any other Java application but I rather get some other people's opinion anyway. I'm not picking SQLite because that's not pure Java so distribution of a standalone application gets much more complex. It seems the way to go is Apache Derby. Anything else I should consider?
Without a doubt, H2
Here are the settings,
(def demo-settings
{
:classname "org.h2.Driver"
:subprotocol "h2:file"
:subname (str (System/getProperty "user.dir") "/" "demo")
:user "sa"
:password ""
}
)
And then the usual Clojure SQL code:
(with-connection demo-settings
(create-table :DEMO_TABLE
[:M_LABEL "varchar(120)"]
[:M_DATE "varchar(120)"]
[:M_COMMENT "varchar(32)"]))
Have you looked at FleetDB? It's a Clojure database with a JSON protocol and clients in several languages. I suspect you could probably run it embedded without working too hard at it.
h2
oracle Berkley DB
I used an embedded database, H2 within clojure and used clojureQL to access it. Be warned though that since the database is in process you should not use this for large amounts of records (> than 10,000s in a single table) as you will get huge performance problems as the database and your code will both be sharing the same JVM
I think Derby makes an excellent 100% Java embedded database, and it's useful for a wide variety of applications, well-maintained by an active community, and very well documented.
If you don't mind NOSQL, neo4j is an embeddable graph db with transactions, licensed under the GPL. The most up to date bindings I've found are https://github.com/hgavin/borneo
There is also an interesting graph db project in clojure with pluggable backends: https://github.com/flatland/jiraph
The still quite young but promising looking OrientDB might be worth a look: http://www.orientechnologies.com/orient-db.htm
http://github.com/eduardoejp/clj-orient
Then there's http://jdbm.sourceforge.net/
I am using https://github.com/clojurewerkz/archimedes which allows you to specify a backend later.
Another option to consider is a key-value store Chronicle Map, because it's pure Java and provides a vanilla Java Map interface, so working with it should be very simple using Clojure.
Related
I'm looking for a Flutter NoSQL persistence DB with basic query system.
I found sembast
I would like to know alternatives or better solutions
Sembast would be my top recommendation. It's maintained by tekartik who also maintains the excellent SQFLite package. Sembast is also the most popular embedded NoSQL database on Pub right now (other than Firebase options).
I've trusted tekartik many times in the past with SQFLite among others, he's prompt, polite and incredibly helpful, even with new coders.
Have you tried objectdb? "Persistent embedded document-oriented NoSQL database for Dart and Flutter".
I have worked with ObjectBox in Android development before and they also have APIs for Flutter. It was pretty fast and reliable. Also, have a look at Hive.
I use Hive. It's fast, easy to use and has code generation facilities that work fine with json_serializable and freezed.
I've been searching on how to make a database in J2ME for S40 development, but it seems that Derby is too complicated and RMS doesn't have the capabilities of adding other columns and rows...
I just want to know if there's anything like SQLite for S40 development.
Or if there's a tutorial on how to use the Database component in the Visual Midlet for S40 development. because I don't know how to use it, and I really need to make a database for my application.
btw, I can't get rid of the database and use file communication because it's slow and complicated as well.
Thank you very much in advance :)
SQLite is not supported on Series40. In fact, I am not aware of any SQL databases that is available for Series40. RMS is your best option at this time. I can recommend using an object persistence framework such as Floggy for easier development with RMS.
SQLite never support with Java ME. Look at List of database framework for Java ME development. But I suggest don't use 3rd party database for S40. Because most of the s40 mobiles having small amount of heap memory (not more than 2 MB). So better way, Go with RMS.
I have a project for a class which requires that if a database is used, options exist for the user to pick a database to use which could be of a different type. So while I can use e.g. MySQL for development, in the final version of the project, the user must be able to choose a database (Oracle, MySQL, SQLite, etc.) upon installation. What's the easiest way to go about this, if there is an easy way?
The language used is up to me as long as it's supported by the department's Linux machines, so it could be Java, PHP, Perl, etc. I've been researching and found info on ODBC, JDBC, and SQLJ (such as this) but I'm quite new to databases so I'm having a hard time figuring out what would be best for my needs. It's also possible there may not be a simple enough way to do this; the professor admitted he's not a database guy either and he seemed to think it would be easy without having a clear idea of what it would take.
This is for a web app, but it ought to be fairly straight forward, using for example HTML and Javascript on the client side and Java with a MySQL database on the server side. No mention has been made of frameworks so I think they're too much. I have the option of using Tomcat or Apache if necessary but the overall idea is to keep things simple, and everything used should be able to be installed/changed/configured with just user level access. So something like having to recompile PHP to use ODBC would be out, I think.
Within these limitations, what would be the best way (if any) to be able to interact with an arbitrary database?
The issue I think you will have here is that SQL is not truely standard. What I mean is that vendors (Oracle, MySQL etc) have included types and features that are not SQL standard in order to "tie you in" to their DB, such as Oracle's VARCHAR2 and so on.
When I was at university, my final year project was to create an application that allowed users to create relational databases using JDBC with a Java front-end.
The use of JDBC was very simple but the issue was finding enough SQL features/types that all the vendors have in common. So they could switch between them without any issues. A way round this is to implement modules to deal with vendor specific issues and write ways to translate between them. So for example you may develop a database for MySQL with lots of MySQL specific code in that, but then you may want to use Oracle and then there are issues, which you would need to resolve.
I would spend some time looking at what core SQL standard all the vendors implement and then code for these features. But I think the technology you use wouldn't be the issue but rather the SQL you create.
Hope this helps, apologies if its not helpful!
Well, you can go two ways (in Java):
You can develop your own classes to work with different databases and load their drivers in JDBC. This way you will create a data access layer for yourself, which takes some time.
You can use Hibernate (or other ORMs). This way Hibernate will take care of things for you and you only have to know how to use Hibernate. Learning Hibernate may take some time, but when you get used to it, it can be very useful for your future projects.
If you want to stick Java there Hibernate (which wouldn't require a framework). Hibernate is fairly easy to use. You write HQL which gets translated to the SQL needed for the database you're using.
Maybe use an object relational mapper (ORM) or database abstraction layer (DAL). They are designed to provide a standard API to multiple database backends, making it possible to switch between different backends with minimal or no changes to your code. In Python, for example, a popular ORM is SQLAlchemy, and an excellent DAL is the web2py DAL (it's part of the web2py framework but can be used as a standalone DAL outside the framework as well). There are many other options in other languages as well.
use a framework with database abstraction layer and orm . try symfony or rails
There are a lot of Object relational database frameworks, unless you prefer jdbc. For simple/small applications this should work fine.
I'm using Squeak4.1. How does it handle Database connections? Does it provides something similar to ODBC/ADO in .NET or the J2EE stuff?
Which packages deal with database operations?
Can anybody give me some hints?
Few links that might be of use to you:
Squeak Smalltalk and Databases
SqueakDBX
Persistence in Seaside (Also see Chapter 8 in the Seaside tutorial)
Magma
Databases and Persistence
Squeak PostreSQL
If you want something that's truly an analog to ODBC/JDBC or ADO.NET, then the closest analog would be SqueakDBX, a generic, FFI-based connector to a wide variety of databases. While it uses FFI, the developers have gone to great lengths to ensure that long operations do not block the VM. While I can't honestly say I've used it in production, reviews have been positive, it supports a very wide variety of databases (MySQL, Microsoft SQL Server, PostgreSQL, SQLite3, and more), and it's being actively developed, so it's probably a good bet.
Historically, the downside of SqueakDBX is that you didn't get GLORP, the major ORM used in the Smalltalk world these days. The good news is that's no longer true: SqueakDBX now has GlorpDBX, which brings GLORP to SqueakDBX. Drivers are currently available for PostgreSQL, MS SQL, and MySQL, among others. If you need to connect to a traditional database, this is probably your best bet.
Benjamin: We have already started to modify Glorp, we call it GlorpDBX and now Glorp works with a generic database driver, included a GlorpSqueakDBX driver. Right now we have GlorpDBX working with SqueakDBX for Postgres, MSSQL and Oracle.
Cheers
You might not need to. If your smalltalk code runs in Gemstone, there is no need to worry about database connections and queries before you have a lot of data/a lot of transactions.
And if the number of objects is very small, SandstoneDB is much easier to use. On the Persistence in Seaside page you can find the links.
With the rising of non-sql database usage in high traffic website, I'm interested to use it for my project. Now I've heard several names like Voldermort, MongoDB and CouchDB. But which are among these NonSQL database that is production ready? I've seen the download pages and it seems that none of them is production ready because is not version 1.0 yet. Is there any other names other than these 3 that is recommendable to be used in production?
What do you mean by production ready? As far as I know, all of them are being used on live systems.
You should make your choice based on how the features they provide fit your needs.
You can also add Tokyo Cabinet to the list as well as the mnesia database provided by the Erlang VM.
I think you need to start out from your project requirements to see what kind of database you really need. There are many non-relational DBMS:s out there and they differ a lot in what kind of problems they are good at solving. I think the article Should you go Beyond Relational Databases? by Martin Kleppmann is a good starting point for finding out what you need. There's also a lot of stackoverflow threads on similar topics, these are my favorites:
The Next-gen Databases
Non-Relational Database Design
When shouldn’t you use a relational
database?
Good reasons NOT to use a relational
database?
When you have narrowed down what you actually need you can take a deeper look into the alternatives to see which DBMS are production ready for your use case. Production readiness isn't a yes/no thing: people may successfully deploy some solution that for example lacks in tool support - in another project this could be a no-go.
As for version numbers different projects have a different take on this, so you can't just compare the version numbers. I'm involved in the graph database project Neo4j and even if it has been in production use for 5+ years by now we still haven't released a version 1.0 final yet.
I'm tempted to answer "use SIRA_PRISE".
It's definitely non-SQL.
And its current version is 1.2, meaning that someone like you must definitely assume it's "production-ready".
But perhaps I shouldn't be answering at all.
Nice article comparing rdbms with 'next gen' and listing some providers:
Is the Relational Database Doomed?
http://readwrite.com/2009/02/12/is-the-relational-database-doomed
I will suggest you to use Arangodb.
ArangoDB is a multi-model mostly-memory database with a flexible data model for documents and graphs. It is designed as a “general purpose database”, offering all the features you typically need for modern web applications.
ArangoDB is supposed to grow with the application—the project may start as a simple single-server prototype, nothing you couldn’t do with a relational database equally well. After some time, some geo-location features are needed and a shopping cart requires transactions. ArangoDB’s graph data model is useful for the recommendation system. The smartphone app needs a lean API to the back-end—this is where Foxx, ArangoDB’s integrated Javascript application framework, comes into play.
Another unique feature is ArangoDB’s query language AQL — it makes querying powerful and convenient. AQL enables you to describe complex filter conditions and joins in a readable format, much in the same way as SQL.
You can model your data in several ways:
in key/value pairs
as collections of documents
as graphs with nodes, edges, and properties for both
You can access data in ArangoDB:
using the general HTTP REST API via curl/wget, or your browser
via the ArangoDB shell (“arangosh”)
using a programming language specific client library
Server requirements for ArangoDB:
ArangoDB runs on Linux, OS X and Microsoft Windows.
It runs on 32bit and 64bit systems, though using a 32bit system will limit you to using only approximately 2 to 3 GB of data with ArangoDB.