[SQL] Struktura tabeli z różnymi typami wartości Opcje

[epg.kojak]

Witam,

mam pewien problem związany z optymalizacją struktury bazy danych. Postaram się dokładnie to wytłumaczyć.

Tworzę pewien projekt, gdzie będzie można dodawać różne wartości, jednak będą one odzworowane jako różny typ kolumn w bazie (np. int, double, varchar). Jak najlepiej zapisywać te różne wartości w bazie. W projekcie używam Propel 1.6. Chodzi o to, że mogę dodawać wartość typu 'int' lub 'varchar' itd, aby przeszukiwanie tabeli było wydajne.

W sumie mam dwa pomysły. Pierwszy to stworzenie tabeli "value", która będzie miała kolumny: "id", "value_int", "value_double", "value_varchar", itd - z odpowiednimi typami kolumn. W zależności od typu wartości, rekordy będą zapisywane z wartością w odpowiedniej kolumnie (w reszcie będzie NULL).

Drugie rozwiązanie to stworzenie osobnych tabel, np. "value_int", "value_varchar" itd. Tu by były kolumny: "id", "value", które odpowiadałyby odpowiednim typom dla "value" (czyli, np. int, varchar, itd).

Nie ukrywam, że nie mam przekonania do żadnego z powyższych rozwiązań, pierwotnie zastanawiałem się nad jedną tabelą "value", gdzie kolumna byłaby typu "text" - jednak to rozwiązanie byłoby chyba jeszcze gorsze.

Chciałbym poznać Wasze zdanie na ten temat, może coś innego byłoby lepsze. Z góry dzięki.

|| edit:
prośba o przeniesienie do działu "Bazy danych" - drobna pomyłka (IMG:style_emoticons/default/wink.gif)

Ten post edytował phpion 7.11.2013, 11:14:45

Powód edycji: [phpion]: Przeniosłem.

[phpion]

Robiłem kiedyś coś podobnego, źródła dla Kohany masz tutaj:
http://forum.webmastah.pl/topic/2285-k2-dict-dane-sownikowe/
W Twojej tabeli VALUE kolumna value jest typu TEXT żeby móc przyjąć dowolne wartości. Cały myk polega na tym, że na podstawie danych słownikowych w locie budujesz widok (lub tabelę, ale widok zawsze zawiera aktualne dane) na zasadzie N JOINów wszystkich kolumn zawartych w słowniku rzutowanych na konkretny typ danych (poprzez CAST()) determinowany przez typ pola (u Ciebie FIELD.type). W efekcie otrzymujesz dane jakby z normalnej tabeli. Możesz wyszukiwać, dołączać inne tabele czy słowniki itd. Dodatkowo masz transparentość danych tj. możesz wstawiać dane do słownika jakby były normalną tabelą. Potrzeba do tego nakładki wstawiającej dane do tabeli VALUE, ja skorzystałem z ORM, który mapuje mi nazwa kolumny = ID kolumny z tabeli FIELD). Wydajność raczej nie będzie powalająca, ale zależy do czego chcesz to wykorzystać.