NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Larry Wall in perl.c from the perl source code
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Huh? (Score:2)
Your schema reflects your business rules. If you require that all customers have an address, there should be a constraint to this effect. If customers can have more than one address, I'm sure you know quite well how to model that as well.
Also, SQL is not relational. It's a poor second cousin of relational, and it does suck. Imagine that you had a richer constraint language so you could easily specify constraints on the database as a whole (aka across multiple tables). Given that, you could very easily allow for each customer to have more than address, and require that they always have at least one. Similarly, you could easily require that each address have a customer.
Of course, this also requires the ability to clearly define the boundaries at which constraints are checked. The nice way to do this is to allow for multiple statements at once:
UPDATE
DELETE
INSERT
;
If constraints are checked at the semi-colon, you can satisfy complex constraints across multiple tables and easily write DML code that will not violate them.
Conceptually, this is pretty trivial, but I still haven't seen an RDBMS that really supports this stuff well. I've mostly used Postgres and MySQL, which both do suck. But my experience with Sybase, SQL Server, and Oracle has suggested that they all suck too, just more powerfully.
Reply to This