| > His main argument is difficulties during data migrations which he frequently encounters. He rather have a smooth data migration process than having an unexpected error and abort the whole operation that the migration is only a small part of. NUTS! > I suspect the errors might be mainly caused by not considering data integrity at all at the first place Spot on. ---- I deal with interface with MANY ERP-like software with as many "database designs" as you can't imagine, and have face the fun of interface with many system in my long career. Among DOZENS only 2 major packages have zero issues and are the only ones with competent schema designs. Let me tell you how bad is it: One of my interfaces is with a package that, somewhat, manage to mix all the ways to be wrong about RDBMS: - MySql, not a good start - Only Strings and Ints datatypes, and the Ints datatypes are not many - This means ALL data is suspected (dates, money, and yes, strings too) - The tables are named `UNCC_00001, UNCC_00002...` - The fields are named `FT_0001, FT_0002...` and obviously the first is the PK. This pk is purely advisory, other fields can be part of the PK but you can't know looking at the schema - NO FK at all, so ALL TABLES have integrity issues. - NO indexes, because why make joins or lookups faster? - Weird normalization, like yes, no, maybe? - And no option to let me add some sanity to the DB, because the database is (in my niches) "property" of the software makers so can't be touched, only queried. And not tell the rest, because this is only the query side, the CRUD side is nuts, and not wanna remember much about it. --- RDBMS is one of the most simplest ways, to get FOR FREE, and minimal effort, a sane, well behaved and performant system. Refuse to use them is NUTS. Refuse to use the abilities they have is NUTS. I only have ONE actual company (in +20 years) with a real reason to go NoSQL, and that only was for a fraction of the thing (in fact, the data was mirrored to a RDBMS for reporting!). And maybe that was true 5-10 years ago, today I think modern SQL engines catchup more and more on the scenarios (Today I have used timescale just for speed up log processing, and was so much nicer that deal with weird log storage engines). |