When I wrote Angela, I'd designed it to use object databases; so I was a NoSQL early adopter. Then when I started working on Magic Epoch, I was using the Google App Engine, which is also a NoSQL environment. Certain things were just more difficult in a NoSQL environment; though there is no need for any ORM business. The last straw was seeing that certain operations would be very expensive to run on the GAE. So now I'm moving in the opposite direction of the herd; towards SQL.
Would you please share which "Certain things were more difficult in a NoSQL environment"? Since i've move from MySQL to a NoSQL db such as MongoDB, i've found certainly more easy to read and write operations in it, and having the ability to store JSON like objects its the biggest perk i've found vs MySQL.
NoSQL isn't right for every project. Anything that needs to do a lot of analyzing, such as business intelligence applications, are not a good fit for object databases. But for me at least, 95% of the work that I do seems to benefit a lot with MongoDB so far. If you just need to store, retrieve and update things in a fast manner and do a bit of light reporting (like the reporting required for a typical web game), it seems to work really well.
Considering that "NoSQL" is just a catch-all phrase for pretty much all databases that aren't SQL, which one were you using?
I guess what I'm wondering as I'm following this, what is the difference between the two other than different ways of using a DB?
I have always used mySQL and have found it useful. One can use it for calculations, retrieving, storing, etc. All through the SQL commands which I know fairly well.
Instead of SQL and NoSQL let's say Relational and Document based, as those are the 2 approach for me. It doesn't matter much the "language" you need to use to query data or store data. Relational database are what people call SQL databases. Document based databases are like MongoDB. I say documents as some of those have clues of what kind of data you store, some don't.
Relational database:
The database must know the structure of the data you will store, you need to define "tables" or "objects" (yes oracle for example can store objects and not simply rows inside a table), and those tables or objects can have links between them (inside the same table / object or toward other tables / objects). Those are typically called foreign keys for example. The advantage of this approach is it tends to improve the consistency of the data, for example, if I delete a user I would either want to delete all the linked data like the preferences of the user and his/her orders or prevent to delete till all the other tables are cleaned as well. You can also give constraints such that some values need to be within a range or a selection, or that you cannot have duplicates of some sorts. Finally, some databases engine can offers stored procedures or functions to extend the capabilities of the databases to understand and work with your data, and therefore extend their dialect with your own defined features or checks.
Those databases are also masters of making complex queries and make what we call data mining, for example, imagine a log table where you log all the information about page loads, it could be interesting to see how many different IP you had on a given day, and what sort of browser they used, well, with a query it is possible to extract it saying that an IP loaded X time a page or there is Y different browsers.
Drawbacks are that your structure should be well defined, and should not be modified (you can but it should be avoided ideally). Having a complex object stored inside the database can be tricky. Therefore the development time linked to the database can be higher than with a document database.
Document based
Document based approach usually work on a "simple" key => value pair. Each document is linked to a single key, where the key is a unique ID you can define or the DB will generate for you. What you store as value can be completely free or defined by a "schema" (think about it like a template document). However usually the understanding of the document is not a main task of this kind of storage. Think that you can store basically anything as long as you have a key to retrieve it.
The advantage of such database is that you can have different contents for each different documents, and therefore store different kind of data, or have more or less complex objects inside the same dataset. If you just want to store JSON or any other object serialization and be able to retrieve it knowing its key, then this is the best tool.
However as the database doesn't have a good or any understanding of what you store, it may be impossible to have data mining operations made directly by the database. So you may not be able to group your values. Also links between documents are basically not possible as normally documents are independent entities, so you will need to code it if you want such feature.
Conclusion (my conclusion)
Both approach have their pro and cons, it pretty much depends what you need to do for a given project. I usually use relational databases (Oracle at work), while for cubicverse MongoDB is certainly the way to go.
Creator of Dot World Maker
Mad programmer and annoying composer
My problems with NoSQL: Reference Tracking , aggregation (I’m a BI guy in my day job and aggregation is valuable to me)and one more thing… multiple membership.
Let me give an example from magicus occultus. It uses object assemblies, instead of atomic objects. So a man is wearing a helmet, welded to a castle gate.
Now if I look at the man, I can say that he’s wearing the helmet.
If I look at the castle, it’s a lot bigger than the door, so the door is “part of the castle”.
From the perspective of the door, the helmet is part of the door.
So if I can nest objects, I can add an object as an attribute of another object. It cen be a member of a single object! This means that if I want to be able to shift my perspective, then I need a hashmap/dictionary object for tracking pairings. If I link objects this way, I’ve just implemented a hackish bridge table. Yay!
I've never used MongoDB, which seems to the the standard. I have used the GAE datastore (and MondoDB's API reminds me a LOT of that) and ZDB; which 5 or so years ago was what people thought of when they said object database (the old term for NoSQL).
Cayle wrote:My problems with NoSQL: Reference Tracking , aggregation (I’m a BI guy in my day job and aggregation is valuable to me)and one more thing… multiple membership.
OK, right there I am with you. I remember when I was first learning MongoDB and falling in love with it, something kept saying in the back of my head "As great as this is, this would utterly stink for complex reporting".
I would not totally write it off for games and websites, though, which is where it really shines.
And A_betrand:
Yes, the namings of "NoSQL" and "SQL" are kind of irritating. Of course the latter is called "relational", but people have started calling all SQL and SQL-like using dbs simply "SQL" in opposition to "NoSQL", which is kind of a goofy name to begin with. How many other things are named after what they are not? Trains aren't called "NoPlanes". Cats aren't called "NoDogs", etc. But I am also guilty of boiling it down into those names since that is the common parlance of the day
But I am also guilty of boiling it down into those names since that is the common parlance of the day 