3 ms·

Polyglot Persistence

25 points by cdl 14y ago

taligent 14y ago
What's interesting is how much of this can be traced back to one simple word: agile. As software development has moved to very short release cycles the importance of a fluid persistence approach is paramount. Gone are the days of fixed ER diagrams, DDLs and migration scripts for many small to medium and even large projects. Likewise having to wait for a DBA/Ops team to make changes on your behalf is never going to work. There just isn't the time for all of this when you are releasing to production every two weeks. The databases that can best adapt to these conditions will be the ones that do well in the future.
- nahname 14y ago
  Most of the problems you define are organizational. The one that isn't (migrations) actually has the best support on relational databases because their tooling is much more mature. Just try to lookup recommended migration strategies for neo4j.
- nateberkopec 14y ago
  Maybe. Fowler has been interested in NoSQL for a long time (in his Patterns of Enterprise Architecture, he called it 'Object-Oriented Databases'). I think a lot of his interest is in how NoSQL makes it easier to persist certain object models that would be difficult to persist relationally (entity-attribute-value for one).
  - zzzeek 14y ago
    > he called it 'Object-Oriented Databases' IMHO I disagree that this phrase is relevant to NoSQL. The systems he refers to (I'm looking on page 37) are specifically object databases (OODBMS). While in the strict sense, an OODBMS doesn't use SQL and could be referred to as "no SQL", they are not what people are normally talking about when they talk about NoSQL. To be fair, I checked Wikipedia on NoSQL and they do list object databases underneath the taxonomy, however OODBMS conflicts with the Wikipedia description of NoSQL: > In short, NoSQL database management systems are useful when working with a huge quantity of data and the data's nature does not require a relational model for the data structure. The data could be structured, but it is of minimal importance and what really matters is the ability to store and retrieve great quantities of data, and not the relationships between the elements This refers to what we usually talk about as the main advantage of NoSQL databases which is that they are nearly or completely schemaless. The notion that fields can be added/removed and new kinds of structures and sub-structures can be added at will without any impact to existing data is pretty much one of the key advantages offered by NoSQL. With an OODBMS, the situation is totally the opposite. The database is completely hardwired to the structure of your objects, as they are stored in some quasi- or actually-serialized format. In contrast to Wikipedia's phrase, in an OODBMS, the structure of the data and the relationships between the elements is of maximal importance. From Fowler: > With an OO database you dont have to worry about mapping. You work with a large structure of interconnected objects. You might call this NoSQL in the strictest sense, but in practice NoSQL strongly implies "nearly/completely schemaless". With a "schemaless" database, you totally have to worry about mapping your objects, as an OO domain model looks nothing like the key/value cassandra/mongo-esque models we talk about in NoSQL. Schemaless systems certainly have existed for decades but that's IMHO not what Fowler refers to here.

25 points by cdl 14y ago

What's interesting is how much of this can be traced back to one simple word: agile. As software development has moved to very short release cycles the importance of a fluid persistence approach is paramount. Gone are the days of fixed ER diagrams, DDLs and migration scripts for many small to medium and even large projects. Likewise having to wait for a DBA/Ops team to make changes on your behalf is never going to work. There just isn't the time for all of this when you are releasing to production every two weeks. The databases that can best adapt to these conditions will be the ones that do well in the future.

nahname 14y ago
Most of the problems you define are organizational. The one that isn't (migrations) actually has the best support on relational databases because their tooling is much more mature. Just try to lookup recommended migration strategies for neo4j.
nateberkopec 14y ago
Maybe. Fowler has been interested in NoSQL for a long time (in his Patterns of Enterprise Architecture, he called it 'Object-Oriented Databases'). I think a lot of his interest is in how NoSQL makes it easier to persist certain object models that would be difficult to persist relationally (entity-attribute-value for one).
- zzzeek 14y ago
  > he called it 'Object-Oriented Databases' IMHO I disagree that this phrase is relevant to NoSQL. The systems he refers to (I'm looking on page 37) are specifically object databases (OODBMS). While in the strict sense, an OODBMS doesn't use SQL and could be referred to as "no SQL", they are not what people are normally talking about when they talk about NoSQL. To be fair, I checked Wikipedia on NoSQL and they do list object databases underneath the taxonomy, however OODBMS conflicts with the Wikipedia description of NoSQL: > In short, NoSQL database management systems are useful when working with a huge quantity of data and the data's nature does not require a relational model for the data structure. The data could be structured, but it is of minimal importance and what really matters is the ability to store and retrieve great quantities of data, and not the relationships between the elements This refers to what we usually talk about as the main advantage of NoSQL databases which is that they are nearly or completely schemaless. The notion that fields can be added/removed and new kinds of structures and sub-structures can be added at will without any impact to existing data is pretty much one of the key advantages offered by NoSQL. With an OODBMS, the situation is totally the opposite. The database is completely hardwired to the structure of your objects, as they are stored in some quasi- or actually-serialized format. In contrast to Wikipedia's phrase, in an OODBMS, the structure of the data and the relationships between the elements is of maximal importance. From Fowler: > With an OO database you dont have to worry about mapping. You work with a large structure of interconnected objects. You might call this NoSQL in the strictest sense, but in practice NoSQL strongly implies "nearly/completely schemaless". With a "schemaless" database, you totally have to worry about mapping your objects, as an OO domain model looks nothing like the key/value cassandra/mongo-esque models we talk about in NoSQL. Schemaless systems certainly have existed for decades but that's IMHO not what Fowler refers to here.