Thanks for your input, Ron.
My question, however, is addressed to PG only since this is PG mailing list. I have no interest to buy another DB
productat this moment.
My question can be stated in the other way: why the data in the sub-table is visible, but not referable?
Here is my example:
Table A ( id int, ... )
Table B ( ... ) inherits (A)
Table A1 ( id int REFERENCES A ON DELETE CASCADE, ...)
A selecting operation can retrieve data in the table B, but an inserting operation can't refer a key in the table B.
--
--------- Original Message ---------
DATE: 02 Aug 2003 17:09:12 -050
From: Ron Johnson <ron.l.johnson@cox.net>
To: pgsql-general@postgresql.org
Cc:
>On Sat, 2003-08-02 at 15:26, Vernon Smith wrote:
>> We usually use another table for a multi-valued field. Is possible
>> having a single multi-valued field table for all tables in the
>> same heredity, other than having a multi-valued table for every
>> single tables in the heredity?
>
>Sure: Pick, now known as D3.
>http://www.rainingdata.com/products/dbms/d3/index.html
>
>However, that breaks the cardinal rule of relational DB design:
>http://www.databasejournal.com/sqletc/article.php/26861_1428511_4
>
>--
>+-----------------------------------------------------------------+
>| Ron Johnson, Jr. Home: ron.l.johnson@cox.net |
>| Jefferson, LA USA |
>| |
>| "I'm not a vegetarian because I love animals, I'm a vegetarian |
>| because I hate vegetables!" |
>| unknown |
>+-----------------------------------------------------------------+
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005
