[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Martijn Grooten wrote: > On Thu, Jun 25, 2009 at 8:10 PM, Simon Waters wrote: >> What's the reason for your interest? > > Mostly curiosity, combined with the fact that I use databases > regularly for work and I know enough I need to know to do my job, but > not much more. And I quite like to know why certain things work (well) > and others don't work (as well), rather than having read a book that > just told me to believe it. But having read a few things here and > there, I am a bit worried that after reading about how relational > databases really work, I'll end up thinking they're a daft idea in the > first place. :-) I think your more likely to come away thinking that SQL, and relational databases never really (or only lately) implemented a load of things they should have done early on. The particular bug bear I use as an example is hierarchical relationships (think database of human relationships - find all descendants of Joe Smith, where each record is a name, ID, and a table mapping ID to parent IDs, which you'd think something called a "relational" database would be especially good for. But you find that implementations are incomplete and inconsistent, and recursive queries are few and far between. More generally SQL never really lived up to being a standard, I suspect if it had, then it would have been more aggressively developed. But I guess it saps the motivation of a standards committee if hardly anyone implements what you recommend. I spent ages the other day trying to debug a SQL statement giving me a silly error, and even a fresh pair of eyes didn't spot it immediately, then we realised that this particular SQL variant uses a different string concatenation operator to what I'd typed (argh). > Perhaps I should just dig into TAOCP TAOCP is largely an algorithm reference. So very useful when you want to know how to efficiently sort a list that is already partially sorted. On the other hand for a dry reference work it has more wry humorous comments than most. When I got the bug about databases, it was because I knew the ones I was working with weren't done well. So I stumbled into reading about database normalization (lack of which was the obvious problem), which was interesting, as there is a load of common-sense ideas which maps to some interesting theoretical underpinnings. But where the stuff dove off into relational algebra and such my undergraduate maths wasn't much help (I should have done pure maths clearly) and quickly lost me. That said I never got into doing complex data queries, sometimes I've had to optimize databases for complex queries, or optimise complex queries for a database, but I've nearly always had my system administration hat on, not a database developer hat on. I wrote my own implementation of cursors inside an application once for a database that didn't have it, I think that qualifies me only for the first step to being a database developer. Step two is probably to refuse to work on any more projects using that database backend ;) If so I qualify on step 2 as well. But there are others here who know far more about this stuff. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html