The relation way to this imho is:
Basically what you are already doing, however I would have a field language which references a language table or a
checkand have all the different languages in one table. My main point is however that it should be the entities (books,
e-booksetc.) that references the description - not the other way around, if you need a select which returns all the
differentdescriptions for the different entities and knows what is what use a union select the other option is to use
aninherit clause - this would allow to do more or less what I believe you had originally planned. - However I due to
severallimitations (especially that it does not inherit constraints) in the inheritance system I would very much
recommenddoing it the other way. Also consider making a view of the complicated select and you are well on your way.
regards,
Aasmund.
On Tue, 23 Oct 2001 05:10:33 -0700 (PDT), Andrew Gould <andrewgould@yahoo.com> wrote:
> If your books, ebooks, etc are in one table, why can't
> the descriptions be in one table? The primary key
> would be the unique item id from your original table.
> You could have a columns for item id (the primary
> key), item type (book, ebook, etc) and a separate
> description column for each language. Would this work
> for you?
>
> Best of luck,
>
> Andrew
>
> --- "Johnny_Jørgensen" <johnny@halfahead.dk> wrote:
>
>
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Aasmund Midttun Godal
aasmund@godal.com - http://www.godal.com/
+47 40 45 20 46
