Thats alot of columns you might want to normalise your data before settling on any feeding a fixed DB schema
http://www.datamodel.org/NormalizationRules.html 1) Are there any repeating patterns? such as Repeating Groups or Redundant data e.g. OrderLineItem1...OrderLineItem2 splitting the grouping of (related data points) such as OrderLineItems to a new table would allow you to creating a unique key such as OrderLineItemID (foreign key in your table) to point to uniquely access only the related data points from your new table 2) Are there any data columns that do not necessarily absolutely belong in the data? I once worked with Patient Data where someone put Patient phone number in Diagnosis (Patient's diagnosis has nothing to do with their phone unless the bill is off the charts) Diagnosis belongs with Patient DRG code and Diagnostic Physician Name Patient Phone number is more closely associated with Contact record for that Patient Up front schema design is vital and necessary activity for ensuring you know how your data can be aggregated into functional groups before 1)Any Database/Table Creation (or any DB entity is created) 2)Any data Feeds from external sources or Form Population to your new DB entities take place.. HTH Martin ______________________________________________ Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung / Note de déni et de confidentialité This message is confidential. If you should not be the intended receiver, then we ask politely to report. Each unauthorized forwarding or manufacturing of a copy is inadmissible. This message serves only for the exchange of information and has no legal binding effect. Due to the easy manipulation of emails we cannot take responsibility over the the contents. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. From: ge...@tbstbs.net To: pgsql-general@postgresql.org Subject: [GENERAL] Maximum number of columns in a table Date: Sun, 12 Apr 2009 05:33:35 +1000 The FAQs state "Maximum number of columns in a table? 250-1600 depending on column types". Is there a location which gives instructions for calculating whether a number of columns of different types can be accommodated? I have a situation where I need to load tables from another database which may theoretically contain up to 1000 columns per table and this information will determine whether I need to rebuild PostgreSQL with a larger blocksize. Splitting into multiple tables is not always an easy option. Many thanks Gerry __________ Information from ESET NOD32 Antivirus, version of virus signature database 4001 (20090411) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com _________________________________________________________________ Rediscover Hotmail®: Get quick friend updates right in your inbox. http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates1_042009
