Andre, >From a distant view of your problem I would like to vote for Thomas Kellerer's proposal: Maintain only the data you need (to enhance import/sync performance) and use the hstore data type (as long as query performance is ok).
Yours, S. 2011/1/3 Fredric Fredricson <fredric.fredric...@bonetmail.com>: > > On 01/03/2011 12:11 PM, Andre Lopes wrote: >> >> [snip] >> The problem with this task is that the information is not linear, if I try >> to design tables with fields for all possible data I will end up with many >> row fields with NULL values. There are any problem with this(end up with >> many row fields with NULL values)? Or should I user other kind of structure? >> For example store the data in one field and that field containing an >> associative array with data. > > As far as I understand NULL values are not really stored and a column with > many NULLs is not a problem as such, but if it is part of an index the index > might not be very useful. > > At least that's my understanding of how SQL databases work. If I got this > wrong I hope someone will correct me. >> >> [snip] > > /Fredric > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > > -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
