391–400 of 493 posts
Earlier quoted context omitted.
I would expect most seniors to want a set of eyes across their work doing any form of authk or z. If only to share blame :p
> authk I've always seen authn. Where'd you pick this usage up?
Why exactly would it be so bad to just put a suitable index on the table containing strings? The time complexity of the resulting search would be the same, so I assume there will be some constant factor slowdowns. Is it that indices over string fields are stored inefficiently on disk? (If so, can that not be fixed in the db engine directly?) Or is this fine today but wasn't fine 15 years ago?
Yeah, while this is not optimal (ip should be converted into integer, time should be ts), the table would be small (as old entries could be safely deleted). The only real issue is the lack of indices. Also is helo field even needed?
Even better, use a database with a proper inet datatype. That way you get correctness, space efficiency, and ability to intelligently index.
Earlier quoted context omitted.
Fork and fix? I’ve personally been pleasantly surprised by how fast maintainers will merge a PR I submit. If it causes an issue with our own systems it also gives me a very good justification for doing it.
In Oracle's proprietary system?
This case its important to recognize it was 2002, early days. This story just doesnt read the same in todays context.
Earlier quoted context omitted.
> authk I've always seen authn. Where'd you pick this usage up?
You need to distinguish authentication from authorization. "auth9n" and "auth8n" might be a slight bit too obsure for the purpose.
Earlier quoted context omitted.
Yeah, while this is not optimal (ip should be converted into integer, time should be ts), the table would be small (as old entries could be safely deleted). The only real issue is the lack of indices. Also is helo field even needed?
IP should NOT be an integer. IPv6 does not fit in a database integer. MySQL has functions to convert to bytes. Even better, use a database with a proper inet datatype. That way you get correctness, space efficiency, and ability to intelligently index.
In 2021 I’d recommend just turning off the IPv6 allocation or deleting it from DNS like this site does.
Earlier quoted context omitted.
I 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 cert…
As 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 "se…
Earlier quoted context omitted.
Old best practice for InnoDB performance was actually to never use foreign keys because of these locking issues. Not sure if that's the case in 2021.
InnoDB uses row-level locking, and foreign keys are (usually) a great feature to ensure data integrity. But using multiple foreign keys from tables `a`,`b` as a composite index for table `x` can cause deadlock if both are being updated in rapid succession, because an update on `a` gets a lock on `x`, which needs a read lock on `b` which is waiting for the lock from `a` to be released. I try to never structure multipl…
Earlier quoted context omitted.
That's pretty beside the point though, the concept of indexing had existed for decades even prior to that.
The quote was "database optimization features" and the scope was "MySQL as of 2002". Of course, even my old DBase II handbook talks about indexes - all that's old hat. MySQL had them, too. MySQL also used to have a long-earned reputation as a toy database though, and MySQL in 2002 was right within the timeframe where it established that reputation. So yeah, you could add indexes, but did they speed things up (as in t…