Permalänk
Medlem

Effektiv databasdesign

Sitter just nu och håller på designar en databas till min blogg. Jag vill att läsarna ska kunna kommentera både inlägg samt bilder.

Min fråga är helt enkelt om det bästa är att skapa en tabell som spar alla kommentarer, och sedan genom två "länk tabeller" koppla ihop rätt bild med rätt kommentar och rätt inlägg med rätt kommentar.

Eller helt enkelt skapa två olika kommentars tabeller. Och då i t: ex comments_img bara ha en column som specifierar vilken bild kommentaren hör till.

Det jag undrar är alltså vad som är bäst ur ren prestanda synvinkel, vad är snabbast helt enkelt

/MVH Tomas

Visa signatur

//Toombass

Permalänk

En tabell för bilder.
En tabell för kommentarer.
En tabell för inlägg.
En relationstabell för bilder <-> kommentarer.
En relationstabell för inlägg <-> kommentarer.

Jag tycker att om man får fram relationen har flera så ska man ha en separat tabell och en hjälptabell.

Jag vet inte vad som ger mest prestanda, men jag tycker att det är väldigt viktigt med vettiga databasscheman och normalisering.

[EDIT] "Nope," skulle aldrig vara med i meddelandet...

Permalänk
Medlem

Tyvärr ger normalisering ibland viss förlust av prestanda men i detta fallet tror jag knappt det är mätbart så gör som hagbarddenstore skriver...

Permalänk
Medlem

hagbarddenstore: Nope?, ditt förslag är ju identiskt med mitt första.

fegis: Jo så är det ju sjävklart, men i det här fallet var det vilken metod som är snabbast som är av intresse.

/Tomas

Visa signatur

//Toombass

Permalänk

Det som ger mest prestanda torde vara att du har vettiga frågor. Jag tror inte det är alltför stor skillnad på att fråga tre tabeller med krav än det är att fråga en tabell i en modern databashanterare om du skriver dina frågor bra.

Permalänk
Medlem

hagbarddenstore: Det är klart att frågorna är väldigt viktiga, men dom vet jag hur jag ska utforma för att få dem så optimerade som möjligt. Det var därför jag inte frågade hur jag skulle skriva frågorna utan hur jag skulle designa tabellerna.

Skillnaderna i databasdesignen må vara små, men har man väldigt mycket data i dem så kan det bli en märkbar skillnad.

Visa signatur

//Toombass

Permalänk

Gör ett test kanske?

Fixa tabellerna som jag föreslog, fixa som du föreslog, peta in ett par miljoner rader, kör dina frågor med hjälp av ett skript.

Något sådant hade jag gjort för att få reda på svaret på frågan.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Toombass
hagbarddenstore: Det är klart att frågorna är väldigt viktiga, men dom vet jag hur jag ska utforma för att få dem så optimerade som möjligt. Det var därför jag inte frågade hur jag skulle skriva frågorna utan hur jag skulle designa tabellerna.

Skillnaderna i databasdesignen må vara små, men har man väldigt mycket data i dem så kan det bli en märkbar skillnad.

Om du vet hur man skriver optimerade frågor så borde du ju veta hur en bra databasdesign ser ut i det här fallet, kan man tycka.

Har du korrekta index i din databas så ska prestandan inte påverkas så mycket beroende på om du har en eller två tabeller för kommentarerna. Det är nog viktigare att ta i beaktning huruvida kommentarerna för inlägg skiljer sig från kommentarerna för bilder på något grundläggande sätt.

För övrigt håller jag med hagbarddenstore om att det är viktigt med bra databasscheman och normalisering. Följer man bra principer så får man bra databaser, och man kan sedan spendera tid på att optimera där det behövs.

Visa signatur

Bra, snabbt, billigt; välj två.

Ljud
PC → ODAC/O2 → Sennheiser HD650/Ultrasone PRO 900/...
PC → S.M.S.L SA300 → Bowers & Wilkins 607

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Fegis
Tyvärr ger normalisering ibland viss förlust av prestanda men i detta fallet tror jag knappt det är mätbart så gör som hagbarddenstore skriver...

