[JesperA]

Japp, luddig rubrik men visste inte hur jag skulle beskriva det.


Jag har en litet motorcommunity sen några år tillbaka, inget seriöst, mest för att ha något att göra och testa lite olika saker.

Sitter nu och planerar att göra ett marketplace där folk kan sälja allt i motorväg i kategorierna: bilar, husbilar, motorcyklar, mopeder, fyrhjulingar, lastbilar osv osv.

Så jag satt och planerade databasens struktur ända tills det gick lite väl överstyr, varje kategori har ju någon form av extra information, tex miltal, årsmodell osv.

Så nyss satt jag och kladdade databasstrukturen på ett papper:

kolumnnamn (kolumntyp, längd, exempel)
...
...
ad_modelyear (smallint, 4, etc "2012")
ad_mileage (tinyint, 2, etc "30" som översätts till "1000-1499")
ad_gearbox (tinyint, 2, etc "1" som är "Manuell")
ad_fuel (tinyint, 2, etc "2" som är "Diesel")
ad_length (tinyint, 2, etc "2" där siffran är i meter, unikt för husvagnar)
ad_beds (tinyint, 2, etc "4" där siffran är antalet sängplatser, unikt för husvagnar)
ad_boogie (tinyint, 2, etc "2" där siffran är 1 för ja, 2 för nej osv, unikt för husvagnar)
osv osv
...
...


Om jag skall hålla på så och göra en ny kolumn för varenda unik sak för extra informationen för en viss kategori så kommer det ju bli en jädra massa kolumner.

Tex, ovan gjorde jag ett exempel på 7st kolumner, men egentligen är det bara 4 "unika" kolumner som behövs egentligen.

Tex kategorin "Bilar" behöver bara ad_modelyear, ad_mileage, ad_gearbox, ad_fuel och då kommer ju ad_length och ad_beds, ad_boogie kolumnerna stå tomma när någon skapar en annons för bilar, vilket känns lite onödigt.

Och för kategorin "Husvagnar" gäller samma sak som bara behöver ad_modelyear, ad_length, ad_beds, ad_boogie, då står ju ad_mileage, ad_gearbox och ad_fuel kolumnerna tomma.

Blir ju sjukt i framtiden när man lägger till ännu fler kolumner för tex "Karosstyp" osv.


Så jag funderar på om jag skall köra om kolumnerna så dom används till olika saker beroende på vilken kategori det gäller.

Tex (ei = extra information)

ad_ie1 (smallint, 4)
ad_ie2 (tinyint, 2)
ad_ie3 (tinyint, 2)
ad_ie4 (tinyint, 2)

Så i kategorin bilar används dom i denna ordningen:
ad_modelyear ersätts med ad_ie1
ad_mileage ersätts med ad_ie2
ad_gearbox ersätts med ad_ie3
ad_fuel ersätts med ad_ie4

Och för kategorin husvagnar:
ad_modelyear ersätts med ad_ie1
ad_length ersätts med ad_ie2
ad_beds ersätts med ad_ie3
ad_boogie ersätts med ad_ie4


Så nu är det totalt 4 kolumner för "Extra information" istället för 7st. Och om nu kategorin "Fyrhjuling" får 4 unika kolumner så skulle det på "gamla" sättet bli 11 kolumner, istället för 4.


Har suttit i ett par timmar och försökt komma på någon nackdel med detta, men hittar bara positiva saker:
Mindre databas, mindre antalet kolumner, lättare sök query (behöver inte lika många AND/OR) osv osv.

Eller iofs, en nackdel är ju att man omedelbart vet vad ad_beds innebär, men är ju bara att skriva en liten dokumentation så man håller koll på vad ad_ieX används för för respektive kategori.

Så ja, nämn gärna någon nackdel eller något annat förslag på hur ni minimerar antalet kolumner.

[Conny Westh]

Nej, du är inne på fel spår.

