En eller flera tabeller?

Tycker att man kommer till olika dilemman vad det gäller att planera databaser hela tiden.

Säg nu att jag har en tabell med en miljon rader. Nu behöver jag också ha en kolumn för att kunna spara en kommentar till varje rad i tabellen..
Saken är den att det är kanske 10% av alla rader som har en kommentar. Då är ju frågan:
Ska jag lägga till en kolumn i tabellen som kommer bli av typen "Pm"?
Eller ska jag skapa en ny tabell där jag sparar alla kommentarerna och koppla dom till till rätt rad i den första tabellen?

Är det inte så att om jag skapar en kolumn till och anger den till en viss datatyp så tar den upp ett visst utrymme oavsett om det finns något i den eller om den bara är NULL?
Å andra sidan blir det det väll en prestandard försämring om jag måste koppla till en ytterligare tabell.. Men å andra sidan borde väl första tabellen bli tyngre att gå igenom med det nya fältet??

Mycket funderingar nu :)

Det är ju en helt ny data struktur så en ny tabell är ju att föredrar. Prestanda vet jag inte om det bli sämmre men underhåll bli ju 100gånger lättare att jobba med om man nu skall ta bort kommentarer och liknande. Att ha ett fält som heter "PM" är oavsett fel hur man än vrider och vänder på det :)

haha a jo kan hålla med om "PM" :)

Men tycker det är många gånger man blir osäker på vad som är optimalt, när man läser och frågar lite folk så känns det som åsikterna och sätten man löser olika dilemman på skiljer sig.

Om du har så gles data i en eventuell ny kolumn i databasen ska du absolut bryta ut kommentarsfältet till en separat tabell. Då slipper du ha ett fält med en massa null. Sen refererar du bara till huvudtabellen med radid på varje kommentarsrad i den nya tabellen. Bäst för struktur också, enligt min mening.

Glöm inte index bara, och att ha unikt index dessutom så du inte får flera kommentarer för samma rad.

OR: precis så blev det nu, kör en separat tabell med kommentarer och en kolumn med hänvisning till huvudtabellen..
Om jag nu istället haft en enda tabell med en kommentar kolumn, säg då att 90% av fälten för den kolumnen är tomma, det hade ändå tagit upp det uttrymmet även det är tomt?

onkel: du menar att jag skulle ha en "id" kolumn i min kommentartabell? Jag är för snål för det ;) Den funktionen med att kontrollera om kommentar redan finns gör jag ändå när jag spara ny kommentar..

Nej, du behöver inte separat id-kolumn, inte mer än den du redan har som pekar på din vanliga tabell. Däremot behöver du ett index, en primary key, på den kolumnen, som är unik

(Att bara kolla när du skapar räcker inte, tänk om det blir två parallella anrop..?)

aja ok, då är jag med. Så det blir en ren kontroll bara att ange det fältet med referensen som primary key?

Nja, om du inte har något index alls så blir det en våldsam prestandaförsämring, till att börja med. Din databas skulle knäcka vilken server som helst vid minsta beröring..

Att ha det fältet som PK är för att kunna hitta kommentaren, för att hitta en viss kommentar så söker man primärt på id:t för din tabell, alltså är det PK. Sen ska den vara unik eftersom att du aldrig ska kunna ha två kommentarer för samma rad, och sådana här kollar överlåter man _inte_ till mjukvara eftersom att du då får ett race condition. Någon gång så kommer det att klicka, och det blir inte kul att hitta och åtgärda felet..

Pkey. men det du skriver om prestandaförsämring då. Det handlar alltså om vikten av att alltid ha en PK till varje tabell..

Nu börjar jag fundera på om jag ens förstår vad du menar med index. vad är Index?
Innebörden av PK är att det bara finns en av varje, annars skulle man aldrig kunna hitta rätt va??

Jag försöker i alla mina tabeller skapa en kolumn som heter id och som är PK med autoinkrement..

Index är i princip samma sak som registret längst bak i en bok, dvs. för att snabbt hitta rätt ställe i boken. Hade du inte haft det så hade du behövt läsa igenom hela boken varje gång..

En PK är en sorts index.

okey, då förstår jag att det blir tungt för databasenhanteraren att läsa igenom alla sidor i letan efter ett enda ord :)