[MySQL] Spara många kopplingar mellan olika tabeller på bästa sätt?

Problemet som uppstår är att man inte kan plocka ut folk som specifikt gillar päron utan att först plocka ut alla registrerade personer och sedan programmatiskt söka igenom deras GillarFrukt-array efter ett visst värde.

Genom att separera (normalisera) varje N:N (många till många)-förhållande till två stycken 1:N (ett till många) går man runt detta på ett smidigt sätt:

SELECT Person.Namn FROM Person, Frukt, Kopplingar WHERE Kopplingar.PersonID = Person.ID AND Kopplingar.FruktID = Frukt.ID AND Frukt.Namn = 'Päron'

(går att göra snyggare med JOINs.)

60000 rader är småpotatis. Men när det börjar närma sig hundratals miljoner rader så kommer man vilja flytta lasten från läsning (join) till skrivning och faktiskt lägga ihop varja användares frukter i en egen struktur vid varje förändring. Det är bla här "NoSQL" kommer in.

Precis.
Faktum är att man ofta gräver en grop åt sig själv när man försöker göra det enkelt och slå ihop tabeller. Databasens främsta egenskap är, om den är korrekt utformad, att sökningar är okomplicerade och snabba att genomföra.

Man skulle exempelvis klara sig hjälpligt med en enda tabell Fruktälskare med kolumnerna ID, Namn och GillarFrukt. Problemet som uppstår i detta läge kallas redundans. Om Kalle gillar Äpplen och Päron måste hans namn återfinnas på två rader i databasen. Vill man exempelvis plocka ut alla unika personer ur en sådan tabell måste databasen arbeta igenom en massa redundant information som berättar att Kalle gillar Äpplen, Päron, Bananer, Meloner, Avokados och Rambutaner. Jämför detta med att ha en Person-tabell som bara innehåller unika ID:n så står det klart vilket som är att föredra, även om konceptet med många olika tabeller, privata och främmande nycklar och constraints kan kännas väldigt avskräckande till en början.

Här är den "snyggare" JOIN-satsen jag pratade om..

SELECT Person.Namn AS Person, Frukt.Namn AS Fruktnamn
	FROM Person
	INNER JOIN Kopplingar USING (PersonID)
	INNER JOIN Frukt USING (FruktID)
	WHERE Fruktnamn = 'Päron'

Det finns en quirk här som på sätt och vis uppmuntrar ett strikt namngivningsschema: när man använder USING() kombineras rader med det inom-parenteser-angivna kolumnnamnet. Detta innebär alltså att du i Kopplingar behöver ha kolumnerna [PersonID, FruktID] och att dessa även måste återfinnas som PersonID och FruktID i de relaterade tabellerna Person och Frukt. Det kan tyckas lite omständligt, jag har faktiskt inte beslutat mig för vad jag gillar mest; Person.ID = Kopplingar.PersonID ser tydligt ut för mig.

edit
För att svara på din fråga:
Ett index är en mekanism som optimerar ett attribut för sökning. Som en bieffekt av detta brukar INSERTs eller UPDATEs på det indexerade fältet bli långsammare. Primärnyckeln (eller -nycklen som det kallas i Skåne) är en mer eller mindre mandatorisk indexeringsfunktion som vanligtvis läggs på ett fält med automatiskt tilldelat heltalsvärde. Detta fält uppdateras sällan och INSERTs sker förutsägbart, varvid den potentiella prestandaförlusten hålls till ett minimum.

Mer info här: Index (database) - Wikipedia, the free encyclopedia

Ta bort Frukt.Namn ur "SELECT Person.Namn, Frukt.Namn FROM ... "'

edit: scratch that. I en relationsdatabas ser precisa selects ut på det viset. Om du bara hade haft fruktnamn på en rad så hade de andra inte varit knutna till något. Hur du presenterar informationen du hämtar ur databasen är oberoende av tabellstrukturen.

Kort och gott, att göra två SELECTs är bara onödigt. Vill du ändå greja med det så borde det gå att slå ihop namnen och gruppera på frukten, på något sätt. Jag är inte så bra på inbyggda SQL-funktioner..

Om du vill ha alla som gillar en viss frukt (och de inte är för många) i samma fält kan du göra så här:

mysql> SELECT f.Namn AS fruktnamn, GROUP_CONCAT(p.Namn) AS person FROM Frukt AS f JOIN Kopplingar AS k ON k.FruktID=f.FruktID JOIN Person AS p ON p.PersonID=k.P
ersonID GROUP BY f.FruktID;
+-----------+------------------+
| fruktnamn | person           |
+-----------+------------------+
| Apple     | Anna,Karl,Robert |
+-----------+------------------+
1 row in set (0.00 sec)

MySQL :: MySQL 5.0 Reference Manual :: 11.11.1 GROUP BY (Aggregate) Functions

Om det är rätt eller inte beror dock på vad du har för mål med det hela, oftast kommer du antagligen vilja ha mer information om personerna och då är det inte så praktiskt att slå ihop raderna iaf.