The web is supposed to be this great leveller. Everyone is able to publish whatever they want and put it before a global audience. There is no bar to entry into the web club. Sometimes that might not be seen as a feature.
We all know HTML "designers" who have no idea of how HTML should work.
As Perl programmers, we've all seen CGI programs written by "programmers" who have no idea how to program.
I'm now starting to see more and more web sites that include databases which have been "designed" by someone with absolutely no clue about entities and relationships.
Take, for example, the database that I'm currently replacing. It's a music database so it models (amongst other things) artists and tracks. An artist has a number of associated tracks.
In my design, there is a table called "artist" and a table called "track". The artist table has a primary key and the track table has a column called "artist" which contains the key of the artist associated with that track.
In the original database[1] there was a table called artist. The track data was an attribute of the artist. And when I say "attribute" I mean that there was a column in the artist table called "track" which contained a comma separated list of the tracks associated with that artist.
But it gets worse. A track has attributes - the track name, the name of the MP3 file it is stored in and a boolean flag to indicate whether it has been approved by the A&R people. So the artist table needs three columns for the track-based data. The "track" column I mentioned before contains the filename. There are also columns called "track_name" and "track_approved". Each of them are comma separated lists of values.
And in some cases, the number of items in the three lists isn't the same.
This is a web-based system that was designed and implemented by another company for my current clients. People are being paid to design systems as badly as this.
Am I being too critical? I've been working with databases for far longer than I've been working with the web or Perl. Database normalisation is second nature to me. Is it too much to ask that people who are designing databases actually know something about... er... designing databases?
[1] Which was in Microsoft Access, but I'm not drawing any conclusions about the abilities of Microsoft users in general.
You're not being too critical. I expect to see such sloppy work out of CS students or new programmers, but it should never work it's way into the professional code.
Now that's what I think. The reality is, I have funny notions about software design. I think that professional software should have a test suite, preferably one that can also run on the end-users system. Many would argue that point with me. Few would argue that a test suite is a bad idea, but many might argue that it's not necessary ("I don't write bugs" or "I test it thoroughly by hand"). Further, I've been told that using templates and writing tests is "overengineering."
In a similar vein, I've had silly arguments with people who think that foreign key constraints and transactions aren't necessary because, as programmers, they want to have fine-grained control. They might be the sort who would argue that having a CSV list would mean one less join in the database and thus keep the schema simpler. How do you argue with "logic" like that?
Re:Not Too Critical
chromatic on 2004-04-02T17:51:22
A nice Louisville Slugger always helps.
Re:Not Too Critical
ethan on 2004-04-05T10:59:09
Now that's what I think. The reality is, I have funny notions about software design. I think that professional software should have a test suite
Test suites are not part of the "culture" everywhere. It appears to be a language-thing. Perl (as do other languages) come with frameworks to write tests. For other languages there appears to be no such standard. I've hardly ever seen a C library coming with a test suite. And the remarkable thing is: Most often they work splendidly. Maybe it's because a good C programmer's mind is trained to expect trouble everywhere so over the time he has developed skills and techniques to write robust code.
At least there are always things he double- and triple-checks before letting them pass because they otherwise bite back so easily.Re:Not Too Critical
TeeJay on 2004-04-05T14:47:48
Sorry but any IT gradudate should know normalisation. There is no excuse - any IT degree that doesn't cover the basics of normalisation (its not that hard, in fact once you've done a handful of exersizes you realize its pretty much common sense) is worthless.As for new programmers - again any course which teaches programming has to include some database design - name a single application since 1980 that didn't use some sort of database.
Re:Not Too Critical
davorg on 2004-04-06T06:31:40
I don't think I said anything about these people being graduates. I don't know for sure, but there seems to be no evidence to support that.Sorry but any IT gradudate should know normalisation. There is no excuse - any IT degree that doesn't cover the basics of normalisation (its not that hard, in fact once you've done a handful of exersizes you realize its pretty much common sense) is worthless.Re:Not Too Critical
TeeJay on 2004-04-06T09:11:36
I know. The reply I replied to mentioned Graduates not knowing Normalisation which is pretty shocking.mind you I have worked with graduates who it seemed forgot how to normalise databases. (i.e. they did it in wierd quirky ways to work better with VB or just used too many or too few tables).
Re:Not Too Critical
drhyde on 2004-04-06T09:19:05
name a single application since 1980 that didn't use some sort of database.mysql <gd&r>
I think that for the time being, it is our lot in life to discover and clean up such messes.
