Producten met veel specificaties, hoe bewaren?

Heb je al iets van een programma opstaan? Heb je enige ervaring met Javascript, jQuery, PHP, MySQL?

Begin bij het begin, zet eerst eens je formulier op, met handmatig alle opties. Kijk of je daar uit komt. Dan kun je het later uitbreiden naar dynamisch ophalen en nog later verder.

Ik ben eigenlijk meer benieuwd naar het gedrag van de artikel-informatie. Is deze altijd hetzelfde van opzet (in welk geval je misschien zelfs zou kunnen volstaan met een enkele tabel :p), of hebben verschillende artikelen verschillende (sets van) eigenschappen? Dan zou je die misschien nog kunnen categoriseren. Veel van de database-opzet hangt hier vanaf lijkt mij.

Ook lijkt er een soort hierarchie (boomstructuur?) te zitten in de eigenschappen zelf.

Ook zou je kunnen denken aan een dynamische structuur, waarbij je de volgende opzet hebt:
tabel met standaard artikelinformatie (1)
tabel met eigenschappen (2)
tabel met waarden van eigenschappen per eigenschap (3)
koppeltabel tussen artikelen (1) die gelinkt worden aan specifieke waarden van eigenschappen (3)

Maar dat is misschien een schot te ver voor de boeg, simpelweg omdat we geen representatieve samples van concrete artikelen hebben.

Daar bovenop, als je eigenschappen dynamisch zijn zul je ook rekening moeten houden met het *type* van de eigenschap. Zij het boolean, numeriek, een string of weet ik veel wat. De opslag zal per type verschillen, en dit kun je op verschillende manieren oplossen. Je zou kunnen denken aan aparte tabellen per type eigenschap, of een combinatie van kolommen waar altijd maar 1 van gevuld is. Het is maar net hoe generiek de opzet moet zijn. Want nee, een INT of DECIMAL in een VARCHAR is een no-go. Dan kun je er immers niet meer mee rekenen, en dus ook niet meer fatsoenlijk filteren op eigenschap.

Tabel 1: artikelen
== Uniek ID (foreign key)
== Artikelnummer (streepjescode?)

Tabel 2: kenmerken
== het ID van het artikel
== Datumtijd van toevoegen van kenmerk
== Naam van kenmerk (bijvoorbeeld: Naam, omschrijving, gewicht, prijs, aantal_op_voorraad)
== Inhoud van kenmerk (bijvoorbeeld: Cirkelzaag, "een ronde zaag", 1800, 36.33, 12

Dus een cirkelzaag van 1800 gram en 36,33 euro. En je hebt er 12.

Zo kan je ongelimiteerd aantal kenmerken toevoegen. Waaronder prijs (die kan wijzigen... je voegt gewoon een NIEUWE rij toe aan tabel Kenmerken, ID = 3847, Naam = "Prijs", Inhoud = "36,33"
Zo ook met breedte/gewicht/wattage/kleur/etc etc etc.
Voordelen: je kan prijswijzigingen bijhouden en een geschiedenis opbouwen.
Je zit niet met lege kolommen voor kenmerken maar komt er ook nooit te kort.
Bij meerdere

En wat voor type zou jij de inhoud van het kenmerk dan maken? VARCHAR? In dat geval zou ik toch even herzien. Een getal is een getal, en geen VARCHAR. Als je er zinnige dingen mee wil doen zul je dat in het juiste kolomtype moeten stoppen.

Hoi mensen, bedankt voor jullie reacties! Ik heb ondertussen deze tabellen opgebouwd:

CREATE TABLE `productspecs` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `level` int(11) DEFAULT NULL,
  `name` varchar(100) DEFAULT NULL,
  `value` varchar(100) DEFAULT NULL,
  `main_group_id` int(11) DEFAULT NULL,
  `product_id` int(11) DEFAULT NULL,
  `price` float DEFAULT NULL,
  PRIMARY KEY (`id`)
)

CREATE TABLE `products` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `description` varchar(100) DEFAULT NULL,
  `category_id` int(11) DEFAULT NULL,
  `info` text,
  PRIMARY KEY (`id`)
)

