Ett id till flera bilder utan reduntant data? Nybörjarfråga

Har fått lära mig att man inte ska få redundant data i sin databas, dvs dubletter

Jag har ett ID ex AAA, detta ID länks samman med flera bilder i databasen, samma med ex id BBB. Hur gör man det för att det inte ska bli redundant?

Gör jag så hör blir det ju en upprepning av mina ID

UniktID | ImageURL
AAA image1.png
AAA image2.png
AAA image3.png
BBB image4.png
BBB image5.png
BBB image6.png
BBB image7.png
BBB image8.png

Fast grejen med ett ID är väll att det skall vara unikt.
Du kan inte ha upprepning av IDna, då kan du ju inte skilja på bilderna.

Är bilderna likadana borde du kunna ta bort alla utom en.

Ett sätt att kolla detta är ju faktiskt att beräkna nån hash, typ MD5 av varje bild och jämföra om de är lika. Hurvida det är smart att göra detta i SQL eller inte, det har jag förlite erfarenhet för att säga.
Jag skulle nog göra det i min programkod, men funktionaliteten finns iaf:
http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html

Tror du missförstod min fråga. Det är inte ett klassiskt uppräknat id utan snarare ett id för att visa att de hör ihop. En gruppering av bilderna.

Det jag vill åstakomma är ju att när jag väljer att skriva ut alla med AAA så kommer image1.png, image2.png och image3.png att skrivas ut.

Skulle kunna vara så här i stället då
Volvo | 240
Volvo | V70
Volvo | V40
BMW | Z23
BMW | K79

Där Volvo och BMW blir redundant i tabellen. Med en fråga vill jag ju sen kunna skriva ut ex alla volvo-bilar.

Känns som att jag pratar om en till många relation? Var så länge sedan jag höll på med det här.

Jag tycker att det ser bra ut, eftersom att det är kombinationen som är väsentlig så har du ju inga dubletter.

Det du vill är ju att databasen skall vara i tredje normalfrom antar jag.
Det betyder att det inte får finnas någa duplicerade rader. Notera att detta inte betyder
att kolumner där data är samma inte får existera.

Kolla t.ex. på http://en.wikipedia.org/wiki/Third_normal_form

I exemplet är året 1999 duplicerat i 3:e normalform.

Om du vill kan bryta ut bilmärkena i två tabeller, en "Volvo tabell" och en "BMW tabell", så sätter du in primärnycklarna (det uppräknade unika idt ) i respektive tabell beroende på vad det är för bil.

Men, jag tycker inte att det är nödvändigt att göra det om det inte finns mer information om en Volvo eller en BMW, då måste du göra det.

vare sig det är 2-3 eller 50 olika "bil märken" så ska du fortfarande köra det i en separat tabell. Gör rätt från början då det rätta alternativet tar mindre space också. En int är mindre i storlek än massa text som du ska ha i tabellen.

Exempel på tabeller du kan skapa för att åstadkomma det du vill:

Bilmärken
{
id
name
} = Bilmärken = (1,volvo) (2, bmw)

Bilägare
{
id
BilID
name
} = Bilägare = (1,1,Johan) (2,1, Nicklas) (3,2, Simon)

Så joinar du bara tabellerna beroende på vad du är ute efter.

Du nämner svaret själv, "gruppering", alltså grupp
Image
Image_ID PK
ImageURL Index, för sökning. Vill endast tillåta unika namn anger du det här

Group
Group_ID PK
Image_ID FK Vill du bara ha unika bilder anger du det här
GroupName Index, för sökning. Vill endast tillåta unika namn anger du det här

Nu kan ett valfritt antal bilder ingå en grupp, vill du tillåta en viss bild i endast en grupp eller i flera så gör du det enligt ovan i gruppen.

Detta är ju samma sak som att säga att en person kan ha flera telefonnummer. Dvs en sk multivalued attribute. Där en person kan ha flera telefonnummer men en telefonnummer kan bara användas av en person. Då kan man ha telefonnumret som pk:

T
id|phone
1 | 070
1 | 071
1 | 072
2 | 073
etc

Så nej det bryter inte mot 3NF. För att bryta mot 3NF så måste det finnas ett beroende mellan en icke primär attribut till en annan icke primär attribut.

Just nu har vi dessa beroenden:
phone -> id

Jävligt enkelt att testa att den inte bryter mot varken 2NF eller 3NF

phone finns bara i vänster sida av relationen medan id finns bara i höger.
p= phone och np = id

Eftersom det inte finns någon sammansatt nyckel i relationen så kan den inte bryta mot 2NF. Och eftersom ingen transitiv beroenden finns så är relationen i 3NF.

EDIT: Självklart ska du inte uppdatera/delete'a utefter id utan telefonnummer annars kommer du få anomalier som t.ex att du råkar ta bort alla telefonnummer eller ett duplicate primary key error om du använder id för att uppdatera men det vet du säkert .

Den nämnda MD5-funktionen tar en sträng som argument, men en bild-fil är av typen binär.

Skulle man använda den MD5-funktionen så stannar den ihopräkningen av MD5 summan vid första bästa NUL byte

Bättre att använda en MD5-funktion avsett för binärfiler än för textsträngar.

Med denna modellering kan en grupp bara bestå av max 1 bild, så nåt gick nog fel här..