2 ms·
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 r
by 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 agoYour 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?