Beror på vad det är för någon data. Kommer ni alltid behöva använda er av alla 20 "kolumner"? Hur förhåller sig datan till varandra? Du måste nog berätta lite mer ingående om tabellerna och datan dom ska innehålla för att man ska kunna svara på den frågan, men i 99,999% av fallen så måste det vara rent vansinne att göra som din kolega har föreslagit. :moose
Frågan#1
Hej, jag har en fråga angående databasdesign. Ifall det spelar roll så är det i Oracle (som jag är ny på, men jag har mångårig erfarenhet av SQL Server).
Våra system fylls ständigt på med ny data, och i det här fallet ska användarna kunna plocka fram rapporter som exv visar aktuella uppgifter. Dvs användaren väljer rapport, ställer in kriterier, klickar på Utför, och väntar en stund tills rapporten är färdigframställd.
Jag hittar på ett exempel (i verkligen finns förstås massor av tabeller osv).
Idag finns en tabell med nyckel och 6 st kolumner.
Tabell1 (ID1, k1, k2, k3, k4, k5, k6)
14 st nya fält, k101-k114, skall läggas till.
Detta kan förstås göras på flera olika sätt (se nedan)...
----
A-varianten:
Befintlig tabell utökas med de nya kolumnerna.
Tab1 (ID1, k1, k2, k3, k4, k5, k6, k101, k102, k103 ... k114)
(Inget joinande mellan tabeller behövs.)
---
B-varianten:
De nya kolumnerna läggs i separat tabell med samma nyckel.
Tab1 (ID1, k1, k2, k3, k4, k5, k6)
Tab101 (ID1, k101, k102, k103, k104, k105, ... , k114)
Tabellerna joinas enkelt via ID1.
----
C-varianten:
De nya kolumnerna läggs i separat tabell med koppling via syntetisk nyckel.
Tab1 (ID1, k1, k2, k3, k4, k5, k6, ID101)
Tab101 (ID101, k101, k102, k103, k104, k105, ... , k114)
Här har vi t ex en syntetisk nyckel i Tab101, samt en referens till den via ny kolumn i Tab1.
Tabellerna joinas enkelt via ID101.
----
D-varianten:
Ett par kollegor till mig valde dock en helt annan lösning.
Vi har alltså
Tab1 (ID1, k1, k2, k3, k4, k5, k6)
Därefter skapade de en tabell för de nya kolumnerna, vilka lagras som rader(!):
Tab100 (ID100, Klartext)
som t ex kan innehålla
1, 'k101'
2, 'k104'
3, 'k102'
4, 'k114'
...
14, 'k112'
Dessutom har man lagt till en kopplingstabell mellan de båda ovanstående tabellerna, där man lagt vart och ett av de 14 nya värdena som en egen rad:
TabK (ID1, ID100, Värde)
Som jag förstår det behövs därmed 29(?) st joinar, istället för 1 st, för att få tag i de 14 nya attributen.
select Tab1.ID, t101.Värde, t102.Värde, t103.Värde, t104.Värde ... t114.Värde
from Tab1 t1, TabK tk1, Tab100 t101
, TabK tk2, Tab100 t102
, TabK tk3, Tab100 t103
, TabK tk4, Tab100 t104
, TabK tk5, Tab100 t105
, TabK tk6, Tab100 t106
, TabK tk7, Tab100 t107
, TabK tk8, Tab100 t108
, TabK tk9, Tab100 t109
, TabK tk10, Tab100 t110
, TabK tk11, Tab100 t111
, TabK tk12, Tab100 t112
, TabK tk13, Tab100 t113
, TabK tk14, Tab100 t114
where Tab1.ID1 = tk1.ID1 and Tab100.ID = tk1.ID100
and Tab1.ID1 = tk2.ID1 and Tab100.ID = tk2.ID100
and Tab1.ID1 = tk3.ID1 and Tab100.ID = tk3.ID100
and Tab1.ID1 = tk4.ID1 and Tab100.ID = tk4.ID100
and Tab1.ID1 = tk5.ID1 and Tab100.ID = tk5.ID100
and Tab1.ID1 = tk6.ID1 and Tab100.ID = tk6.ID100
and Tab1.ID1 = tk7.ID1 and Tab100.ID = tk7.ID100
and Tab1.ID1 = tk8.ID1 and Tab100.ID = tk8.ID100
and Tab1.ID1 = tk9.ID1 and Tab100.ID = tk9.ID100
and Tab1.ID1 = tk10.ID1 and Tab100.ID = tk10.ID100
and Tab1.ID1 = tk11.ID1 and Tab100.ID = tk11.ID100
and Tab1.ID1 = tk12.ID1 and Tab100.ID = tk12.ID100
and Tab1.ID1 = tk13.ID1 and Tab100.ID = tk13.ID100
and Tab1.ID1 = tk14.ID1 and Tab100.ID = tk14.ID100
Kanske har jag missförstått nåt, men eftersom man sparar infon radvis istället för kolumnvis så tänker jag mig
att det blir 14 st fler joinar. Plus ytterligare dubbelt så många pga kopplingstabellen mittemellan.
(I händelse av att exv 15 joinar räcker så är det lugnt för min del, jag är liksom främst ute efter själva principen.)
(Ska man koppla ihop andra saker från andra tabeller så växer förstås antalet joinar ännu mer.)
------------
Vad är bäst?
------------
En av kollegorna hävdar följande fördelar med D-varianten:
+ mer flexibel (eftersom man slipper göra alter table ifall nya attribut tillkommer)
+ minst lika bra prestanda som A/B/C-varianterna.
+ skapar bättre struktur/design
Stämmer ovanstående?
Finns andra fördelar?
Överväger fördelarna?
Rörande flexibiliteten i samband med att framtida nya attribut tillkommer, så tänker jag mig att det snarare är bättre med alter table. Dels går det snabbt, och dels ger det omedelbart en elegant och verklighetsnära design, samtidigt som inga joiner eller villkor behöver förändras.
Att som i D-varianten istället göra inserts är förstås smidigt i sig, men medför att man för att få tag i de nya attributen ifråga kommer behöva joina ännu mer och kanske ändra i villkors-satser i script.
Rörande prestandabiten tänker jag mig, utan att vara någon prestandaexpert, att man snarare förlorar än vinner rörande svarstider..? Typ att 29 st joinar som regel tar längre tid än 1..??
I övrigt ser jag själv mest nackelar:
* Krångligare, och tar längre tid, att designa och utveckla.
* Krångligare att hålla ordning på alla relationer, joinar/villkor osv i databasen.
* Svårare få överblick över vad man egentligen håller på med (dvs verksamhetsbiten)
* Svårare sätta sig in i för andra.
* Krångligare och svårare att skriva selects-satser, etc, för att titta på data.
