3 ms·

Never use an ORM that wants you to define your schema anywhere except the database. Never use NoSQL just to avoid writing SQL. (There are lots of valid reason

Never use an ORM that wants you to define your schema anywhere except the database. Never use NoSQL just to avoid writing SQL. (There are lots of valid reasons to use NoSQL, but that is not one of them). First week or so: Change the DB as much as you like, directly, using the visual tools or create/alter statements as you see fit. Once you're ready to do things right: Use change scripts. Save every create/alter statement, as well as data population and modification queries into a .sql file in a directory, named sensibly so that you can run them in order to exactly reproduce your schema at any point, on any machine. Important to note: This is not hard. SQL is not hard. Avoid tooling written by people who think SQL is hard, that therefore build elaborate workflows that are in fact hard in an effort to shield you from having to touch the database.

scarface74 9y ago
He never said anything about SQL being hard. In fact, I think MongoQuery is much more obtuse than SQL. That being said, when you don't know what your schema is going to look like, why not use a Nosql solution - either a pure nosql solution or the JSON support built into modern databases? If you write your code correctly and have one module retrieve for one domaim, you should be able to isolate changes. But, if I do have to use Sql, I agree, put all of your changes in sql files numbered and have a "database version" and find/create tooling that can automate running the Sql scripts and run it as part of your CI/CD.
- jasonkester 9y ago
  when you don't know what your schema is going to look like, why not use a Nosql solution Because one day soon, you will know what your schema is going to look like. And the next 10 years of your business will be a lot more pleasant had you optimized for them rather than the first week of greenfield development.
  - scarface74 9y ago
    And there are all sorts of well known solutions that let you create separate solutions for OLTP and OLAP. You don't have to have one type of data store to rule them all.

scarface74 9y ago

He never said anything about SQL being hard. In fact, I think MongoQuery is much more obtuse than SQL. That being said, when you don't know what your schema is going to look like, why not use a Nosql solution - either a pure nosql solution or the JSON support built into modern databases? If you write your code correctly and have one module retrieve for one domaim, you should be able to isolate changes. But, if I do have to use Sql, I agree, put all of your changes in sql files numbered and have a "database version" and find/create tooling that can automate running the Sql scripts and run it as part of your CI/CD.

jasonkester 9y ago
when you don't know what your schema is going to look like, why not use a Nosql solution Because one day soon, you will know what your schema is going to look like. And the next 10 years of your business will be a lot more pleasant had you optimized for them rather than the first week of greenfield development.
- scarface74 9y ago
  And there are all sorts of well known solutions that let you create separate solutions for OLTP and OLAP. You don't have to have one type of data store to rule them all.