![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Working on the SQL
Crowdsourcing my brain....
I am looking for a good introduction to sensible relational database design.
I have written Perl to interface with databases; I am happy with constructing reasonably simple SQL queries and can, with a bit of headdesking, understand the seriously mangled SQL which makes the course booking system work; but I have never built a complex database (ie anything much above "hello world" kind of level) from scratch.
Pretty much everything I know about databases has been inferred from querying them in one way or another, usually in fairly narrow ways; I feel a bit like two and a half blind men with approximately three eighths of an elephant (<pred>but where can I get one at this time of night?</pred>), and I am worried that my incomplete understanding will result in me getting trampled on by the elephant sooner or later.
What I want is to be able to look at a moderately complex database and, with some poking around (hopefully knowing what I was looking for!), understand a) how it all interlinks, and b) whether if I was building it again from scratch I would change it. I suspect that the latter will probably be partly a question of personal style.
I'm not really expecting clear rules about what makes a sensible database (though that would be nice), so much as something that will point me towards 'best practice' or at least 'how to avoid tying oneself in unspeakable knots'.
I would also like to know how people who do understand databases describe them, document them, map them so that the representation of them a) makes sense to normal people, and b) is unambiguous toabnormal people anybody who's dealing with the back end of the database (which is, I fear, a bit like the back end of an elephant). I suspect there will be more than one right answer to a) and/or b).
I have a map on my wall of how our course booking database works, though it's only the basic tables and not all the complicated logic. I suspect this is not how real people draw database structures.
Any suggestions, comments, constructive ridicule etc gratefully received.
I am looking for a good introduction to sensible relational database design.
I have written Perl to interface with databases; I am happy with constructing reasonably simple SQL queries and can, with a bit of headdesking, understand the seriously mangled SQL which makes the course booking system work; but I have never built a complex database (ie anything much above "hello world" kind of level) from scratch.
Pretty much everything I know about databases has been inferred from querying them in one way or another, usually in fairly narrow ways; I feel a bit like two and a half blind men with approximately three eighths of an elephant (<pred>but where can I get one at this time of night?</pred>), and I am worried that my incomplete understanding will result in me getting trampled on by the elephant sooner or later.
What I want is to be able to look at a moderately complex database and, with some poking around (hopefully knowing what I was looking for!), understand a) how it all interlinks, and b) whether if I was building it again from scratch I would change it. I suspect that the latter will probably be partly a question of personal style.
I'm not really expecting clear rules about what makes a sensible database (though that would be nice), so much as something that will point me towards 'best practice' or at least 'how to avoid tying oneself in unspeakable knots'.
I would also like to know how people who do understand databases describe them, document them, map them so that the representation of them a) makes sense to normal people, and b) is unambiguous to
I have a map on my wall of how our course booking database works, though it's only the basic tables and not all the complicated logic. I suspect this is not how real people draw database structures.
Any suggestions, comments, constructive ridicule etc gratefully received.
no subject
Again, I can't really think of a single good text on database design. If you ask, somebody will usually crop up and say Date's Introduction to Database Systems (http://www.amazon.co.uk/Introduction-Data-Base-Systems-Pie/dp/0321189566/) - it's the classic reference in the field, however it's not a terribly good tutorial.
Understand normalisation (http://en.wikipedia.org/wiki/Database_normalization), understand why a design being 3NF (http://en.wikipedia.org/wiki/Third_normal_form) is worth aiming for, and only then think about breaking the rules.
no subject
no subject