- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- 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
I worked on a "Post-Relational" database (PICK, Prime, Info-PC) for years which did exactly this, with the exception of a delimiter between data in the columns ( | ) BTW, still today there are very large databases using this technology due to it's performance, yes its way faster than today's relational databases.
These guys are almost there, just figure out how to add a delimiter!
Admin
If that's what it is, then there seems to be a gap between each sub-field in the "data" colum. Could that be a tab? A tab would function as an acceptable delimeter.
The main problem with this approach is that it's not type-safe. It only takes someone to get the fields in the wrong order and it all goes to pot.
Admin
I know that following up to yesterday's post will not get much airtime, but...
I also worked with 'Pick', but as a developer of a version of Pick written in C.
Post-Relational ????? Pick was state of the art in 1970, somewhat before relational databases. Some really inventive marketing type came up with the term post relational, barf, barf, barf.
Yes, Pick was quick as long as you don't need indices or transactions.
Flat files are much faster than Pick, albeit only if you always want to read the entire file.
The comparisons are a MAJOR WTF.
Admin
It really looks more like an import from a fixed-width text file (where the fields are defined as offset ranges from the beginning) to me than anything delimited. I've dealt with a lot of these, and you're damn skippy that I immediately parsed them out into delimited fields or into a proper database table...
Admin
==> Its pretty slick actually
Yeah, if you consider 1972's "heirarchical databases" to be "slick".
Admin
Try PeopleSoft...maybe not 1000 columns per table, but there are several key tables with 200+ columns. Everybody loves screwing with that! What column is that data in?...let's just scrrrrrrrrrollllllll till we find it. And as a bonus, every time you upgrade to a newer version, tons of new columns will be added to most tables.
Admin
I am currently working a contract in a defense plant. I see this all the time, for the same reason. They want to use the latest technology, but the old mainframers there have no clue what relational DB means. One asked me the other day what a data warehouse is [:O]
Admin
cuckoo clocks are from germany... out of bavaria...
Admin
Baden-Württemberg, you heathen. Or are you a northerner like me who considers everything south of Hannover to be Bavaria? [;)]
Admin
In fact, all the names, phone numbers and zip codes are Swiss.
Admin
I have dealt with many such systems doing things exactly like that. Automotive manufacturers have holdover systems from the days of punched card readers. I kid you not.
I can't go into extreme detail, however, many of these systems, in the fun and long twisted road of conversions over the years, have been turned into what are essentially blocks of text. Different characters in different positions define specific vehicle options. Every VIN is a relic of this, the VIN is usually a direct copy of the first line of such positional systems.
Therefore, when working with this sort of thing, you frequently see these big blocks of text in relational databases as strings. When you need to know something about the vehicle, you pull out the string via some method (that you don't have any control over), and then decode it in some fashion.
Slightly offtopic: One of our systems had a rule-based configuration system. You would define things like "BucketSeats" as "D14=ABCD". If the character in position D14 was ABC or D, then you knew the car had bucket seats. Then you'd define other stuff based on "BucketSeats". You could then even base rules off other rules like "D12=DEF | !BucketSeats" and so forth. Some of my favorite WTFs is when I found things like "BigMirrors" = "!LittleMirrors" and "LittleMirrors" = "!BigMirrors" or the time I found "SomeSpecificModel" = "SomeOtherStuff & (RedColor | !RedColor)"...
But the best was when I had to write a conversion system between our interface and our competitors competing product. See, in one plant, they had bought our competitors system, but hated the way it looked. Since we couldn't convince them to switch to our system very easily, I was drafted to pull data from their system and produce our pretty reporting functionality from it.
Their entire "relational database" used one DB table with two columns: Line and String. And Line was an autoincrementing number.
The thing was originally written to put all its results into a single flatfile, and the client asked them to use a relational database instead (in order to try to make them do something similar to our product). So they took the simplest approach possible.
The client wanted nice reports (like ours did), but their product couldn't produce any reports about statistics or number of failures or anything. It was a testing system with absolutely no way to report the results of the testing.
So I had to write something that actually checked their database every so often, got the max(Line) number, compared it to what it had gotten before, pulled out everything in between, parsed it, and stuck all that into our own real relational database. Then our reporting system worked without any changes, more or less. It was hideous. They used it for about 6 months then dropped the system entirely and bought one of ours. So in that sense, it was worth it. :)
Admin
Hmmm.. the data seems to be in the German language. Now I am beginning to understand how the allies were able to break the German code and win WWII.
Admin
There are 2 solutions to that:
1) make them develop their code on a slow database server and force them to start with hundreds of thousands of rows of data. With a lot of up-front test data, bad design becomes very apparent, very quickly. And it's much better than finding out 6-18 months later when the data's grown.
2) apply a suitable LART. e,g, a clue-by-four. or failing that, apply a suitable manual/database design book. if they won't read it, apply it like a lart.
Admin
It's hard not to laugh out loud at some people's first attempts at relational database design. The database WTF's I've seen on this site in the last couple of weeks have really got cooties. But to be charitable (hey it's Christmas) maybe they were fresh out of school or were under pressure.
There's an Amazon list of great data and consulting books http://www.amazon.com/gp/richpub/listmania/fullview/1MNEQZ98AWUN/002-3301118-9644804?%5Fencoding=UTF8, by a gal named Karen Lopez who's a real smarty about this stuff. All her data selections are solid and have stood the test (imho as a data architect and modeler for over a decade). Personally I think Data Modeling Essentials by Graeme Simsion is a tremendous owner's manual for relational data and a strongly suggested first book for anyone who wants to do good data work. It's an easy read, very practical, in its third edition, and it's cheap. Give it to your friends and relatives.
Merry Christmas.
Admin
Yay for reviving threads that have lain dormant for 4 months. Seriously, I think I saw some more interesting threads to which I have something to add on page 18.
Admin
First time I saw a RDBMS (Sybase) I worked in a COBOL shop, they went into RDBMS all right, with client/server appls, powerbuilder, all the stuff.
But they had to migrate interactive (VT-100) COBOL appls, it was impossible to convert some appls to client/server because the users logged in without tcp/ip connectivity (thanks God for cisco IGS protocol converters).
At the time sybase had process to embed SQL in COBOL programs (it was some kind of pre-processor that was run before the COBOL compiler).
The quick 'n' dirty porting in order to get the data inside the new disks in the new server, INSIDE the database give birth to files just like that one.
It may be ugly from the RDBMS point of view but it was Gold from the porting point of view, almost no changes to the programs, just a few pre-processor calls with the SQL inserted at strategical points and it's over.
Of course that new appls are clien/server and new data goes into normal tables, but old data HAVE to be stored like that or you will have to develop new appls (and convert the old data) to suport appls that are near his end-of-life.
And they need no sticking delimiters, COBOL just reads a "record" over a PIC (it looks like a C struct), it was made to read and write fixed length records with fixed length fields, it could be made to work in other ways but most of COBOL programmers didn't even dream with that.
Admin
The real WTF is that they have too many columns in their database table. They could easily have merged the "Date Processed" and "Time Processed" (DATVERA and ZEITVERA) columns into a single DATETIME column. (Heck, if they could not get their heads around standard SQL data types, they could even have used a UNIX-style time_t timestamp, like some people do...)
Admin
correct
/quote
Germany in the 17th century was a hard place. Europe was going through a mini-ice age, and it was so cold during the winters that milk sometimes froze in the pail between the barn and the house.
In the Black Forest area of Germany, opinion has it that around the year 1630 a glass peddler who had traveled to Czechoslovakia brought back a crude, wooden clock called a “wood-beam clock” which used wooden gears and common stones as weights. There was no pendulum; it used instead a piece of wood called a “Waag” which moved back and forth above the clock dial. Crude or not, the clock was a definite improvement over the hourglasses and sundials that were the norm in those days.
The clock caught on, and people began to make clocks in their homes during the long, harsh winters. These clocks soon became an important source of income; particularly among the so-called “Häuslers”. The custom of inheritance by primogeniture (i.e. the 1st born son inherits) was in effect and other, younger sons usually received only a small plot of land for a hut and had to work for others in order to survive. Very shortly, clock making was a roaring cabin industry.
The original clock was greatly improved upon over the years by the volk of the Black Forest, and clock peddlers ( “Ührschleppers” in German) began taking the clocks all over Europe. The people would work at clock making during the Winter and the Ührschleppers would take them off for re-sale in the Spring.
In 1712, Friedrich Dilger from the village of Urach went to France for a year to study advances in clocks and clockmaking tools, and brought better technology back with him.
/endQuote
Admin
So they paid the consultants for this load of crap....