I'm writing an application in MeteorJS, which requires use of MongoDB. However, I'd really like to use an SQL database, as my data is highly relational, and I could make use of features like views.
I see that IBM has a Mongo wireline driver which natively emulates Mongo i.e. you can create a frontend that thinks it's communicating to a Mongo database, while in reality, it's being backed by an SQL database. This, to me, seems ideal, at least until Meteor supports a native relational backend.
Both DB2 and Informix have Mongo drivers, and my question is this: have any of you used the JSON and Mongo driver capabilities of either of these DBs and are there limitations or factors to consider? This is a greenfield project so there's no legacy database that needs to be supported.
I'd prefer to use DB2, as Informix appears to be a legacy product and I'm hesitant to start a brand new project with technology I'll have trouble finding trained staff for. Ironically, however, it seems that Informix has deeper support for JSON, including full two-way conversion of JSON to relational tables and back, indexing, etc. (even sharding and replication)
My reading of DB2 is that currently it only supports JSON as an additional JSON/BSON field into which all JSON data will go, but without automatic two-way access to the other relational columns. Is this correct? Anyone using DB2's JSON features?
I suspect in future versions, IBM will put better JSON support into DB2 (sort of how XML was gradually integrated), but I need something now. So my options for now, as I see them:
Use Informix with its better JSON support.
Use DB2 with less JSON support (unless I'm mistaken), and wait for
new versions
Use MongoDB for now and wait for Meteor to support a
relational DB
Any other options?
Related
After seeing this image:
http://2.bp.blogspot.com/_T-uXeKcGTnM/TIdoKBGwk9I/AAAAAAAABcs/CLW3_cRlN78/s1600/tumblr_kxovt0VLZy1qappj8.png
I wonder is exists any tool for translating SQL querys into MongoDB map/reduce query model??
Larger version of the image: http://rickosborne.org/download/SQL-to-MongoDB.pdf
Update to the question asked in Jan 2011:
A couple of sites exist now to convert sql to mongodb.
Convert MySQL Queries to MongoDB Syntax
http://www.querymongo.com/
And
Convert sql to mongodb
http://klaus.dk/sqltomongodb/
The simple anwser? No.
The slightly more complex anwser is some people have had luck translating more complex SQL to Mapreduce functions ...
http://rickosborne.org/blog/index.php/2010/02/08/playing-around-with-mongodb-and-mapreduce-functions/
http://rickosborne.org/blog/index.php/2010/02/19/yes-virginia-thats-automated-sql-to-mongodb-mapreduce/
However, that said ... generally speaking you might as well learn mapreduce properly because if the data is in MongoDB already ... you'll really need to know how to properly query MongoDB to get anything meaningful done!
MongoDB has wonderful and helpful docs http://www.mongodb.org/display/DOCS/Advanced+Queries
As well as an easy to use online tutorial: http://try.mongodb.org/
The simple answer: Yes. Hibernate OGM - JPA for NoSQL.
JPA is Java API for mapping objects to data stores.
It includes JPQL, a query language similar to SQL which adds the OOP concepts. It's not SQL, but you don't want pure SQL - that was designed for the relational paradigm.
Hibernate OGM proposes to simplify the programming model by embracing JPA/Hibernate APIs and semantics to store data in NoSQL stores like JBoss Enterprise Data Grid instead of the traditional RDBMS. (source)
Also see this Hibernate OGM: JPA for NoSQL talk by Hardy Ferentschik
Recently I happened to see this website mongoquery.com, you can try it.
You can use free sql to mongodb converter like: https://rapidapi.com/ariefsam/api/easy-sql-to-mongodb-aggregation/
Just to add to the last comment
re:The simple answer: Yes. Hibernate OGM - JPA for NoSQL.
JPA is Java API for mapping objects to data stores.
It includes JPQL, a query language similar to SQL which adds the OOP concepts. It's not SQL, but you don't want pure SQL - that was designed for the relational paradigm.
There is a company called UnityJDBC that has released a JDBC driver for Mongo that allows you to run SQL queries against mongo in any java application that supports JDBC.
you can download this driver free at
http://www.unityjdbc.com/mongojdbc/mongo_jdbc.php
hope this helps
You can also http://teiid.org which gives full range of SQL based access to MongoDB. You can use SQL through JDBC/ODBC or use REST/ODATA based access to MongoDB. Teiid uses MongoDB's aggregation framework to provide advanced SQL MongoDB query conversation.
I have a core data schema file with relationships between the entities.
I need to create a SQL database and would like to know if it can be created automatically (MySql or MS-SQL) using only this file.
Looking at the SQLite DB I see that the relationships are not mapped in any logical way.
First, your assessment that the relationships are "not mapped in any logical way" is not correct. If you look carefully at the Core Data generated database you will discover that the relationships are mapped exactly as in any other old relational database scheme, i.e. with foreign keys referring to rows in other tables.
Also, the naming conventions in these SQLite databases are very transparent (e.g., entity and attribute names start with Z, etc.
That being said, I would strongly discourage you to hack the Core Data generated database file, or even to use it to inform another database scheme, the reason being that these are undocumented features that could change any time without notice and thus break any code you write based on them.
IMO, the most practical thing to do is to rewrite the model quickly in the usual MySQL schema format and update it manually as well when you change the managed object model.
If you would like to automate the process, there is a rich set of APIs provided for interpreting and parsing NSManagedObjectModel, including classes like NSEntityDescription, NSAttributeDescription etc. You could write a framework that iterates though your entities and attributes and generates a text file that is a readable schema for MySQL, complete with information about indexing, versions etc..
If you go down that route, please make sure to notify us and do post your framework on Github for the benefit of others.
If you use Core Data you can create an SQL based database using a schema file but its structure is entirely controlled by the Core Data framework. Apple specifically tell us as developers to leave it alone and do not edit it using libsqlite or any other method. If you do then Core Data won't have anything to do with you!
In terms of making your own DB using one of Apple's schema files, I'm sure it is possible, but you'd have to know the inner workings of the Core Data framework to even attempt it.
In terms of making your own SQLite DB then you have to sort out all the relationships and mapping yourself.
I think that mixing and matching Core Data resources and custom built SQLite databases is probably a headache waiting to happen. I have used both methods and find that Core Data is brilliant (especially with iCloud) as long as you're OK with your App being limited to Apple only.
I am going to be writing to a MySQLite database file, using Perl's DBD:SQLite module, and I wondering if it is possible for this file to be read by any distribution of MySQL? Is there a better way to create a simple MySQL database (using Perl)?
If it means anything, I'm only going to be using the database to store key-value pairs based on unique ID numbers for the keys. I tried BerkeleyDB but there is little support for it on Perl and I could not get it to work correctly in the past on certain versions of Windows.
Edit: I am aware that BerkeleyDB is a better way to do this, but when I was writing scripts for it, most of the methods have TODO, and I've had mysterious bugs on Windows Server 2003 using the same airtight code that ran for 2 weeks straight on my Win7 machine at home.
MySQL and SQLite are completely separate RDBMS systems. There is no such thing as MySQLite. To the best of my knowledge, MySQL cannot read SQLite databases.
If all you really want is a key-value store, perhaps look at Redis: http://code.google.com/p/redis/
I use Perl's DBI module which I can use to read databases using either MySQL or SQLite. All you need is the correct driver. In fact, if you write your program correctly, the backend database (either SQLite or MySql) is irrelevant. Your program will work with either one.
However, you can't use a SQLite database and then treat it as a MySQL database. They're two different creatures. Your program can be database agnostic, but once you chose a database, you can't switch back and forth. It'd be like opening an Oracle database as a MySQL database.
See This posting on Perl Monks for more info.
BerkeleyDB is well supported by perl. You have a choice between the older DB_File and the more fully featured BerkeleyDB module.
But there are tons of choices. If you don't want to have to run a separate server process, use DBI and DBD::SQLite or BerkeleyDB or any of the AnyDBM_File modules. For a simple server-based key-value store, there's redis or the older memcached.
We're working on an ASP.NET web application with C# code behind. The database is MySQL 5.1 using InnoDB. The data access layer uses ADO.NET to call stored procedures and then builds various data structures out of the result sets (no object mapping). This works fine, but it is a little verbose.
Not surprisingly, we made some mistakes when designing the first version of our data model, but the experience has made us smarter and we decided to refactor the data model. We don't have to change our data access layer, but we are considering our options for that as well.
It's been difficult for us to ignore the popularity of ORM tools these days; we feel like we are way behind or something for not being familiar with them. Not only that, but we have already designed an object model that nicely describes our data model. The main ORM tools we would consider are NHibernate, ADO.NET Entity Framework, and LINQ to SQL. We would prefer LINQ to SQL because we have read (on S.O.) that it is more light weight than full ORM tools.
We think one drawback to using an ORM tool is the learning curve, but we can already see how using LINQ could reduce the amount of code we will have to write, which could save us time in the long run. However, we are using MySQL, not SQL Server.
So my question is, would DBLinq work well enough for a production system? Or, is LINQ to SQL a compeling enough reason for us to make the move to SQL Server 2008? Incedentally, I'd prefer to use SQL Server over MySQL, but cost is the obvious drawback. After 3 years on BizSpark, we'd be on the hook for $6K. Or, should we consider other ORM tools instead? Or, should we just ignore the hype and not use an ORM tool, but maybe take advantage of LINQ to DataSet?
I searched S.O. for info on DBLinq, but only found 17 questions with the DBLinq tag, so it doesn't appear to be popular.
EDIT
Looks at though dotConnect for MySQL has support for LINQ, so that's another option.
Can anyone speak to how well that driver works for writing LINQ queries?
Check bl-toolkit. It's free, very fast and has great LINQ support. Newest addition are T4 templates for generating your data model from database.
I am working on a business app (asp.net). Right now I am using sql server. But I plan to support at least mysql and postgresql down the road.
What are the issues that I should consider to avoid future headaches? Especially about datatypes (column types). E.g. I think BIT column is not supported on some dbs so I use tinyint?
I mostly use plain sql (no entity framework or linq, etc) and try to keep it as simple as I can.
I am NOT using things like triggers, etc.
I do use stored procedures but they can be replaced with plain sql if I have to.
Your only hope is to separate data access into a proper data access layer, as Remus Rusanu suggests. The data access layer can have one consistent interface to the rest of your code, and be changed out for other versions for each DB platform. Keeping the SQL fairly standard will help, but it's not really possible to write one body of SQL code and have it work everywhere (the SQL standard isn't that well implemented.)
Consider (with some costs in term of learning curve) the adoption of a Domain Model and a data access layer based on an OR/M like NHibernate (https://www.hibernate.org/343.html)
Make sure you write all your client code using the abstract IDbConnection, IDbCommand, IDataReader instead of the concrete. You will also have to keep your SQL statements in check all the time to ensure you use only compatible syntax.
You can also try connecting via the OdbcConnection/OdbcCommand components and use generic ODBC syntax and generic ODBC data types (ie. the {fn SUBSTRING(...)} stuff, aka. the ODBC Escaped Syntax).
As an alternative what I prefer to do is to isolate the data access and create specific DAL classes for each back end. I use XML and XSLT to generate the DAL code. Similar to this the technique of integrating XSLT code generation from my blog, but with XSLTs geared specifically for each back-end specific code.