3 ms·
My tips, start a project with an NoSQL store, and when you are certain about your schema, consider traditional SQL. It’s so comfortable to iterate quickly with
by edweis 2y ago
My tips, start a project with an NoSQL store, and when you are certain about your schema, consider traditional SQL.
It’s so comfortable to iterate quickly without schema constraints
- realprimoh 2y agoAt that point, why not just use a SQL database with a JSONB column and then add columns as you slowly finalize your schema? :)
- deleted 2y ago[deleted]
- psadri 2y agoDoes this ever actually happen? In my experience, by the time you realize you need regular SQL there is so much code that changing the database is a major project. It will also halt all other feature development.
- appplication 2y agoI like the idea in theory but in practice having a big json blob that I need to refactor later has never felt great. Makes more sense to me to just do it right.
- psadri 2y agoYup. I tend to start with SQL tables as well - although I feel the pain during the heavy iteration phase. I tend to nuke my entire db, recreate it and reload some data into it. I wish there was a tool that ran in watch mode and patched the db based schema edits.
- mohas 2y agordbms with dynamic json column is totally different from nosql mindset and design patterns, if you are going to design your data in a relational matter but with dynamic attributes rdbms are still better at the job
- chipdart 2y ago> It’s so comfortable to iterate quickly without schema constraints I'd be very careful about this simplistic reasoning. The whole point of schemas is data validation, and the hard part of "iterating quickly" is migrating data in a way you ensure it remains valid. Neither of these requirements are tied to relational databases. At most, breaking a schema ensures you cannot proceed with broken data without undergoing a migration, or completely wiping your database. But you are already doing that, aren't you?