Sitter och klurar lite på design av en databas som ska innehålla försäkringar. Problemet är att det är väldigt mycket data (och då menar jag mycket) som ska in och då undrar jag vad ni tycker är bästa sättet att gå tillväga.

En försäkring har ett ID (F_ID), försäkringstagare (pno), premie och lite annat smått o gott

Försäkring
-----
F_ID
Premie
pno
...

En försäkring kan vara av en viss typ och typerna har till stor del likadana fält. Därtill kan man välja olika tillägg, som också har gemensamma fält till viss del. Tilläggen kopplar jag till en försäkring (FID).

Tillägg
-----
F_ID
T_ID
Premie
a
b
c
...

Nu är ju alternativet att ha bara en tabell för alla tillägg och därmed få massor av tomma fält. Är det bättre att skapa en tabell för varje typ av tillägg då? Eller kanske ha en gemensam tabell för de gemensamma fälten och därtill koppla olika tabeller för olika typer med unika fält?


Försäkring
-----
F_ID

Tillägg
-----
F_ID
T_ID
Premie

Tillägg_1
-----
T_ID
a

Tillägg_2
-----
T_ID
b

Hur jag än gör så känns det inte 100% bra..

Om tilläggen variera över tiden (nya kommer till och andra försvinner) blir det snabbt ohållbart att ha alla tilläggen i samma tabell. Tycker ditt senare förslag verkar bäst men jag förstår inte riktigt vad du menar med tillägg_1 och tillägg_2. Behöver du olika tabeller för olika tillägg?

Eftersom det finns olika tillägg med olika innehåll, så tänkte jag att man kunde lägga specifik data för just Tillägg 1 i en tabell, och data för Tillägg 2 i en annan tabell.

Det kanske är 20 fält för varje tillägg varav 5-10 fält är likadana. Sen är det runt 5-6 olika tillägg. Så det blir många olika fält i tabellen om man ska spara alla tillägg i en tabell.

Så här kan det ex se ut:

Tillägg1
a, b, c, d

Tillägg2
b,c

Tillägg3
c,d,e,f,g,h


Det kan bli rätt många försäkringar, så ur prestandasynpunkt är det väl bäst att ha så få tabeller som möjligt med något index i varje? Försäkring i en tabell och alla tillägg i en tabell. Men det finns väl någon gräns för hur mycket data man kan lagra i en rad i en tabell?

Det stora problemet med att ha olika tabeller för olika tillägg är att du inte kan skapa relationer (foreign keys) mellan tabellerna.

Vad sägs om att ha endast en tabell för tilläggen, med en extra kolumn som anger typ av tillägg.
Varje försäkring kan då att ha flera rader i tilläggstabellen, och det blir en snygg datamodell, utan tomma fält. En kopplingstabell anger då vilka tillägg en försäkring har.


exempel:

Försäkring
-----
F_ID
Premie
pno
...

FörsäkringsTillägg
----
F_ID
T_ID

Tillägg
----
T_ID
Tilläggstyp
...

Det är väl just en massa tomma fält han får i tilläggstabellen med den lösningen i och med att de har så få fält gemensamma.

En tredje variant vore att ha separata tabeller för tilläggen och referera till försäkringen i dessa tabeller. Då kan du ha relationer mellan tabellerna samtidigt som du undviker en massa tomma fält.

Försäkring
-----------
F_ID (PK)
...
...


Tillägg1
---------
T1_ID (PK)
F_ID (FK)
...

Tillägg2
---------
T2_ID (PK)
F_ID (FK)
...


//J

Att ha separata tabeller för tilläggen gör att lösningen inte blir särskilt skalbar. Tänk om det dyker upp ett nytt tillägg? Då ska man skapa en ny tabell och sen lägga till och ändra i databasanropen.

Lägg istället till ett par tabeller till Pers förslag ovan.

Vad vi har är:

- Försäkring
-- Kan ha 1 eller flera tillägg
--- F_ID, premie, pno, ...

- Tillägg
-- Kan ha 1 eller flera fält
--- T_ID, benämning

- Fält
-- Vissa fält finns på flera tillägg
--- F_ID, benämning, ...

Om vi skapar dessa 3 tabeller och sedan lägger till 2 stycken relationstabeller( försäkring-tillägg och tillägg-fält) så kan vi göra följande väldigt enkelt:

1. Ändra vilka tillägg en försäkring ska ha
2. Ändra vilka fält ett tillägg ska ha
3. Lägga till nya tillägg
4. Lägga till nya fält

Då har du en normaliserad och skalbar lösning.

>Det kan bli rätt många försäkringar, så ur prestandasynpunkt är det väl bäst att ha så få tabeller som
>möjligt med något index i varje?

Är det verkligen så. Rent intuitivt skulle jag säga att det är tvärtom. Många tabeller med 1-n relationer ger bättre prestanda.

Visst kan du få bättre prestanda med många relationstabeller, där du har splittat upp datamängden på flera tabeller istället för 1. Dock så riskerar du att få många Joins och detta slöar ner databasen mer än vad det gör att ha mycket data i en tabell.

Jag skulle nog påstå tvärtom, att om man är ute efter rå prestanda så bryter man ofta mot normaliseringsreglen och dubbellagrar information för att slippa göra extra beräkningar och joins, detta speedar up lite. Ordentliga index är dock nycklen till hastighet.

- M

Jag håller med om att Patiks design är både mer elegant och mer flexibel. Dock så skulle jag vilja påstå att den blir en aning knepig att arbeta med i t ex beräkningar och rapporter. Det blir ju inte lika enkelt som att referera till ett fält direkt => extra felkälla. Min bild av försäkringsbranchen är att den är ruggit beräkningsintensiv och då kan det bli opraktiskt att om det är för normaliserat.

Skulle vara intressant och veta vad som menas med väldigt mycket försäkringar. Rör det sig om 100.000, 1.000.000 eller fler?

Man kan ju alltid lägga en View ovanpå mina tabeller att arbeta mot.

Om jag inte är helt ute och cyklar så blir det än rätt otrevlig vy i och med att du får joina in tabellen med alla fält x antal gånger?

"Jag håller med om att Patiks design är både mer elegant och mer flexibel."
Ja det känns ju mer flexibelt iaf. Får kolla lite närmare på det.

"Min bild av försäkringsbranchen är att den är ruggit beräkningsintensiv"
I det här fallet ska försäkringar endast sparas och presenteras, premie och sånt är redan beräknat.

Många försäkringar är ju väldigt subjektivt, var väl jag som uttryckte mig otydligt. Vid närmare koll så blir det inte så hemskans många försäkringar, ett tak på 10.000 kanske. Fast man vet inte, det kan ju ändras i framtiden.

Patrik, jag tror att jag är med på hur du menar. Fast med de fält som ett tillägg har så menar jag t.ex.

Duedate, ett datum
Årsinkomst, en float

Hur/var är det tänkt att spara värdet för ett fält i så fall?! Att koppla vissa fält till ett visst tillägg är ju inga problem. Men ett fält kan ju vara av olika datatyp. Eller missade jag något?