- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Performance art I hope?
Admin
Can I play with madness. - Yes, go into DB design.
Admin
A linked list of database? WTF?
The guy who created that is not a clown, he's an entire circus.
Admin
Relational Databases are the closest we come to actual Wizardry in the modern world. Only the Initiated know how they work. Sometimes you have to take arcane actions to get your result. They frequently work in mysterious ways.
Admin
Ahh yes, the π-normal-form.
Admin
Storing the date of events in the name of the table? That's not going to end well, ever.
I'm sure that if you describe it as that, at least some folks are going to have first thoughts about it. (I would say "second thoughts", but that would imply that those people had given it even a microsecond of thought in the first place.)
Admin
The real WTF is not using ISO dates in the table names.
Admin
Someone reinvented database-partitioning. Very badly of course, because Raisins.
Admin
Seems like the designers of this scheme reinvented database partitioning.
Admin
To those (justifiably) thinking this is a clownish version of partitioning - well not really, because according to the article, there are materialized views which "join" (did they mean "unioned"?) all of the tables together, which undoes the benefit of partitioning, and furthermore, makes the whole thing that much worse.
Admin
None of the people you seem to be addressing said or even implied that the partitioning had been reinvented well. Approximately 58.27% of TDWTF articles come from someone's attempt to reinvent a standard tool or technique.
Admin
One of the more difficult things to learn when designing a relational database is learning when not to "do things my way" when the database engine is already far more capable, fast and efficient at solving that "performance problem" than you are.
Admin
And, only after that, learning when and how you should do things differently because you do sometimes know better than the database engine, so you can steer it away from a poor access path and towards a better one. You can't do it well until you understand your data, your indexes, the general behaviour of your database's optimiser, and how to read a query plan.