Databasdesign

Den gröna sommaren av Apan
id
isbn_id
kategori_id
övriga_egenskaper

------------------------------
Är det så du menar? För isåfall är det ju bara att berätta vilket 'id' den ska hämta information ifrån. Det borde fungera :0

ett alternativ är ju att du har en tabell som bara innehåller egenskaper för rubriker.

kategorin bil har id1
kategorin skiva har id2

då har du en tabell för egenskaper såhär:

id, namn, kategoriid
---------------
1, årsmodell, 1
2, färg, 1
3, regnr, 1
4, år, 2
5, titel, 2
6, artist, 2

då kan du ju lägga till egenskaper till kategorin helt fritt.

Samma sak gör du då också med artiklarna.
Artikelid berättar vilken artikel vi pratar om.
egenskapid berättar vilken egenskap detta värde definierar.

Artikel 1 är en bil
Artikel 2 är en cd
(återanvänder data från tabellen ovanför)

artikelid, egenskapid, värde
------------------------
1, 1, 1996
1, 2, "grön"
1, 3, abc123
2, 4, 2004
2, 5 "en dag på sweclockers"
2, 6, "Totoo"

Detta system förutsätter däremot att alla värden lagras lika, t.ex. en sträng på 60 tecken. Detta passar däremot knappast allt (tunga beskrivningar), så antingen gör du ett eget fält för längre texter, t.ex. att varje produkt har dessa "korta beskrivnignar" samt en egen tabell med långa beskrivningar.

Så skulle jag ha gjort.

Jag skulle nog lösa det med arv för få mer kontroll över vilka olika egenskapern som varje kategori har.

Fördelarna blir att du kan ha kontroll på vilka värden som måste vara satta för varje kategori. Du kan även lägga till nya fält för varje kategori om det visar sig att det behövs. Du behöver inte heller fundera på parsning av egenskaper.
Och inte minst så kan du lägga till hur många kategorier som du vill utan att behöva ändra i någon annan tabell.

Nackdelen är att du måste göra en ny tabell för varje kategori som du vill skapa. Det är dock inget stort jobb enligt mig. Insättningarna till databasen bör göras med stored procedures för att det gör utvecklingen av klienten mycket lättare.

Jag antar att du kan lite sql så ja skriver koden direkt.
Skrivet för MS SQL Server:

create table vara (
kId			int identity(1,1),
kSubkat		varchar(20) not null check( kSubkat <> ''),

PRIMARY KEY(kId)
);

create table bil (
kId			int, 
bId			int identity(1,1),
--massa olika
--saker man vill ha
--som beskriver en bil

foreign key(kId) references kategori(kId),
primary key(bId, kId)
);

"vara" är tabellen där alla varor ligger. Där kan man lägga till fler gemensamma egenskaper som tex Artikelnummer etc. kSubkat-kolumnen är tänkt att innehålla namnet på den "child"-tabell som informationen om själva varan ligger i, tex "bil"

I "bil"-tabellen finns alla fält som beskriver en bil.
När en ny kategori skall läggas till kan denna tabell användas som template.

Nu kan man köra "SELECT * FROM bil" och få fram alla bilar med alla deras attribut.

Denna artikel är bra http://www.phlonx.com/resources/nf3

Tar upp hur normalisering fungerar.

Sen har du http://en.wikipedia.org/wiki/Database_normalization