Met deze structuur kan ik als volgt te werk gaan:

Het product: een fotoblok (foto gedrukt op een houten paneel)

Dit product krijgt in tabel 'products' bv ID 4, dan is dit de inhoud van tabel 'productspecs' voor dit artikel:

INSERT INTO `productspecs` (`id`, `level`, `name`, `value`, `main_group_id`, `product_id`, `price`)
VALUES
	(8, 1, 'Materiaal', 'Berkenplexhout 40mm', 0, 4, 0),
	(9, 2, 'Formaat', '10 x 15 cm', 8, 4, 4.2),
	(10, 2, 'Formaat', '15 x 15 cm', 8, 4, 6.29),
	(11, 2, 'Formaat', '20 x 30 cm', 8, 4, 16.78),
	(12, 2, 'Formaat', '30 x 40 cm', 8, 4, 33.57),
	(13, 3, 'Whitewash', 'Ja', 9, 4, 1.5),
	(14, 3, 'Whitewash', 'Nee', 9, 4, 0),
	(15, 3, 'Whitewash', 'Ja', 10, 4, 2),
	(16, 3, 'Whitewash', 'Nee', 10, 4, 0),
	(17, 3, 'Whitewash', 'Ja', 11, 4, 2.5),
	(18, 3, 'Whitewash', 'Nee', 11, 4, 0),
	(19, 3, 'Whitewash', 'Ja', 12, 4, 4),
	(20, 3, 'Whitewash', 'Nee', 12, 4, 0);

Veld 'main_group_id' verwijst dan naar de id in dezelfde tabel van de bovenliggende specificatie.
Veld 'level' duidt de stap aan.

Dus in dit voorbeeld beginnen we bij stap 1: Materiaal. Hier is er maar één keuze van materiaal na deze keuze wordt de volgende stap gekozen: Formaat. Hier keuze uit 4 formaten. Bij de formaten staan ook (voor de eerste keer) prijzen ingevuld. Dus bij keuze van een formaat wordt de prijs gekozen. De volgende stap is dan Whitewash. Afhankelijk van het gekozen formaat, is er een andere meerprijs (indien er JA gekozen wordt). Die prijs wordt dan bij opgeteld bij de vorige prijs.

Voor een eenvoudig product als dit, is dit perfect haalbaar, maar je ziet dat in dit voorbeeld de vraag 'whitewash' 8 keer terugkeert (afhankelijk van mogelijke antwoorden van de vorige stap), dus bij een meer gecompliceerd product komt vele specificaties steeds terug en wordt de tabel zeer groot.

Ik heb een ingewikkeld product geprobeerd, en zit ondertussen al aan 1600 records in de tabel en ik ben nog niet rond :-)
Daarom mijn vraag of dit op een andere manier te bewaren is in de databank.

Groetjes!

CREATE TABLE `productspecs` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `level` int(11) DEFAULT NULL,
  `name` varchar(100) DEFAULT NULL,
  `value` varchar(100) DEFAULT NULL,
  `main_group_id` int(11) DEFAULT NULL,
  `product_id` int(11) DEFAULT NULL,
  `price` float DEFAULT NULL,
  PRIMARY KEY (`id`)
)

Je gebruikt voor level een INT(11), waarom zo groot? Als het om stappen gaat kun je volgens mij ook met TINYINT uit de voeten?
https://dev.mysql.com/doc/refman/5.7/en/integer-types.html
Daar kunnen 255 stappen in.

Dit is overigens ook voor je VARCHAR:
https://dev.mysql.com/doc/refman/5.7/en/char.html

Persoonlijk zou ik nog een aantal tabellen maken:
product_materials
product_size
product_finish

In deze tabellen komen dan ook weer unieke ID's aan elke regel.
In productspecs kun je deze dan koppelen aan de hand van de ID's. Zo kun je b.v. bepaalde keuze opties maken per product.
(Je zult dan de kolomnamen moeten aanpassen)

Als een extraatje nog: ik zou dimensies nooit (alleen) als tekst opslaan. Je hebt specificaties immers ook zodat je makkelijk kan zoeken. Je zou complete menustructuren kunnen bouwen op basis van wat je aan specificaties hebt.