Inheritance & multiple-value fields
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?
Thanks for your information.
Vernon
____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005
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 |
+-----------------------------------------------------------------+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 product at 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.htmlHowever, 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?
____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005
Import Notes
Resolved by subject fallback
On Sat, 2003-08-02 at 18:55, Vernon Smith wrote:
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 product at
this moment.
You asked about "multi-valued field table". That looks like a
construct that is against the "rules" of relational database
design. So, since PG doesn't support that feature, I told you about
a product that does do multi-valued fields. What's the problem?
I was being helpful.
--
+-----------------------------------------------------------------+
| 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 |
+-----------------------------------------------------------------+--
--------- Original Message ---------
DATE: 03 Aug 2003 02:27:08 -050
From: Ron Johnson <ron.l.johnson@cox.net>
To: pgsql-general@postgresql.org
Cc:
On Sat, 2003-08-02 at 18:55, Vernon Smith wrote:
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 product at
this moment.You asked about "multi-valued field table". That looks like a
construct that is against the "rules" of relational database
design. So, since PG doesn't support that feature, I told you about
Relation DB has its way to handle multi-valued field.
a product that does do multi-valued fields. What's the problem?
What is the problem of my previous email?
I was being helpful.
Did I say "thank you"? Yes, I did.
-- +-----------------------------------------------------------------+ | 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 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005
Import Notes
Resolved by subject fallback
On Sat, 2 Aug 2003, 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?
The SQL 3 standard has an enumerated type listed in it, but I don't think
it's likely to show up in Postgresql any time soon. you can approximate
these using a check in() constraint.
Or are you looking at more than one value in the same field? In that
case, arrays are a way to do that.
both enumerated types and arrays break the strict relational model, but
sometimes they're the simpler, cleaner soltution.