Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by autarch (914) on 2005.10.20 22:12 (#44064) Homepage Journal
    The real world is not hierarchical. Some parts of it are, some aren't. A system like MV which only lets you express hierarchical relationships is not going to be a better model of the real world than a SQL system.

    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.