Du bör normalisera databasens struktur. Se http://sv.wikipedia.org/wiki/Normalform_(databaser) för detaljer om normaformerna. Det finns många andra bättre beskrivningar av hur normalisering går till men du får söka lite på Google för det.

En grundläggande sak att tänka på är att varje kolumn ska användas för en sak och inget annat, du ska ha s.k. "atomära" värden, dvs odelbara värden. Det är 1NF (Första Normalformen).

Men om du läser på wikipedialänken ovan så är det lämpligt att försöka hålla sig till 3:e normalformen, dvs 3NF (BCNF kan du glömma för den har visat sig vara ett missförstånd).

Sammanfattningsvis så ska alla kolumner innehålla atomära värden. Alla tabeller ha en primärnyckel. Primärnyckeln kan bestå av en eller flera kolumner.

"Varje kolumn ska vara beroende av primärnyckeln, hela primärnyckeln och inget annat än primärnyckeln, so help me Codd". (Det ären klassisk vits som brukar användas för att beskriva 3NF).

Du bör m a o bryta ut properties som inte behövs på alla rader i tabellen till egna tabeller och så ska den tabellen innehålla en främmande nyckel till Bil-tabellen som samtidigt är en del av primärnyckeln i egenskapstabellen.

Men du bör även ha en tabell som består av alla möjliga properties, så tre tabeller ser ut att delvis lösa ditt problem.


Tabell: Bil
PK: RegNr
Kolumn: Brand

Tabell: Egenskap
PK: EgenskapID (Ex: ProdMonth)
Kolumn: Egenskap (Ex: Tillverkningsmånad)

Tabell: BilEgenskap
Kolumn: PKFK->Bil ("ABC123")
Kolumn: PKFK->Egenskap ("ProdMonth")
Kolumn: Värde ("2012-03")

Nu har jag lett in dig på rätt spår, men det finns mer detaljer som vi kan ta sen du satt dig in i denna grund.

[Conny Westh]

Det första steget är att försöka hitta de olika tabellerna som behövs, sen ska man försöka placera ut egenskaperna på ett smart sätt.

Ta tabellen bil till en början. Vilka egenskaper finns på alla bilar? Regnr, Märke, Modell m.m. Eftersom det är en köp/sälj sida så bör kanske även pris vara ett krav på varje bil som annonseras ut.

Vilka egenskaper ska alltid finna smed och vilka ska vara dynamiskt styrda? De dynamiskt styrda kan du använda mitt förslag i mitt tidigare inlägg med särskilda egenskapstabeller.

Du kommer säkert även komma på att du behöver fler tabeller än BIL. Men dett aär ett gediget arbete att ta fram en bra och stabil datamodell, du bör lära dig normalisering och fundera ordentligt innan du börjar lägga ner tid på kodning av övrig adelar, annars får du hiskeligt mycket jobb i onödan.

[JesperA]

Tack för svaret.

Jag kommer köra med denormaliserad, jag vet mycket väl hur jag skulle bygga upp en 3NF version men valde bort det då det är otroligt onödigt i förhållande till att bara använda 4 INT kolumner.

[Jonas]

Jag skulle fortfarande bygga detta enligt 3NF eftersom skall projektet vidareutvecklas senare så är min tanke att detta kommer att bita en något så fruktansvärt i baken.

Bättre att bygga saker bra för framtiden än att bygga det för stunden.

[JesperA]

Ursprungligen postat av Jonas

Jag skulle fortfarande bygga detta enligt 3NF eftersom skall projektet vidareutvecklas senare så är min tanke att detta kommer att bita en något så fruktansvärt i baken.

Bättre att bygga saker bra för framtiden än att bygga det för stunden.

Ja jag håller fullständigt med, brukar spendera en enorm tid på att få till rätt struktur på databasen. Men denna gången tänkte jag testa något helt annat då annonser är högst tillfällig data, så är ju ingen katastrof att göra om till 3NF i en bit in i framtiden när det börjar kännas att det behövs.