4 ms·

One important topic missed is time. MySQL default table engine was non-ACID MyISAM until 2010, the internet is chock full of pre- 2010 era blogposts authoritat

by VLM 8y ago

One important topic missed is time. MySQL default table engine was non-ACID MyISAM until 2010, the internet is chock full of pre- 2010 era blogposts authoritatively declaring mysql can never be ACID compliant which is doubly wrong because InnoDB was added around 2010 so I guess its possible to have an eight year old untouched install where innodb is available and possibly in use, but not default. Mysql can't do transactions is another decade-obsolete mantra that is very common for same reason. Another topic not mentioned is scalability and hardware reqs change over time. Something that would have required a large database cluster and Oracle and a huge pile of money in the 90s or some strange nosql in the 00s can be done today on sqlite on a single ras pi. You have to trace the requirements backwards all the way. "We have to do something exotic unreliable and complicated in 2018" is usually a short version of "We have to do something exotic unreliable and complicated in 2018 because we spec'd how to do that in 2003, but we'd never do that again in 2018" A topic not discussed is the dreaded anti-pattern of internal platform. Make your DB and the paperwork around it complicated enough, your distant devs will take a dump from the DB and emulate a truly awful and buggy simulation of a real DBMS in javascript or whatever. World is full of devs doing "Select * from ..." then writing their own un-indexed WHERE clause in their frontend UI, for example. I've seen people try to be better at sorting than the DB, cringy stuff. Just saying whenever you have a DBMS its a natural human desire for devs to write an inner platform DBMS emulating things that should be done in the DB. The final topic I have is busywork expands to fill all available hardware and a constant DBMS problem is people will max out any DBMS, no matter how large, with meaningless trivialities if you have the spare gigs and cycles. And you'll never get an honest answer from business users, everything is critical means nothing is actually critical. Those are business anti-patterns all DBMS need to fight against regardless of technology, and are present at all DBMS installations. Its possible I missed some of those topics if they were in fact in there.

collyw 8y ago
MySQL is usually shambles still. I am pretty sure that Django defaulted to MyISAM until later than that. Or maybe it's that most installs were not on the most recent version until well after the 2010 release. I have had some really crappy problems to fix because of tables being a mix of MyISAM and InnoDB, tables being locked because one type has a foreign key to another. Then there are the default string settings.... Agree with you on crappy devs essentially doing NoSQL in the application layer though. I am starting to hate this industry, where chasing the new trend is becoming more valuable than learning to do things well.
- VLM 8y ago
  Your string comment reminded me of another thing, some DBMS have a philosophy of consistently storing data, like MySQL, and others have a philosophy of storing consistent data, like postgresql, and people often confuse the two and run into horrible business rules problems when they intermix. Consider the idea of a column type "date". Is that supposed to merely be a string format and search and sort key like (old?) mysql or should a date column be something the dbms tries (and usually fails) to authenticate? For an example of a problem with the latter, there are Gregorian calendar dates that do not exist or exist depending on the locale of the data (or the locale of the DBMS, or the locale of the table, or maybe the locale of the query session?), what should a hyper-authoritarian DBMS do to be strict enough? Will there be a leap second on the last day of 3210 AD and if we later decide not, what should happen to existing stored timestamps for that leap second, just core dump the DBMS every time you try to start it?

by VLM 8y ago

collyw 8y ago

MySQL is usually shambles still. I am pretty sure that Django defaulted to MyISAM until later than that. Or maybe it's that most installs were not on the most recent version until well after the 2010 release. I have had some really crappy problems to fix because of tables being a mix of MyISAM and InnoDB, tables being locked because one type has a foreign key to another. Then there are the default string settings.... Agree with you on crappy devs essentially doing NoSQL in the application layer though. I am starting to hate this industry, where chasing the new trend is becoming more valuable than learning to do things well.

VLM 8y ago
Your string comment reminded me of another thing, some DBMS have a philosophy of consistently storing data, like MySQL, and others have a philosophy of storing consistent data, like postgresql, and people often confuse the two and run into horrible business rules problems when they intermix. Consider the idea of a column type "date". Is that supposed to merely be a string format and search and sort key like (old?) mysql or should a date column be something the dbms tries (and usually fails) to authenticate? For an example of a problem with the latter, there are Gregorian calendar dates that do not exist or exist depending on the locale of the data (or the locale of the DBMS, or the locale of the table, or maybe the locale of the query session?), what should a hyper-authoritarian DBMS do to be strict enough? Will there be a leap second on the last day of 3210 AD and if we later decide not, what should happen to existing stored timestamps for that leap second, just core dump the DBMS every time you try to start it?