Såvida man indexerar rätt så är normaliserade tabeller någorlunda snabba. Om sedan prestandan skulle var ett stort problem så kan man cachelagra datan i RAM-minnet för att få upp prestandan. Om man inte normaliserar sina tabeller och istället cachelagrar saker internt i databasen så får databasdesignen en mer komplex struktur, vilket är jobbigt.

Permalänk
Medlem

Du behöver ju inte två relationstabeller för ändamålet. Räcker med att bilder-tabellen och inlägg-tabellen har en kommenteringsobject-kolumn, och att varje kommentar sker per kommenteringsobjekt.

Permalänk
Medlem

Är det inte prestandavinst att ha två ID-kolumner i kommentarer-tabellen (en för bilder, en för inlägg) som båda kan vara null och skjuta INNER JOIN istället för att köra med relationstabeller?

EDIT: Ser att det var nästan det som "RAMPKORV" skrev.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av azoapes
Är det inte prestandavinst att ha två ID-kolumner i kommentarer-tabellen (en för bilder, en för inlägg) som båda kan vara null och skjuta INNER JOIN istället för att köra med relationstabeller?

EDIT: Ser att det var nästan det som "RAMPKORV" skrev.

Det här känns ju inte helt rätt. Varför ska man hålla reda på vilken slags kommentar det är genom vilken kolumn som används för att lagra IDt? Det finns ju inga krav på att de olika typerna av kommentarer måste ha varsin serie av IDn, och man måste ändå ha en relationstabell eftersom ett inlägg kan ha flera kommentarer.

Man kan lösa detta utan en relationstabell genom att ha en kolumn i inlägg/bilder-tabellerna som innehåller ett kommentars-ID som är unikt för varje inlägg/bild. I kommentarstabellen har man en nyckel som består av detta ID samt en räknare för varje enskilt ID. Nackdelen med detta är att man måste hålla reda på kommentars-IDt så att det inte förekommer samma ID flera gånger.

Visa signatur

Bra, snabbt, billigt; välj två.

Ljud
PC → ODAC/O2 → Sennheiser HD650/Ultrasone PRO 900/...
PC → S.M.S.L SA300 → Bowers & Wilkins 607

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Phod
Det här känns ju inte helt rätt. Varför ska man hålla reda på vilken slags kommentar det är genom vilken kolumn som används för att lagra IDt? Det finns ju inga krav på att de olika typerna av kommentarer måste ha varsin serie av IDn, och man måste ändå ha en relationstabell eftersom ett inlägg kan ha flera kommentarer.

Nej då behöver man ingen relationstabell, det var hela poängen. Två ID-kolumner i kommentartabellen, en kommentar kan ju bara ligga under en bild eller ett inlägg. Man lagrar alltså inlägget eller bildens ID i en av de extra kolumnerna. Blir rätt smidigt med INNER JOIN på det, vilket ignorerar de som är null och bara plockar fram de relevanta posterna.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av azoapes
Nej då behöver man ingen relationstabell, det var hela poängen. Två ID-kolumner i kommentartabellen, en kommentar kan ju bara ligga under en bild eller ett inlägg. Man lagrar alltså inlägget eller bildens ID i en av de extra kolumnerna. Blir rätt smidigt med INNER JOIN på det, vilket ignorerar de som är null och bara plockar fram de relevanta posterna.

Det känns ju inte helt klockrent att använda ett sådant index du föreslår ifall man vill göra operationer på hela kommentarstabellen (t.ex. om man ska lista alla kommentarer från en användare och liknande). Då har man problemet att IDt växlar mellan två kolumner den resulterande uppsättningen data. Problemet går ju lätt att lösa detta med endast en kolumn för IDt i kommentarstabellen, så jag ser ingen anledning till att ha två kolumner för detta ändamål.

För övrigt har relationstabellen ingen större påverkan på prestandan i det här fallet. Är du säker på att din lösning med NULL i nyckeln inte kan leda till situationer där indexet inte används och man råkar ut för en table scan?

Visa signatur

Bra, snabbt, billigt; välj två.

Ljud
PC → ODAC/O2 → Sennheiser HD650/Ultrasone PRO 900/...
PC → S.M.S.L SA300 → Bowers & Wilkins 607