Zip'en indeholder et antal filer:
inflating: DATA_SRC.txt
inflating: DATSRCLN.txt
inflating: DERIV_CD.txt
inflating: FD_GROUP.txt
inflating: FOOD_DES.txt
inflating: FOOTNOTE.txt
inflating: LANGDESC.txt
inflating: LANGUAL.txt
inflating: NUT_DATA.txt
inflating: NUTR_DEF.txt
inflating: sr26_doc.pdf
inflating: SRC_CD.txt
inflating: WEIGHT.txt
som hver især ser ud til at være i et bizart næsten-CSV-lignende format, f.eks. NUTR_DEF.txt :
~287~^~g~^~GALS~^~Galactose~^~2~^~2100~
~291~^~g~^~FIBTG~^~Fiber, total dietary~^~1~^~1200~
plus sr26_doc.pdf , dokumentationen.
Oprettelse af tabeldefinitioner
Så det, du skal gøre her, er at oprette SQL-tabeldefinitioner til databasen - med en tabel for hver inputfil. Du skal bruge CREATE TABLE kommando til dette; se PostgreSQL-dokumentationen.
Side 35 i PDF'en skulle hjælpe dig - "Figur 1. Relationer mellem filer i USDA National Nutrient Database for Standard Reference". De følgende sider beskriver filformaterne og fortæller dig, hvad hver kolonne betyder. Du kan skrive CREATE TABLE udsagn baseret på denne beskrivelse.
Her er et eksempel på FOOD_DES.txt (madbeskrivelse), den første post.
CREATE TABLE food_des (
"NDB_No" varchar(5) NOT NULL PRIMARY KEY,
"FdGrp_Cd" varchar(4) NOT NULL,
"Long_Desc" varchar(200) NOT NULL,
"Shrt_Desc" varchar(60) NOT NULL,
"ComName" varchar(100),
"ManufacName" varchar(65),
"Survey" varchar(1),
"Ref_desc" varchar(135),
"Refuse" smallint,
"SciName" varchar(65),
"N_Factor" NUMERIC(4,2),
"Pro_Factor" NUMERIC(4,2),
"Fat_Factor" NUMERIC(4,2),
"CHO_Factor" NUMERIC(4,2)
);
Det er en ret bogstavelig kopi af beskrivelsen. Det er ikke sådan, jeg ville designe bordet
Jeg har brugt NUMERIC vilkårlig præcision decimal flydende komma typer for nøjagtighed i ikke-heltal numeriske typer. Hvis ydeevne er vigtigere end nøjagtighed, kan du bruge float4 i stedet.
Til relationer bruger du FOREIGN KEY begrænsninger - bare colname coltype REFERENCES othertable(othercol) er tilstrækkeligt til at oprette en.
Vigtigt :Jeg citerede kolonnenavnene dobbelt for at bevare det samme navn som i definitionerne. Det betyder, at du altid skal dobbeltcitere dem, når du henviser til dem, f.eks. SELECT "NDB_No" FROM food_des; . Hvis du ikke ønsker det, skal du bare udelade de dobbelte anførselstegn – eller vælge andre navne. Du behøver ikke holde dig til de klodsede forkortede kolonnenavne, de brugte, og det er ganske rimeligt at skrive:
CREATE TABLE food_description (
ndb_no varchar(5) NOT NULL PRIMARY KEY,
foodgroup_code varchar(4) NOT NULL,
long_description varchar(200) NOT NULL,
short_description varchar(60) NOT NULL,
common_name varchar(100),
manufacturer_name varchar(65),
osv. På samme måde, hvis du arbejder med Rails, kan du konvertere tabeldefinitionerne til at følge Rails' konventioner, især hvis du derefter har til hensigt at foretage dataindlæsningen via Rails.
Indlæser data
Hvis disse var fornuftige, fornuftige afgrænsede filer, kunne du bare indlæse hver tabel ved hjælp af psql kommando \copy , eller PgAdmin-III's "import" mulighed.
Det er faktisk CSV, de har lige besluttet at bruge helt bizarre afgrænsningstegn og citattegn. Importer via psql med:
\copy food_des FROM 'FOOD_DES.txt' (FORMAT CSV, DELIMITER '^', QUOTE '~');
eller tilsvarende i det værktøj, du bruger til at tale med PostgreSQL.
Resultaterne er en fornuftig tabel:
craig=> select * from food_des limit 2;
NDB_No | FdGrp_Cd | Long_Desc | Shrt_Desc | ComName | ManufacName | Survey | Ref_desc | Refuse | SciName | N_Factor | Pro_Factor | Fat_Factor | CHO_Factor
--------+----------+----------------------------+--------------------------+---------+-------------+--------+----------+--------+---------+----------+------------+------------+------------
01001 | 0100 | Butter, salted | BUTTER,WITH SALT | | | Y | | 0 | | 6.38 | 4.27 | 8.79 | 3.87
01002 | 0100 | Butter, whipped, with salt | BUTTER,WHIPPED,WITH SALT | | | Y | | 0 | | 6.38 | 4.27 | 8.79 | 3.87
(2 rows)
På samme måde, hvis du bruger Rails, kan du bruge det Rails CSV-bibliotek, du vil, og masseindlæse i modeller.