From what I understand, some proponents of NoSQL are even more minimalist than that--they are fine with the idea of relations, just not with storing them in a traditional RDBMS (e.g. MySQL, Postgres, Oracle, etc). The most convincing argument that I see for this is traditional RDBMSs are all row-oriented and organized via relational theory, and that a lot of data is better stored and/or manipulated via column-oriented, or graph theory, or object oriented systems.
From what I understand, some proponents of NoSQL are even more minimalist than that--they are fine with the idea of relations, just not with storing them in a traditional RDBMS
I don't know about this. I would never use the word NoSQL... but I use object databases heavily and find them a better fit than relational databases for the majority of my work. However, I still store the physical data in a relational database. (Key => value.)
This is beneficial in a number of ways. You already know how to administer MySQL, you already know how to replicate MySQL, you already know how to back up MySQL, etc. This method also affords you the opportunity to reuse the database machinery in your application. You can extract attributes from objects as you store them, and later index/search them with the usual database querying infrastructure. The database does not know everything about the objects you are storing, it just knows a few key facts that you know you want to search on, so you can write efficient searches, but you are not limited by the usual relational weaknesses. (The "object-ness" is stored in a structure opaque to the database engine, like a JSON blob or something.)
As an example, consider cleaning out dead user objects that have not confirmed their email address after a certain number of days. If you were only using an object database, you would maintain a set of users to potentially expire. When they confirm their email address, you remove them from this set. Fine. The problem is the date constraint; you don't really want to scan the entire set of potentially-expireable users to expire users, you would like to be able to search for these objects efficiently.
That's easy to fix; when you store a user object, you can extract the confirmation status and registration date from the object and store those in real columns next to the opaque object data. Then you can "SELECT object_id FROM objects WHERE registration_date < NOW - 30 days AND confirmed_email IS NULL" and remove those objects from your system. Efficient, and it works as you change the structure of the user object, or add subclasses, etc.
I work with objectstore nearly everyday and wish we were using oracle or db2. I am firmly convinced that you better have a damn good reason (like a big heavily updated graph structure) to forgo the discipline of a normalized relational schema.
Use objects in memory. I'm just saying the relational <-> object mapping is a necessary evil because in the long run with complex data you'll suffer for your sin of skipping normalization.
The row orientation of a sql database is a significant limitation for sufficiently deep datastructures IMO. They often force you into multiple calls for a single entity or complicated loops through really long rows. All of which can be the cause of wasted cycles in code. A sql db with its rows presents a poor datamodel for those cases.
You are confusing SQL with "necessitates row ortientation", even tho column databases frequently use SQL for queries. This is essentially why I originally asked -- SQL and relational data does not require what you describe, it has just been the traditional approach to implementing it.
I think when zaphar said "sql database" he was just using common usage for RDBMS. Yes, "SQL database" does not have to mean "row oriented storage". But all of the commonly familiar SQL RDBMSs use row oriented storage.
I actually think SQL the language assumes row oriented storage. I honestly can't think of a single SQL database that isn't row oriented. While theoretically you could, in practice no one has.
I can't say for certain but this might be related to the reliance on sql for the query language.
Relational theory only requires row orientation at a conceptual level, and not even that -- a row is just a set with a key and potentially a relationship with another set. At a lower level than the relational algebra much data is better kept in columns or graphs, as you mention. This is why I ask my question, the data is conceptually relational (all data is pretty much by definition of relational...) but access patterns dictate a non-row orientation.
Comments
From what I understand, some proponents of NoSQL are even more minimalist than that--they are fine with the idea of relations, just not with storing them in a traditional RDBMS (e.g. MySQL, Postgres, Oracle, etc). The most convincing argument that I see for this is traditional RDBMSs are all row-oriented and organized via relational theory, and that a lot of data is better stored and/or manipulated via column-oriented, or graph theory, or object oriented systems.
From what I understand, some proponents of NoSQL are even more minimalist than that--they are fine with the idea of relations, just not with storing them in a traditional RDBMS
I don't know about this. I would never use the word NoSQL... but I use object databases heavily and find them a better fit than relational databases for the majority of my work. However, I still store the physical data in a relational database. (Key => value.)
This is beneficial in a number of ways. You already know how to administer MySQL, you already know how to replicate MySQL, you already know how to back up MySQL, etc. This method also affords you the opportunity to reuse the database machinery in your application. You can extract attributes from objects as you store them, and later index/search them with the usual database querying infrastructure. The database does not know everything about the objects you are storing, it just knows a few key facts that you know you want to search on, so you can write efficient searches, but you are not limited by the usual relational weaknesses. (The "object-ness" is stored in a structure opaque to the database engine, like a JSON blob or something.)
As an example, consider cleaning out dead user objects that have not confirmed their email address after a certain number of days. If you were only using an object database, you would maintain a set of users to potentially expire. When they confirm their email address, you remove them from this set. Fine. The problem is the date constraint; you don't really want to scan the entire set of potentially-expireable users to expire users, you would like to be able to search for these objects efficiently.
That's easy to fix; when you store a user object, you can extract the confirmation status and registration date from the object and store those in real columns next to the opaque object data. Then you can "SELECT object_id FROM objects WHERE registration_date < NOW - 30 days AND confirmed_email IS NULL" and remove those objects from your system. Efficient, and it works as you change the structure of the user object, or add subclasses, etc.
I work with objectstore nearly everyday and wish we were using oracle or db2. I am firmly convinced that you better have a damn good reason (like a big heavily updated graph structure) to forgo the discipline of a normalized relational schema.
If you can't do it with objects, what structure do you use in-memory?
Use objects in memory. I'm just saying the relational <-> object mapping is a necessary evil because in the long run with complex data you'll suffer for your sin of skipping normalization.
The row orientation of a sql database is a significant limitation for sufficiently deep datastructures IMO. They often force you into multiple calls for a single entity or complicated loops through really long rows. All of which can be the cause of wasted cycles in code. A sql db with its rows presents a poor datamodel for those cases.
You are confusing SQL with "necessitates row ortientation", even tho column databases frequently use SQL for queries. This is essentially why I originally asked -- SQL and relational data does not require what you describe, it has just been the traditional approach to implementing it.
I think when zaphar said "sql database" he was just using common usage for RDBMS. Yes, "SQL database" does not have to mean "row oriented storage". But all of the commonly familiar SQL RDBMSs use row oriented storage.
I actually think SQL the language assumes row oriented storage. I honestly can't think of a single SQL database that isn't row oriented. While theoretically you could, in practice no one has.
I can't say for certain but this might be related to the reliance on sql for the query language.
Relational theory only requires row orientation at a conceptual level, and not even that -- a row is just a set with a key and potentially a relationship with another set. At a lower level than the relational algebra much data is better kept in columns or graphs, as you mention. This is why I ask my question, the data is conceptually relational (all data is pretty much by definition of relational...) but access patterns dictate a non-row orientation.