4 ms·

So glad I migrated to SQL recently. I thought I had unstructured data and I had no real need for relational data. But oh boy I was wrong. Want a customer list,

So glad I migrated to SQL recently. I thought I had unstructured data and I had no real need for relational data. But oh boy I was wrong. Want a customer list, billing, emails, linked accounts with those users, etc. All of this was such a pain in mongo and remnants of messy schema still lurk in our codebase. Reminds me alot coding in typed languages like C vs. python or JS. But in the case of mongo I think I was getting the worst of everything ;)

xwdv 6y ago
I think the reason this happens is people have a poor understanding of what is unstructured data. Most data is going to have predictable structure to it, so you might as well just make it official. In fact, in all my years, I don’t see any real reason to use MongoDB over SQL, unless you’re storing log files or something.
- atom_arranger 6y ago
  I’ve been thinking lately that maybe the most reasonable path would be using SQL early on so you have a very clear picture of your schema, and you can do migrations easily. Once you scale up and your schema and access patterns have solidified then you can make the switch to NoSQL where it makes sense.
  - mercer 6y ago
    I suppose it depends on the specific project or feature. Usually I go for the approach you describe. But more than once I got bitten by doing this for a feature or project where things were still very much in flux, and/or in a prototyping phase. In those cases, starting with 'NoSQL' (JSONB columns in Postgres though) would've saved me a lot of trouble, and it would have been much easier, relatively speaking, to migrate my data into proper tables once things solidified. Still, I do find that going for 'SQL' by default has usually been the better choice.
joshxyz 6y ago
This this this. At the sight of the first relational data I noped the fucked out immediately at nosql db's

4 ms·

So glad I migrated to SQL recently. I thought I had unstructured data and I had no real need for relational data. But oh boy I was wrong. Want a customer list,

by dazhbog 6y ago

xwdv 6y ago
I think the reason this happens is people have a poor understanding of what is unstructured data. Most data is going to have predictable structure to it, so you might as well just make it official. In fact, in all my years, I don’t see any real reason to use MongoDB over SQL, unless you’re storing log files or something.
- atom_arranger 6y ago
  I’ve been thinking lately that maybe the most reasonable path would be using SQL early on so you have a very clear picture of your schema, and you can do migrations easily. Once you scale up and your schema and access patterns have solidified then you can make the switch to NoSQL where it makes sense.
  - mercer 6y ago
    I suppose it depends on the specific project or feature. Usually I go for the approach you describe. But more than once I got bitten by doing this for a feature or project where things were still very much in flux, and/or in a prototyping phase. In those cases, starting with 'NoSQL' (JSONB columns in Postgres though) would've saved me a lot of trouble, and it would have been much easier, relatively speaking, to migrate my data into proper tables once things solidified. Still, I do find that going for 'SQL' by default has usually been the better choice.
joshxyz 6y ago
This this this. At the sight of the first relational data I noped the fucked out immediately at nosql db's