[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.

[epg.kojak]

Korzystam w projekcie z ORM (Propel), ale właśnie wydajność wydaje mi się sprawą kluczową. Bo dużo rekordów będzie w tej tabeli. Ogólnie chcę pobierać jakieś obiekty (dane) z bazy z przypisanymi do nich atrybutami i wartościami. Te wartości mogą być różne: varchar, int, float, double itp, czasem będzie trzeba posortować po odpowiednich kolumnach. Nie chciałbym wszystkiego wrzucać do pola "TEXT", bo może być potrzebne typu Varchar(255) lub Tinyint(1). Ogólnie zależy mi na wydajności, bo przecież mógłbym zrobić kolumnę VALUE o typie TEXT, i po kłopocie. Chciałbym, żeby było to jak najbardziej optymalne rozwiązanie, pod względem szybkości i wydajności. Bo gdy będą skomplikowane operacje, to rozbicie wartości na różne kolumny może nie przynieść spodziewanych rezultatów i mogę zostawić jak jest.

|| edit:

W sumie wcześniej nie korzystałem z funkcji CAST (i CONVERT). Z tego co widzę to mogę ją wykorzystać. Czyli np. zrobić pole typu TEXT i konwertować pola na odpowiednie, w zależności od potrzeb, tak?

Ten post edytował epg.kojak 7.11.2013, 13:20:49