Plik zip zawiera kilka plików:
Nadmuchiwanie 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
z których każdy wydaje się być w dziwacznym formacie podobnym do CSV, np. NUTR_DEF.txt :
~287~^~g~^~GALS~^~Galactose~^~2~^~2100~
~291~^~g~^~FIBTG~^~Fiber, total dietary~^~1~^~1200~
plus sr26_doc.pdf , dokumentacja.
Tworzenie definicji tabeli
To, co musisz tutaj zrobić, to utworzyć definicje tabel SQL dla bazy danych - z jedną tabelą dla każdego pliku wejściowego. Potrzebujesz CREATE TABLE polecenie do tego; zobacz dokumentację PostgreSQL.
Strona 35 PDF powinna ci pomóc – „Rysunek 1. Powiązania między plikami w USDA National Nutrient Database for Standard Reference”. Kolejne strony opisują formaty plików, informując, co oznaczają poszczególne kolumny. Możesz napisać CREATE TABLE oświadczenia oparte na tym opisie.
Oto przykład dla FOOD_DES.txt (opis jedzenia), pierwszy wpis.
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)
);
To całkiem dosłowna kopia opisu. Nie tak zaprojektowałbym stół
Użyłem NUMERIC dziesiętne typy zmiennoprzecinkowe o dowolnej precyzji w celu zapewnienia dokładności w niecałkowitych typach liczbowych. Jeśli wydajność jest ważniejsza niż dokładność, możesz użyć float4 zamiast tego.
W przypadku relacji używasz FOREIGN KEY ograniczenia - po prostu colname coltype REFERENCES othertable(othercol) wystarczy, aby go stworzyć.
Ważne :Podwójnie zacytowałem nazwy kolumn, aby zachować tę samą nazwę, co w definicjach. Oznacza to, że zawsze musisz je dwukrotnie cytować, kiedy się do nich odwołujesz, np. SELECT "NDB_No" FROM food_des; . Jeśli tego nie chcesz, po prostu pomiń podwójne cudzysłowy - lub wybierz inne nazwy. Nie musisz trzymać się niezgrabnych skróconych nazw kolumn, których używali, i całkiem rozsądne jest napisanie:
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),
itp. Podobnie, jeśli pracujesz z Railsami, możesz przekonwertować definicje tabel, aby były zgodne z konwencjami Rails, zwłaszcza jeśli zamierzasz następnie ładować dane przez Rails.
Ładowanie danych
Jeśli byłyby to rozsądne, rozsądne pliki rozdzielane, możesz po prostu załadować każdą tabelę za pomocą psql polecenie \copy , lub opcja „Importuj” w PgAdmin-III.
W rzeczywistości jest to CSV, właśnie zdecydowali się użyć całkowicie dziwacznego ogranicznika i cytować znaki. Importuj przez psql z:
\copy food_des FROM 'FOOD_DES.txt' (FORMAT CSV, DELIMITER '^', QUOTE '~');
lub odpowiednik w dowolnym narzędziu używanym do komunikacji z PostgreSQL.
Wyniki są rozsądnie wyglądającą 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)
Podobnie, jeśli używasz Railsów, możesz użyć dowolnej biblioteki Rails CSV i zbiorczo ładować do modeli.
