4 ms·
I think she inadvertently made a different point, which is that even experienced developers sometimes misunderstand the problem and make mistakes. Or an even b
by newaccount74 5y ago
I think she inadvertently made a different point, which is that even experienced developers sometimes misunderstand the problem and make mistakes.
Or an even better argument: you don't need to actually understand the problem to fix it, often you accidentally fix the problem just by using a different approach.
- mst 5y agoI would argue instead that this comment thread is making the point that people forget that things that work now wouldn't've worked then and design decisions have to be made based on the database engine you're running in production.
- jeremyjh 5y agoMySQL could index strings in 2002. It would have worked fine.
- mst 5y ago"mysql could index strings" and "using a compound index over four varchar columns would've worked out well" are significantly different propositions.
- jeremyjh 5y agoYes, we won't know because she didn't try it. And we know she didn't try it because the problem she described is table scans, not "indexed strings are somehow slow in MySQL circa 2002".
- mst 5y agoOr she did try it and it didn't work - or researched the question and figured, quite reasonably based on my experience of mysql in that era, it probably wouldn't work - and kept the post to only the original problem and the final approach to avoid having even more technical details in a post that wasn't really about those. I agree that we don't know, but it seems a little unfair to her to treat every unknown as definitely being the most negative of the possibilities.
- hn_throwaway_99 5y agoI really don't understand your general thrust here. MySql certainly had lots of issues in 2003, but being able to support multi-column indexes was not one of them. Her analysis is simply wrong - it is wrong now and was wrong then. Here is the doc from MySql v3.23: 7.4.2 Multiple-Column Indexes MySQL can create composite indexes (that is, indexes on multiple columns). An index may consist of up to 16 columns. For certain data types, you can index a prefix of the column (see Section 7.4.1, “Column Indexes”). A multiple-column index can be considered a sorted array containing values that are created by concatenating the values of the indexed columns. MySQL uses multiple-column indexes in such a way that queries are fast when you specify a known quantity for the first column of the index in a WHERE clause, even if you do not specify values for the other columns
- mst 5y agoAs I said already: "mysql could index strings" and "using a compound index over four varchar columns would've worked out well" are significantly different propositions. To be more verbose about it - there is an important difference between "can be created" and "will perform sufficiently well on whatever (likely scavenged) hardware was assigned to the internal IT system in question." I wouldn't be surprised if the "server" for this system was something like a repurposed Pentium 233 desktop with a cheap spinning rust IDE drive in it, and depending on just how badly the spammers were kicking the shit out of the mail system in question that's going to be a fun time.
- lern_too_spel 5y agoThey are not significantly different. It just means sorting using more than one column.
- merb 5y agoyou know for performance the new table would've needed a string index aswell?
- 5y ago
- deleted 5y ago[deleted]