271–280 of 493 posts
Earlier quoted context omitted.
She has never been "clueless" and has written insightfully for years.
Well she's clueless about what actually sped up this database query.
Earlier quoted context omitted.
> lack of database optimization features That's a perfection description of mysql as of 2002.
MySQL, at least as far back as 2000, had indexes. http://web.archive.org/web/20020610031610/http://www.mysql.c...
The ending is the most important part. > Now, what do you suppose happened to that clueless programmer who didn't know anything about foreign key relationships? > Well, that's easy. She just wrote this post for you. That's right, I was that clueless newbie who came up with a completely ridiculous abuse of a SQL database that was slow, bloated, and obviously wrong at a glance to anyone who had a clue. > My point is: E…
That's definitely not true anymore, if it ever was. Senior/staff level engs with 20+ years of experience are sought after and paid a ton of money.
While the normalized version is more compact and doesn't store redundant data, it _also_ needs an index on the four columns or it'll have to check every row in the table. A similar index added to the original denormalized table would have given comparable query performance. The table schema isn't terrible, it's just not great. A good first-pass to be optimized when it's discovered to be overly large.
It depends - if this was the full use-case then maybe a single table is actually a pretty good solution.
Related to database indexes, but not the post: a busted database index brought down ticket sales of the 2008 Olympics Games. This was the first time regular people could go buy tickets for events & they had been lining up overnight at Bank of China locations through the country. We were down for over a day before we called it off. Apparently this led to minor upheaval at several locations in Beijing & riot police wer…
Earlier quoted context omitted.
How often are you looking at the full contents of a table vs. looking at the results of a query that you could throw an INET_NTOA onto?
Many. You also expect me to remember how to spell INET_NTOA and on what fields to use it on. What if I wanted do a quick "SELECT * FROM"? I barely know how to spell English words what makes you think I'm going to remember how to spell INET_NTOA.
Earlier quoted context omitted.
This entirely depends on what kind of index is used. A sorted index, such as a B or B+ tree (used in many SQL databases), will allow for fast point/range lookups in a continuous value space. A typical inverted index or hash based index only allows point lookups of specific values in a discrete value space.
It was a sorted BTREE index in MySQL 5.x. I agree that its supposed to be fast but it just wasn't for some reason.
I wouldn't be surprised if you hit some sort of similar strange bug.
Why _the hell_ is nobody mentioning that using a database that charges per row touched is absolute insanity? When has it become so normal that nobody mentions it?
Earlier quoted context omitted.
MySQL, at least as far back as 2000, had indexes. http://web.archive.org/web/20020610031610/http://www.mysql.c...
I wouldn't bet on these indexes optimizing anything back then. MySQL was legendary that while implementing the necessary standards (to some degree) it was neither reliable nor efficient.