> I've written a ton of SQL migrations this year, none of them are scary or even really count as "big bunch of sql". If this describes your code, you should probably stop and rethink what you're doing, because that's bad practice.
The difference between, eg, merging your "first_name" and "last_name" fields into a single "name" field with Mongo or a SQL DB is basically that the SQL DB has better tooling so it'll be cleaner, faster, and more concise.
No the difference is one has to be written in a shitty language (SQL), whereas the other can be written in an actual programming language.
> Also false. Nothing requires you to use the ORM commands if they don't make your life easier; literally last week I wrote a migration for some ORM based code using pure vanilla SQL because it was more appropriate. If you know what your ORM is doing, it's trivial. And if you don't, well, you have bigger problems.
Err no it isn't false. It is based on real-world experience, rather than "theory" about "what you can do". In the real world, people use ORMs and the ORM migration library, and then they find that the migration library doesn't do what they need it to do, so they have to use raw SQL. But then they run into the problem that because the ORM handles all of the generation of indexes and column names and so on, they have to figure out the correct naming of everything so that the ORM understands what you have done. This often results in failure because the ORM does not want you to tinker with the schema yourself.
> With a relational DB: Check the table schema.
Which requires you to context switch from the code to the schema and piece together all of the relations based on foreign keys. It is much easier to do this in the programming language, but as I have figured out, most of the people in this thread are actually DBAs and have no idea about programming.
> No. Mongo still lists flexible schemas as a feature, ie, they do not enforce any specific schema.
err yeah I was thinking of constraints. I heard some news about it the other day.
> Yeah, but what relational DBs are very good at is enforcing foreign key constraints. If your data is relational at all (and let's be real, very, very little world data isn't at least somewhat relational), you'll need it, and Mongo doesn't have it. (Well, Mongo doesn't even have foreign keys, but it lacks the equivalent feature for dealing with denormalized data too.) Managing to set some non-numeric characters in your phone number field when some of your app code contains a hard assumption it will be numeric is bad, yeah. But when you start screwing around with relations, foreign keys, failing to properly propagate changes to every copy of a denormalized data structure...oh man, you can spend days trying to untangle that mess. And it's a class of error that relational DBs don't have unless you misuse them badly.
This isn't exactly correct. Foreign key restraints are required when you denormalise the data. Many of mongos relationships are going to be in the same document and therefore a foreign key isn't necessary. You do have to manage consistency within the code though, which is something you don't have to do with a SQL database. Having said that, there are many consistency issues that can occur in a SQL database as the constraints are limited in what they can enforce. You have to start to get into triggers and stored procedures to enforce more complex business rules.