441–450 of 493 posts
I do think the author still has misconceptions over how a database works, and I'm kind astonished. No, your "poor" database system won't go through every row when you are querying a varchar column. As long as it is indexed, the database will perform a index scan of some sort. Assume O(logn) as the average complexity for most databases. Of course, if the data on a column is repeated a lot, normalizing it would bring s…
This was not an issue of being in a vacuum, it was an issue of not reading documentation beforehand, which for some reason is acceptable in the development world
I don't think there are so many people attempting to perform surgery or to build a bridge without reading a number of textbooks on the topic.
And this is why back in the day everyone said RTFM
Earlier quoted context omitted.
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…
I was there and I don't remember it like you describe. MySQL was certainly not a toy database in 2002. I learned PHP from a book called "PHP and MySQL". They went together like white on rice. Every forum software used it. Hell, even today Uber uses MySQL at a VERY large scale to power their schemaless database.
https://www.databasejournal.com/features/mysql/article.php/2... (to pick a contemporary example using that exact word) suggests that the 2003 release of mysql4 ends the "toy status". Others might have had different thresholds, but that reputation was hard earned and back then still pretty apropos (to a declining degree over time because MySQL caught up). I lost data to MySQL more than once (if memory serves but it's been a while: MyISAM was a mess, the InnoDB integration not ready yet)
To handwave two extreme positions of those days (because I'm too lazy to look up ancient forums where such stuff has been discussed at length), it's very possible that different groups approached things differently:
Members of a PHP User Group probably didn't consider MySQL a toy but the best thing since sliced bread, given how closely aligned PHP was to MySQL back then (it got more varied over time, but that preference can still be felt in PHP projects)
OTOH when you had a significant amount of perl coders in your peer group, it was rather likely that some of them could go on for days about how _both_ PHP and MySQL are toys when anybody dared to talk about PHP (which ties in neatly with the original post and its reference about "The One")
[bonus: more recent example: http://www.backwardcompatible.net/145-Why-is-MySQL-still-a-t...]
I do think the author still has misconceptions over how a database works, and I'm kind astonished. No, your "poor" database system won't go through every row when you are querying a varchar column. As long as it is indexed, the database will perform a index scan of some sort. Assume O(logn) as the average complexity for most databases. Of course, if the data on a column is repeated a lot, normalizing it would bring s…
I think you missed the point of the article. Your reply must have felt great for you to write, though I'm not sure anyone got anything out of that but you.
Earlier quoted context omitted.
Indexing existed 15 years ago. The article never mentions why indexing didn't solve this problem. Super weird take on the author's part...
Early InnoDB* had pretty strict limits on varchar indexes and was not the most efficient. I don't remember the details but it's entirely possible the single-table format Rachel described ran head on into those limitations. Also remember indexes take space, and if you index all your text columns you'll balloon your DB size; and this was 2002, when that mattered a lot more even for text. Indexes also add write and comp…
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…
Could you say more about why that was the culprit and not some problem with the load testing? For the Olympics, it seems like the most important test is "What happens when we launch?" That's the kind of thing I'd run on every commit.
load tests usually only happens on staging env, not production, that is the policy.
The moral of this post really falls flat coming from this author, most of whose posts are snarky, passive-aggressive rants where she rants about someone's alleged incompetence or something similar.
This is a really weird ad hominem that is unrelated to the post itself.
To me it really clashed with the original post which concludes we need guidance/mentorship/reference points. Most of the comments in Hackernews are constructive or genuinely curious, don't just dismiss the author and instead provide things to learn.
For the author to then write a reply and dismiss all these comments as comments that are really saying "I am THE ONE. You only need to know me. I am better than all of you." is just plain rude and completely counter to their own point.
Earlier quoted context omitted.
A couple times a day at most?
From the post, you'd have to be rebuilding it every 15 minutes: > A real mail server which did SMTP properly would retry at some point, typically 15 minutes to an hour later. If it did retry and enough time had elapsed, we would allow it through.
Earlier quoted context omitted.
That sounds like newbie developers wrote that and no DBAs were involved in checking the code, not a database design problem, you are throwing blame without knowing enough about the matter. If your string fit in a varchar, it makes absolutely no sense to change it to nvarchar because your query has unicode as input.
What? The database made the call to compare the strings as Unicode. Are you accusing the DB developers of not doing their job?
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…
Oracle was called in, "en masse". Keep also in mind that Oracle Portal was basically running on top of lots of dedicated tables and stored procedures and you could not access the data directly, you interacted to the contents only through vistas, aliases etc.
It was indeed due to a smallish version bump. But we had a pretty good Team Leader who had made Oracle declare that the two different version were absolutely compatible and allowing us to write code on the older version.
He made them state this in written form, before starting the development so it was later impossible to blame the developers for the problem.