4 ms·

> At least with the ORM(-ish) tools I worked with, it always felt much more straightforward to just change classes within the application code and automatically

by ken 6y ago

> At least with the ORM(-ish) tools I worked with, it always felt much more straightforward to just change classes within the application code and automatically generate the respective migrations... There's your answer, no? You've got specific tools and workflows you've designed to work with your database in a specific way. You can't just take one workflow and substitute a piece of another workflow and expect it to always work. Your tools and processes would be as useless for me as mine would be for you.

smoe 6y ago
Sure, but almost all the times (I'm not specifically referring to person in the comment I'm responding to and should have been more clear on that) people were making it fundamentally an sql vs. non-sql argument. As in you need to switch your entire database system or make a bet on this completely new player instead of battle proven tech, because with relational databases schema migrations are hard. Among a bunch of other questionable claims. Sure if you take the vanilla databases without their ecosystem, there is some merit to that, but I don't find it a very practical argument to ignore all the tooling and workflows that do exists and are used by people. When MongoDB first came out, I was eager to check it out. I was using mainly Django with Postgres at the time, but had my career start on ZODB, an object-oriented non-sql database created in the late 90s. So I was hopeful that MongoDB could give me the best of both worlds. One of the reasons I backed of Mongo very quickly was the lack of tooling as soon as you have something resembling a schema or relationship and you'd want to change it.