Search Postgresql Archives

explosion of tiny tables representing multiple fields--Is this necessary?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear PostGreSQL experts,


I am working with text objects. A text object will have lots of fields that 
are potentially multiple. There may be more than one author, more than one 
modern editor, more than one edition number, etc.

These potentially multiple fields are, in my schema, nothing more than 
strings. 

For my purposes, multiple strings of this kind would consist of 
composed/aggregated objects stored as a member in an instance of a 
MyTextObject. The member would be some kind of collection. Like this:


 
public Class MyTExtObject
 
Vector authors;  //simple String for author name
Vector editionNumbers;  //simple string for editionNumber 
...
 

}//MyTextObject
 


My question: is there any legitimate way around creating lots of tiny tables, 
one for each multiple field, when the multiple fields are nothing more than 
strings?

We will be doing lots of involved queries, and although I have a fair amount 
of experience with SQL, this profusion of tables would be a pain to implement. 
But I don't see any way around creating them when the relation between the 
MyTextObject and the various fields is one-to-many. 




-- 
Benjamin Weaver
Faculty Research Associate, Imaging Papyri Projects, Herculaneum Society, 
Oxford
email:  benjamin.weaver@xxxxxxxxxxxxxxxxx
phone:  (0)1865 288260



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux