NoSQL Best Practices

Question

What are the best practices for working with NoSQL, OODB, or any other abbreviations for them?

For example, I often saw that the type field is used to determine how the database document (in terms of couchDB / mongoDB) should be interpreted by the client, the application.

Where applicable, use PHP as your reference language. Read: I am also interested in how such data is best processed on the client side, and not just strictly the database structure. This means that I am also looking for patterns like "ORM" for SQL DB (active record, dataperper, etc.).

Feel free to make statements about how such a database and the new features of PHP 5.3 could best work together.

Answer 1

I think that at present, the whole idea of ​​NoSQL data storage and the concept of document databases are so new and different from established ideas that lead to relational storage, that currently there are very few (if any) best practices.

At this point, we know that the rules for storing your data inside say CouchDB (or any other document database) are quite different from the rules for relational. For example, it is almost a fact that normalization and focus on 3NF is not something to strive for. One common example is a simple blog.

In the relational store you will have a table for "Messages", "Comments" and "Authors". Each author will have many posts, and each post will have many comments. This is a model that works well enough and displays any relational database well. However, storing the same data in docDB is likely to be very different. You probably have something like a collection of Post-documents, each of which will have its own Author and a collection of comments embedded in it. Of course, this is probably not the only way to do this, but rather a compromise (now the request for one message is fast - you perform only one operation and return everything), but you have no way to maintain relations between authors and messages (since all this becomes part of the mail document).

I also saw examples using the "type" attribute (in the CouchDB example). Of course, this sounds like a viable approach. This is the best? I have no clue. Of course, in MongoDB you have to use separate collections in the database, which makes the type attribute completely meaningless. In CouchDB, though ... perhaps this is the best. Other alternatives? Separate databases for each type of document? It seems a bit fixated, so I lean toward the “type” on my own. But it's just me. Perhaps there is something better.

I understand that I chatted a bit here and said very little, most likely you did not know anything. I believe that this is - I think we need to experiment with the tools that we have, and with the data we work with, and over time, good ideas will spread and become best practices. I just think you ask too early in the game.

Answer 2

"NoSQL" should be more involved in building a data warehouse so that it meets your application requirements, rather than how the application should follow a certain structure - this is more like the traditional SQL approach.

Do not leave the relational database "just because"; just do it if your application really needs.