- 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
inserto into conv (uid, type, subtype, convtext, convvalue) values (1, 0, 0, 'frist', 0);
Admin
Please tell me there's another table which contains an ASCII look-up table, so you can de-normalize entire paragraphs of text...
Admin
The issue wasn't so much the existence of the table, but the implied use of it.
Such a pity that the article didn't actually tell us how it was being used.
Admin
In my experience, asking app devs to do something differently for the sake of the dB rarely gets anywhere fast. So he was working around a bad situation. Given the initial implication that not all the queries are SPs, I was expecting the story to end with "and after he removed the table, thinking he knew better, all the adhoc queries broke".
Admin
Wait....that table is an integral part of multilanguage support...
Admin
Eerily, that happened in one of my project once. In that case the good wizard died and the forces of evil (the other DBA's) took over.
Admin
Keep your fingers crossed that Bill didn't build a many-coloured clone of his personality into the database that will crawl out of its digital coffin a couple of months after he touched the system the last time!
Admin
Yea, but what if the words for some of those numbers changes some time later, in the English language? Then what are you going to do?!? Programs, as you know, are unmaintainable and untestable. And you can't rely on programmers to do anything right. So you're really up a creek unless you put everything in the database!!!
Admin
Or did he write a hard-coded lookup table in whatever language the front-end development team used?
IMHO the existence of the table alone is not necessarily a wtf; it would be interesting to see how it was used.
A simple "SELECT ConvValue FROM conversions WHERE ConvText = 'twenty';" would probably be ok; a "SELECT * FROM conversions" and then programmatically extracting the conversions would be a major wtf.
Admin
Not to forget: what do Type and SubType mean? Did they have any meaning? If yes, how did Alan work around that when he dropped the table?
Admin
I'm curious how he filled the table in the first place.
Admin
Usually it's the Dev complaining about being forced to used stored procedures, rather than the DB Admin complaining that it's too slow.
I'm Frist-er than you!
[image]Admin
Admin
Looking at the small snippet (And the clue of sub-type) it was probably 3 lookups into the table...(at least I hope so)
Admin
So nine-hundred would be a type, forty a sub-type and seven a mere whatever. So that's three queries and some parsing of '-' and 'and' and afterwards some adding of queried values? It would be nice to localize this to Germany, where forty-two is 'zwei-und-vierzig' which makes sub-types somewhat impossible (even though types would work).
Admin
Just a day? That's the WTF -- unless it's a super-small trivial application, that's barely any time at all, which is worrying. Where's his due diligence?
Admin
Admin
Also that multiples of 10 qualify for SubType doesn't hold since 10 has the SubType 0.
No, not really. Both systems are easy enough: English: 1000s-100s-10s-1s German: 1000s-100s-1s-10s And both schemes are consistent through natural numbers (with the ususal exceptions of 11 and 12).More problematic are languages that still work on the old (babylonian?) system based on 20: Danish: 90 ("halvfems", basically "halv between 4 times 20 and 5 times twenty") French: 90 ("Quattre vingt dis", basically "4 times 20 and ten")
The msystery of the Type and SubType... will we ever solve it?
Admin
That wouldn't be hard (simply have 80 = 'quatre-vingt'). The trickiness might be with 70s and 90s (eg 72 is "sixty twelve"), but depending on how that table is used, that might be OK if you omit the subtype=1 entry for 70, and specify what 14-19 are as well.
As long as the ordering is like English (big-endian) it should be OK. It is German that would mess it up because that's counter-middle-endian)
Admin
I reckon subtype 1 are simply numbers which can have subtype 0 numbers after them. (You don't say 'ten three', thus 10 is a subtype 0).
So, if your number is X:
As hundreds/thousands/etc are regular (in languages like English, French, German etc), then you work those out using the above scheme, rather than having more types/subtypes.
One problem is that 14-19 aren't in the table, so I presume those must be worked out algorithmically as well (thirteen is the exceptional 'teen' because the 'thir' is not the same as 'three', but fourteen to nineteen can use the X-10 number before the 'teen')
Admin
But obviously they didn't.
Admin
This really isn't an established WTF until we find out how the table was being used in the first place. Were numbers being converted from their written form to their decimal form, or vice-versa? Were numbers being stored fully written out, and then converted back and forth when calculations were required?
Without some important facts there's reasonable doubt that this is a WTF at all.
Admin
Admin
Admin
Heart attacks are TRWTF, right?
Admin
frist for 1ce
Admin
Admin
Admin
Admin
Admin
Admin
Admin
A SELECT statement on one table took five minutes? What were they running it on, an Atari 2600? Did someone have to fetch the right wax memory drum from the basement?
I call BS ... without even getting on to the table itself...
Admin
I'll bet they were doing something like printing checks (checques(?) for you Euro's)
$1344.56 => ONE-THOUSAND, THREE-HUNDRED, FORTY-FOUR and 56/100ths US Dollars
Admin
Admin
In English, only 31-99 are hyphenated when spelled out, as are fractions.
[/pedantry]
Admin
Admin
Admin
Admin
I'm with the people betting on localization. Type would be language, SubType would be locale. In which case you would likely have mapping tables: either a Type and SubType table, or just a Language table. eg:
etc...As others have said, these days I would rely on the application layer for internationalization requirements, but I would point out that i18n and l10n standards are relatively recent (mid-90s.) They didn't get into major languages and common usage for a while after that. That might seem like a long time ago, but non-IT companies look at legacy software with the attitude of "If it ain't broke, don't fix it." (Which is why there's still lots of Cobol code from the 80s still running.)
Also, if you have multiple languages, or even language versions, in your app layer, there's no guarantee they'll all provide the same level of localization support. If you centralize it in your database, at least you know every app will get the same localization results. (My coworker is shaking his head at my multiple languages comment. I'll type out the example I'm giving him: J2EE providing web services + a few Sharepoint sites + some PHP or ColdFusion or ASP websites + some desktop applications in C++ or VB or C# or whatever. It's a more common situation than a company with every single system running on only one version of one language.)
Admin
It's what the Americans call a cheque when they don't have any balances around.
So it's a Freedom Cheque.
Admin
PS: If any developer on my team created a TEXT column where a VARCHAR would do, I would give them grief too. TEXT columns trade capacity for efficiency - you can store a couple of GB worth of text in there, but they can't be indexed, require custom code for searching, and require extra lookups when retrieving (due to the row just holding a pointer to the TEXT location rather than the actual value - like it does for all other columns.)
Re-reading this post, it sounds more like a junior DBA, with no knowledge of the history of a database, complaining that the previous guy had the temerity to die before he fully documented the system. It's more sad than funny.
Admin
What's that: a milkshake for Darth Vader?
Admin
Admin
That really depend on the database server you use. Most don't have any of the problems you mention and treat varchar and text the same.
Admin
Yes, I did have to give all the numbers from 0 to 20. After that it knew to just combine the digit places. 123 = 100 + 20 + 3 = One Hundred Twenty Three. I do not remember if I had to do anything different for 70's in French.
Admin
Admin
Well, MS SQL Server, Sybase, MySQL and Oracle (they call it CLOB) all work like I described. What database server are you thinking of? Or perhaps you're confusing varchar(max) with regular varchar?
Admin
Admin
The wizardly nature of Bill is clearly evidenced by his ability to speak in monospaced font.
CAPTCHA: abico - An abacus having all the beads replaced with a carving of the number they represent.