From: | Tim Cross <theophilusx(at)gmail(dot)com> |
---|---|
To: | a <372660931(at)qq(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Ways to deal with large amount of columns; |
Date: | 2018-08-30 22:24:28 |
Message-ID: | 87a7p3ijc3.fsf@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
a <372660931(at)qq(dot)com> writes:
> Hi all:
>
>
> I need to make a table contains projected monthly cashflow for multiple agents (10,000 around).
>
>
> Therefore, the column number would be 1000+.
>
>
Not sure your data model is correct. Typically, with something like
this, increasing the number of agents would result in tables with more
rows rather than more columns. Tables with large numbers of columns is
often a 'code smell' and indicates the underlying data model needs to be
reviewed. Designs which result in new columns being required because you
are adding new data sources is almost certainly an indication of the
need to review the data model.
Postgres (and many other databases) have lots of functionality to help
deal with tables that have large numbers of rows, but working with
tables that have large numbers of columns has less functionality and
options.
While it is very tempting to create a table and then start coding, you
will almost always get a much better result and simpler code if you
spend some initial time to really analyse your domain, understand the
data elements and how they relate to each other, map them out into a
data model and then start development. Have a look at
https://en.wikipedia.org/wiki/Database_normalization for some background
on the normal forms and why they are useful.
HTH
Tim
--
Tim Cross
From | Date | Subject | |
---|---|---|---|
Next Message | a | 2018-08-31 00:46:07 | Re: Ways to deal with large amount of columns; |
Previous Message | David G. Johnston | 2018-08-30 20:51:29 | Re: searching a value in a variable/field in all tables in a schema |