Hacker News Reader

Comment by discordianfish | Hacker News Reader

The real problem here seems to be that changing the schema seems prohibitive expensive.

That's a huge problem with SQL in general. It ought to be trivial to maintain multiple views of the data to allow you to migrate old clients bit by bit, but in practice it's rarely done.

Also, it's a business problem. They can always ask for more cruft and IT has a huge incentive to take the short-sighted route, get promoted and move on.

Re: "[flexible schema change is a] huge problem with SQL in general." -- I've been a proponent of the idea of "dynamic relational". You can add any column on whim to a row just by including it in an INSERT or UPDATE command, unless an explicit constraint/rule forbid it for a given table or database. You could even make tables similarly create-on-write. No DBA's needed! (within reason) Comparisons have to be done with care, though, as with any dynamic/implied typed system.

But create-on-write doesn't solve cross-table relationship flexibility problems: such as changes between 1-to-1 to 1-to-many and/or to many-to-many. If you already have data, that's usually a tricky domain problem regardless of what kind of database technology you use. It's about the semantics of your data, not machines.

Re: "[flexible schema change is a] huge problem with SQL in general."

Graph databases mostly solve these problem but they have not seen much uptake, don't know why.

Using "Dynamic Relational" (DR) is much more similar to existing RDBMS. You don't have to relearn much. I'm not necessarily saying DR is objectively better or worse than graph DB's, only that DR is a smaller learning curve to those using the most common RDBMS out there.

Reply on news.ycombinator.com