Måste man ha en tredje tabell?

Du behöver en tredje tabell, ja, för att mappa relationerna mellan person och grupp.

För hur ska du annars representera att person A tillhör grupp X, Y och Z?

Ja, det går att fixa med bara två tabeller. Men en tredje tabell kan snabba upp/förenkla hanteringen.

Dessutom kan den tredje tabellen innehålla start och slutdatum för knytningen till de två primära tabellerna.
Då vet man allt.
Om man dessutom tänker till och slänger in lite redundant information så blir den tabellen mycket snabb vid slagningar och vissa grundlistningar.
De jag är bäst på är inte normalisering, det är denormalisering !
Datautrymme är ju numera inga problem.
Ni slipper kolla bits i niblar.

Av nyfikenhet, vad är det för redundant information du tänker på Lappe?

Lasp skrev:

Dessutom kan den tredje tabellen innehålla start och slutdatum för knytningen till de två primära tabellerna.
Då vet man allt.

Vad menar du med att man vet allt om man har start och slutdatum? Vad kan det vara bra för? Radera alla personer inom en viss period.

Lasp skrev:

slänger in lite redundant information så blir den tabellen mycket snabb vid slagningar och vissa grundlistningar.

Vad för redundant information syftar du på då?

casca skrev:

Du behöver en tredje tabell, ja, för att mappa relationerna mellan person och grupp.

För hur ska du annars representera att person A tillhör grupp X, Y och Z?

Så här även om det inte är optimalt

People
People_ID, People_name
1 , Anna
2 , Ola
3 , Tina
4 , Stina

Group
Group_ID, Group_name, People_ID (FK)
1 , Grupp 1 , 1
2 , Grupp 1 , 1
3 , Grupp 3 , 3
4 , Grupp 3 , 3

Anna och Tina matchar sitt People_ID(PK) i tabellen Group, dvs de tillhör grupp 1 och grupp 3. Kan man inte göra så?

xtreme skrev:

Så här även om det inte är optimalt

People
People_ID, People_name
1 , Anna
2 , Ola
3 , Tina
4 , Stina

Group
Group_ID, Group_name, People_ID (FK)
1 , Grupp 1 , 1
2 , Grupp 1 , 1
3 , Grupp 3 , 3
4 , Grupp 3 , 3

Anna och Tina matchar sitt People_ID(PK) i tabellen Group, dvs de tillhör grupp 1 och grupp 3. Kan man inte göra så?

Så länge "grupp" inte är något annat än ett namn så kan man absolut göra så. Problemet kommer när du vill byta namn på grupp "Grupp 1", eller om grupp plötsligt innehåller relaterad information, t.ex. en beskrivning. (Var ska du lagra beskrivningen för "Grupp 1", på ett sätt som undviker redundans?) I en normaliserad tabell skulle din tabell "Group" vara ansvarig för relationen, dvs. innehålla ungefär:

ID, Group_ID, People_ID

Så du har en tabell med "Groups" och en med "Peoples", och där "relationstabellen" har en enda uppgift: att koppla samman objekt, eller skapa en relation (M:N, many-to-many).

OK Jag skall försöka att förklara mig.
Med redundant data menar jag att man har samma uppgifter på flera ställen. Det är normalt inte eftersträvansvärt men det kan ha sina fördelar.
Om man har en komplett persontabell så innehåller den mycken data, men den dagliga listningen och sökningen kanske bara vill ha grupp, förnamn, efternamn och telefonnummer. Kanske man formerar namnen på et mer läsbart sätt och eventuellt skapar en Homonym nyckel.
Om man då passar på att stoppa in dessa data i den tredje tabellen, och automatiskt skapar ny from post vid ändring i persontabellen har man avsevärt ökat hastigheten och dataströmmar.
Att inte ha TS (Timestamp) med i en knyttabell tycker jag är allvarligt. Förhållande eller tillhörighet gäller ju oftast inte i evigheter.
Detta är i mitt tycke mycket försummat! Även en statusflagga är ju guld värt för snabbhet.

Som ni vet är jag ju numera inte bara lat, utan arbetsskygg, så jag hoppas att ovanstående räcker.
Annars får ni ropa så kommer det kanske bättre exempel.
Nu har ju jag bara jobbat med tabeller med några miljoner poster, men svärdottern satt härförleden med optimering kring 1.2 miljarder poster (dublettrensning).

Men jag gillar fortfarande hyfsat stora register ;-) Analys är kul det!

xtreme skrev:

Min tanke är att jag har en tabell med personer och en tabell med grupper. Flera personer kan tillhöra (vara med i en) grupp.

Räcker det med att jag har person ID med i varje tabell, där de överensstämmer är de med i gruppen.

Eller måste jag ha en tredje tabell som matchar person och grupp?

Du kan slippa en tredje tabell om och endast om (*) varje grupp innehåller en till flera personer, men varje person är med i högst en grupp.

(* Eller tvärtom att varje person kan tillhöra många "grupper" men varje "grupp" innehåller högst en person, men då har du ju extremt konstig namngivning på dina tabeller så det utgår jag ifrån att det inte gäller. Du måste alltså ha en 1-N (eller 1:1) koppling mellan dina tabeller.)

Då kan du lösa alla problem med följande struktur:

Person: (PersonID, Förnamn, Efternamn, Användarnamn, ..., GruppID)
Grupp: (GruppID, Gruppnamn, Gruppfärg, ...)

Alla uppgifter om en viss person finns på en rad i Person, dito för en grupp i Grupp, personens grupptillhörighet bestäms av GruppID i Person.

MEN om du idag har eller att det är rimligt att tro att du någon gång kan hamna i läget att en person kan tillhöra mer än en grupp och du alltså har eller kan få ett N-M förhållande, då måste du ha en tredje tabell:

Person: (PersonID, Förnamn, Efternamn, Användarnamn, ...)
Grupp: (GruppID, Gruppnamn, Gruppfärg, ...)
Tillhörighet: (PersonID, GruppID)

Ok, jag har nu lyssnat på er och skapat tre tabeller. Så här ni menar?

En tabell för bilder/people

CREATE TABLE `image` (
  `image_id` int(11) NOT NULL AUTO_INCREMENT,
  `image_name` varchar(255) NOT NULL,
  `image_url` varchar(255) NOT NULL,
  PRIMARY KEY (`image_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

En för rummet/group

CREATE TABLE `room` (
  `room_id` int(11) NOT NULL AUTO_INCREMENT,
  `room_name` varchar(255) NOT NULL,
  PRIMARY KEY (`room_id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1

En som samlar de två tabellerna

CREATE TABLE `image_room` (
  `image_id` int(11) NOT NULL,
  `room_id` int(11) NOT NULL,
  PRIMARY KEY (`image_id`,`room_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Precis!