3 ms·

The problem being that to use RDBMS well with object-oriented software you need an ORM (object-relation mapping) layer, which adds complexity and cost and maint

by nbevans 12y ago

The problem being that to use RDBMS well with object-oriented software you need an ORM (object-relation mapping) layer, which adds complexity and cost and maintenance burden. RDBMS are a central point of failure and don't scale well. Relational data is typically overkill for the vast majority of applications which would be better suited to a document-based dataset at the expense of a little more memory cost. Etc etc... :)

collyw 12y ago
I disagree. Database code is generally a lot less buggy than application code, probably due the declarative nature. Plus with a properly normalized schema, you can answer most questions about your data. Document databases have basically forced you to denormalise at step 1. I would say we should forget about the OOP and stick with the RDBMS, as that part works well.
- nbevans 12y ago
  RDBMS has its uses, I didn't say otherwise. However I did say adopting it as a "default" persistence mechanism is wrong. RDBMS is something you adopt with your eyes wide open as it is large architectural decision and ultimately a burden to take on board. And even then you may only adopt it for one particular subsystem of your product; for polyglot persistence is the best. For application state, the big drawback of RDBMS is its lack of temporal and immutable persistence. This is where the temporal nature of event sourcing is a better fit for application state. Event sourcing can feasibly perform a superset of operations that SQL can do, and it can do all this without the the need for mutable state.
CmonDev 12y ago
Just wait a couple of years until the SQL for NoSQL will arrive or something else at least remotely looking like a standard. Then we will have ORMs for NoSQL.
eru 12y ago
Relations work well with functional programs. Some people even want to make relations the default data type. (We did something similar at Standard Chartered.) See eg http://lambda-the-ultimate.org/node/1446 http://lambda-the-ultimate.org/node/1446

by nbevans 12y ago

collyw 12y ago

I disagree. Database code is generally a lot less buggy than application code, probably due the declarative nature. Plus with a properly normalized schema, you can answer most questions about your data. Document databases have basically forced you to denormalise at step 1. I would say we should forget about the OOP and stick with the RDBMS, as that part works well.

nbevans 12y ago
RDBMS has its uses, I didn't say otherwise. However I did say adopting it as a "default" persistence mechanism is wrong. RDBMS is something you adopt with your eyes wide open as it is large architectural decision and ultimately a burden to take on board. And even then you may only adopt it for one particular subsystem of your product; for polyglot persistence is the best. For application state, the big drawback of RDBMS is its lack of temporal and immutable persistence. This is where the temporal nature of event sourcing is a better fit for application state. Event sourcing can feasibly perform a superset of operations that SQL can do, and it can do all this without the the need for mutable state.

CmonDev 12y ago

Just wait a couple of years until the SQL for NoSQL will arrive or something else at least remotely looking like a standard. Then we will have ORMs for NoSQL.

eru 12y ago

Relations work well with functional programs. Some people even want to make relations the default data type. (We did something similar at Standard Chartered.) See eg http://lambda-the-ultimate.org/node/1446 http://lambda-the-ultimate.org/node/1446