hackolade which diagram to use in NoSql(Mcd, Merise, UML)

nosql data modeling tools (2)

How you organize your project is an independent notion of the technology used for persistence; In particular; UML or ERD or any such tool doesn't particularly apply to relational databases any more than it does to document databases.

The idea that NoSQL has "No Joins" is both silly and unhelpful. It's totally correct that (most) document databases do not provide a join operator; but that just means that when you do need a join, you do it in the application code instead of the query language; The basic facts of organizing your project stay the same.

Another difference is that document databases make expressing some things easier, and other things harder. For example, it's often easier to an entity relationship constraint in a relational database, but it's easier to express an inheritance heirarchy in a document database. Both notions can be supported by both technologies, and you will certainly use them when your application needs them; regardless of the technology you end up using.

In short, you should design your application without first choosing a persistence technology. Once you've got a good idea what you want to persist, You may have a better idea of which technology is a better fit. It may be the case that what you really need is both, or you might need something totally different from either.

EDIT: The idea of a foreign key is no more magical than simply saying "This is a name of that kind of thing". It happens that many SQL databases provide some very terse and useful features for dealing with this sort of thing; specifically, constraints (This column references this other relation; so it cannot take a value unless there is a corresponding row in the referant), and cascades, (If the status of the referent changes, make the corresponding change to the reference). This does make it easy to keep data consistent even at the lowest level, since there's no way to tell the database to enter a state where the referent is missing.

The important thing to distinguish though, is that the idea of giving a database entity (A row in a relational database, document in document databases) is distinct from the notion of schema constraints. One of the nice things about document databases is that they can easily combine or reorient where data lives so that you don't always have to have a referant that actually exists; Most document databases use the document class as part of the key, and so you can still be sure that the key is meaningful, even if when the referent doesn't actually exist.

But most of the time, you actually do want the referent to exist; you don't want a blog post to have an author unless that author actually exists in your system. Just how well this is supported depends a lot on the particular document database; Some databases do provide triggers, or other tools, to enforce the integrity of the reference, but many others only provide some kind of transactional capability, which requires that the integrity be enforced in the application.

The point is; for most kinds of database, every value in the database has some kind of identifier; in a relational database, that's a triple of relation:column:key; and in a document database it's usually something like the pair document_class:path. When you need one entity to refer to another, you use whatever sort of key you need to identify that datum for that kind of database. Foreign Key constraints found in RDBMses are just (really useful) syntactic sugar for "if not referant exists then raise ForeignKeyError", which could be implemented with equal power in other ways, if that's helpful for your particular use.


again, sorry for my silly question, but it seems that what i've learned from Relation Database should be "erased", there is no joins, so how the hell will i draw use Merise and UML in NoSql?


this one will not work for NoSql?

unQL and Django?

it seems that NoSQL and SQL has made something between them called UnQL (Sqlite and CouchDB), maybe i dident understand the concept, but if that UnQL will be aviable, so Django will behave with him as what? as an SQL or as a NoSql?

Target of the UnQL specification is to offer the option/opportunity to implement open and unified querying language functionality among various NoSQL databases and their vendors. Queries in UnQL should be parsable to SQL in order to maintain some level of compatibility with RDBMS world.

since they said that the future release of Sqlite will have the UnQL support? and that concept is only restricted to CouchDB and not MongoDB?

The UnQL specification is in it's early stages and although there are already some prototype codes, it's probably 6-8 months away from some major implementation from the side of database vendors. So far the UnQL participants include SQLite, CouchDB (and probably also Couchbase), but I think as time will go on and the specification will take it's form, more vendors would join the effort to participate and support this unified querying language. Concept is not restricted since the specification is open, so it's up to the database vendors if they will support the UnQL.

will they add CouchDB options to Sqlite to call it UnQL since they say that Sqlite will have UnQL in the future?! what is that?

CouchDB has nothing to do with SQLite and vice versa. Whether CouchDB, SQLite, MongoDB or whatever database will implement UnQL in the future is entirely up to it's vendors/developers.