Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: One Ring to Bind Them

Re: One Ring to Bind Them

From: Anthony W. Youngman <wol_at_thewolery.demon.co.uk>
Date: Fri, 25 Jun 2004 23:42:04 +0100
Message-ID: <iG6fafc8oK3AFwnI@thewolery.demon.co.uk>


In message <bcb8c360.0406210607.424faf2e_at_posting.google.com>, Tony Douglas <tonyisyourpal_at_netscape.net> writes
>"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
>news:<j$hPkhMcm30AFwso_at_thewolery.demon.co.uk>...
>
><snip>
>
>> Actually, I've just reread what you wrote. Do you mean "constraint" as
>> in a relational constraint - foreign-key type stuff; or as a general
>> term for enforcing integrity. I was thinking the latter, hence my
>> reference to triggers, but I suspect you might be meaning the former. If
>> you did mean the former, Pick doesn't have them because it achieves the
>> same effect as a side-effect of its implementation. So the fact that
>> relational needs them is de-facto a hindrance relative to Pick.
>>
>
>Additionally, with regards to your last point - how does Pick have
>"foreign-key type stuff" as a "side-effect of its implementation" ? Is
>this down to its multi-valuedness ? What happens if you use Pick in
>faux-relational mode - do you just lose this kind of constraint ?
>

If by "faux relational", you mean splitting a normal-form FILE into a bunch of first-normal-form FILEs, then yes, we do lose this constraint (in MV mode, anyway. Any modern MV will let you declare a relational constraint, but you are now invoking a load of code (and overhead) to do what would have happened naturally).

Because, in MV, a "cell" can itself contain a "column", imagine the "colour" column for a car. It can contain a list of colours, and deleting a car's "row" will take out the list of colours. In relational, that list would be in a different table and would require a constraint, that would effectively have to do a select followed by a multi-row delete.

So while we need a transaction mechanism to update an accounts system because we need to update the bank, the customer file, the general ledger, and other stuff besides in one hit; we do NOT need a transaction mechanism to eg delete a car, because in MV, "delete car" is atomic (I'm being a little unfair here because we ought to update owner and do a few other things as well, which might need a transaction). But the point is, if it's atomic in the real world, it should be atomic in an MV database. A relational database has to assume it's not atomic, because 9 times out of 10 normalisation means it can't be.

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999
Received on Fri Jun 25 2004 - 17:42:04 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US