Обсуждение: 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 tablesin 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 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
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
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.