Why schemas and not code?

[Tim Sweetman]

Adrian Howard wrote:

>
> On 26 Jun 2006, at 10:02, Ovid wrote:
> [snip]
>
>> This brings me to the question I can't figure out:  why is it that  
>> otherwise competent programmers who admit that their code is a mess  
>> fail to see that their databases might be also?  Since they can  
>> describe virtually nothing about relational theory, one might  assume 
>> (incorrectly) that they might realize they have a weakness  there.
>
> [snip]
>
> I think it's down to three issues:
>
> First doing databases "right" - relational theory yada yada - is a  
> substantially different way of thinking about data than many people  
> are used to. Like trying to convince an OO fanatic of the advantages  
> of functional programming (or vice versa) - changing paradigms is  
> hard. Until you can flick that switch in your head and look at things  
> from a different perspective you can't actually see why the database  
> is a mess.
>
> Second - the depressing approach many programmers seem to have of  
> wanting to specialise themselves into oblivion... "I'm a programmer.  
> No I'm a Perl programmer. No I'm a Perl 5 programmer. No I'm a Perl 5  
> programmer writing web applications. No I'm a Perl 5 programmer  
> writing web applications with TT2 and Class::DBI. Why should I need  
> to learn about customers/usability/databases/whatever to do my job.  
> It's not going to make me  a better Perl 5 programmer".
>
> Third is the attitude of some (or on a bad day "many") of the people  
> on the database side who seem determined to alienate any potential  
> converts by treating anybody who can't recite The Word According To  
> Date backwards while drinking a glass of water as incompetent fools  
> who are not fit to /think/ about using a database. The worst of the  
> database crowd are like the worst of the Lisp/Smalltalk/FP/Agile  
> crowds. They don't seem to want to communicate or educate. They just  
> want to rant about how much better their way is.

... and then, on the other hand, you get things like this:

http://www.dabbledb.com/utr/

I have no idea what that's like "under the hood", but I'm damn impressed 
by the way you can take a typical spreadsheet and start turning repeated 
data into foreign keys!

One real problem with relational databases as currently implemented is 
that, as a rule, it's easier to do it wrong than right. Much easier.
Creating a simple table with "artist" as a varchar is a doddle.
Turning "artist" into a foreign key on an artists table is simply more 
work, with no immediate return on investment. More work still, if you 
want the "artist" table to automatically populate itself when a new 
artist appears; still more if you want to be able to rename an artist 
(say, from "Alanis Morisete" to "alanis morissette") and have the change 
cascade, or refer to abstract numeric keys instead.
And before you know it, you've got tables & triggers and maybe views and 
INSTEAD OF INSERT triggers, and INSTEAD OF UPDATE triggers, and you're 
having to name every field explicitly every time, and change three 
things instead of one whenever you change your table. Can you explain 
the purpose of that to a pragmatic technical lead? "It's four or five 
times the work, for no gain".

I eventually found a solution to my "genre" woes on iTunes. iTunes 
decides most of what I listen to is "Alternative/Punk" (!?). Conversely, 
"music for airports" is "Electronica/Dance" (How can you dance to "music 
for airports"? By being a snail?), as is lemonjelly. So is Fatboy Slim. 
Erm...

What's needed is a one-to-many relationship. Songs can be of many 
genres; perhaps a tenth Country to nine-tenths Electronica. Failing 
that, tags would be nice, but, hey, Apple haven't done that. I don't 
believe I've seen any other music player with a more developed concept 
of genre, either.

Kludge: Start labelling things with genres like "Electronica/Chilled" 
(most of lemonjelly), "Alternative/Punk/Disturbing" (louder or scarier 
Tori Amos), "Ambient/IfYou'reLemmyFromMotorhead" (most "ambient" music 
-- tsk). You can then use "contains" (substring match) operators to 
build some fairly smart smart playlists.

Sorted. No more rides of valkyries charging through quiet, baroque 
interludes. They put all the harpsichords out of tune when they do that. 
And yes, you may call me pathologically eclectic.

ti'