FAQ |
Kalender |
![]() |
#11 | ||
|
|||
Flitig postare
|
OK, så förslag nr 2 kommer ge problem om attributvärdena kan vara både strängar och numerer eftersom de lagras i samma kolumn. Det kommer knappast gå att flytta type-castningen till scriptspråket då det kommer ske typecast i näsan varenda fråga, tex "alla bilar med fler än 200 hästar".
Kanske man skulle ha tvåan som grund och sedan skapa en tabell enligt modell nr 3 som hjälptabell? |
||
![]() |
![]() |
![]() |
#12 | |||
|
||||
Mycket flitig postare
|
Citat:
(Vilket även har fördelen att du på en gång vet att attribut som finns i numreriskaAttributVärden kan jämföras numreriskt.) |
|||
![]() |
![]() |
![]() |
#13 | ||
|
|||
Flitig postare
|
Ja det var ett bra förslag!
|
||
![]() |
![]() |
![]() |
#14 | |||
|
||||
Flitig postare
|
Finns en hel del som sagts om Entity-Attribute-Value-modellen som du antagligen vill läsa innan du gräver dig ett alldeles för djupt hål:
http://en.wikipedia.org/wiki/Entity-Attrib...ute-Value_model http://www.dbforums.com/database-concepts-...eople-hate.html http://weblogs.sqlteam.com/davidm/articles/12117.aspx http://tonyandrews.blogspot.com/2004/10/ot...n-mistakes.html EAV-modellen (dvs, din nummer två) är väldigt flexibel, men den tenderar också att bli väldigt komplex. |
|||
![]() |
![]() |
![]() |
#15 | ||
|
|||
Flitig postare
|
Tack DeSoto, intressant läsning, men jag är inte helt på det klara med vad de olika designtyperna innebär.
EAV är det alltså en tabell enligt: SAAB 9-5, motor, diesel SAAB 9-5, antaldörrar, 5 VOLVO v70, motor, diesel och 3NF som de nämner (3:e normalformen) skulle då vara att man har en tabell med produkter, en med attribut (produkt_id som foreign key) samt en tabell med attributvärden (attribut_id som foreign_key). Fast det stämmer inte enligt det du skrev...? OTLT (one true lookup table) verkar inte vara som mitt 3:e alternativ om jag fattat det rätt och läst vissa kommentarer till en av artiklarna du länkade till. Det verkar vara ett attribut per rad om jag fattat det rätt? Hur skulle OTLT se ut i mitt fall, med produkter och attribut? Har du själv några åsikter i frågan? |
||
![]() |
![]() |
![]() |
#16 | |||
|
||||
Flitig postare
|
Det om OTLT hängde med mest för att det är intressant läsning.
![]() Kärnan i ditt problem är att du vill tillåta dina användare ändra databasens uppbyggnad, vilket i vissa fall kan vara ungefär som att ge ett raketgevär till en fem-åring. Men du har två (eller ja, tre, där den tredje är "Exploded schema") val. Du kan utveckla ditt system så att när kunden lägger till ett fält så körs verkligen en ALTER TABLE-fråga. Eller så väljer du EAV-modellen, och skapar i stort sett en databas inuti en databas. Dvs, allt jobb som lagts ner av olika databastillverkare för att ta fram verktyg för dataintegritet, m.m. slängs bort, och du måste själv utveckla de verktygen till din databas inom en annan databas. Jag föredrar att inte använda EAV-modellen, helt enkelt för att jag accepterat att den nivån av databaskunnande är utanför min expertis. För att implementera en bra och hållbar EAV-modell vill jag påstå att man måste vara en ganska rutinerad databasadministratör. |
|||
![]() |
![]() |
Svara |
|
|