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.Fredricson@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
>
>