4 ms·
SQL is not DRY, especially when people stuff their apps with bloated ORMs. SQL exists because people used to query RDBMS directly , now most of the time databas
by camus 14y ago
SQL is not DRY, especially when people stuff their apps with bloated ORMs. SQL exists because people used to query RDBMS directly , now most of the time databases are simple data repos , it makes sense to put most of the logic in the application itself.
One should not have to deal with types in the app and types in the database, exceptions in the app and database errors , events in the app and triggers , functions in the app and stored procedures , or it means one doesnt trust it's own middleware.
SQL makes apps insecure, and hard to refactor, and is a non sense when doing OOP design ( here comes the bloated ORMs again which usually come up with their own query langage ... linq , dql , hql ... ).
Doesnt mean data modelling is bad , on the contrary that's the first thing to do , but data modelling doesnt need to fit the SQL mindset ( thinking in tables and columns ). Objects are parts of collections that can hold collections of other objects themself. Why should one try to fit that model into SQL ? it does not.
MongoDB may not be the best NoSQL solution out there neither , there are better products.
- jeltz 14y agoOne major advantage of using SQL databases is that they provides excellent guarantees for data integrity. This means I do not have to think much when refactoring my data. And I do not have to worry about production systems crashing due to old data being different from new. When modifying the schema in NoSQL databases I always worry about if I mess up and leave old cruft which will cause my code to crash, or even worse if I lose data (data created between the last backup and the upgrade). With proper SQL constraints there are many fewer ways where you can screw up when refactoring. And easy refactoring of data is key to agile development of systems which have been put into production.
- jfb 14y agoI have never (in twenty years) seen a non-trivial database that is solely accessed by a single application. Given the ORM anti-pattern, many of these databases had no constraints ("we'll do it in the model!") or had only partially defined schema ("it's faster when we don't have to migrate!"), meaning that anyone who just wanted the data had to either load all the application garbage, or reverse engineer the schema. If you start with your tables, and let the database engine do its job (of course, this is predicated on using a database and not, say, MySQL), querying data becomes a one-banana operation. Of course, there are downsides to this approach, but at scale, all quick and dirty hacks become nightmarish tarasques. DO FEWER HACKS.