"I need gather data into one table for consistency and easy for export and
import, it's ok if I split data to smaller tables, but when
export/import/update, i must excute query on alot of table. And this way
lead data to inconsistency if I forget update/export/import on 1 or more
table. It is terrible."
That statement is wrong on many levels:
- Easy for import and export...
- Multiple tables / one table are identical for import export
purposes.
- export/import/update, i must excute query on alot of table.
- That's what SQL is for...
- lead data to inconsistency if I forget update/export/import on 1 or
more
table. It is terrible.
- You build your process once and test it... Additional runs of the
process are 'free'...
And as someone else mentioned, the 34 indexes are additional tables anyway.
There is probably a way to optimize your current system... There often is
no matter how horrible the implementation...
But I would start by normalizing that as much as possible and then running
performance tests against a normalized jobs. There's lots of tools to do
that... But they probably aren't much help with your current schema.
Gary
On Wed, Mar 25, 2015 at 7:43 AM, Adrian Klaver <adrian.kla...@aklaver.com>
wrote:
> On 03/25/2015 07:30 AM, ginkgo36 wrote:
>
>> @Gary
>> I'm working on big data, because of the demands of the job so I
>> export/import/update data on this table every day.
>>
>> I guess it's possible that each query would need all 417 columns but it
>> seems unlikely... --> Yes, not at all but 2/3 of 417 columns :)
>>
>
> There is also the matter of the 34 indexes, which can thought of as 34
> axillary tables that need to be kept in sync with the main table.
>
>
>> I need gather data into one table for consistency and easy for export and
>> import, it's ok if I split data to smaller tables, but when
>> export/import/update, i must excute query on alot of table. And this way
>> lead data to inconsistency if I forget update/export/import on 1 or more
>> table. It is terrible.
>>
>>
>> @John
>>
>> I will learing about it. Thanks alot.
>>
>> @All: If you have any suggestion, please let me known. Thanks for you help
>>
>>
>>
>>
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
