[PHP/MySQL] Serialize versus koppeltabellen

[Verwijderd]

Ik ben op het moment verzeild geraakt in een discussie met een vriend van me, waar we niet uit komen. We zijn bezig met een website met MySQL database die waarschijnlijk in de toekomst een hoge serverload op zal leveren (script en DB gewijs). Bij het ontwerp van de database wilde ik het volgens de 'officiele' manier doen. Dus elke n:n relatie krijgt een eigen koppeltabel.

Volgens hem zou dit te veel load op leveren en is het serializen van een array een veel makkelijkere oplossing. De geserializede array moet dus opgeslagen worden in een enkele kolom van de tabel.

Wat is jullie mening hier over? Levert het gebruik van koppeltabellen een (significant) hogere load?

[NMe]

Serializen.

Uitgebreider antwoord: probeer maar eens snel te zoeken in een enkel, geserialized veld. Dat gaat met een koppeltabel echt wel sneller, zelfs in MySQL. Luister asjeblieft niet naar je vriend en gebruik gewoon een koppeltabel.

[sig69]

Dat hangt er een beejte vanaf wat er in die tabellen staat, en hoeveel records je tabellen gaan bevatten. Maar met een paar goede indexes kom je een heel eind.

en is het serializen van een array een veel makkelijkere oplossing. De geserializede array moet dus opgeslagen worden in een enkele kolom van de tabel.

Dit zou ik dus absoluut niet doen... , of je moet er HEEL goede redenen voor hebben.
Misschien kan je beter beide situaties eerst eens goed performance testen ipv wat aannames uit de lucht te grijpen?

[Verwijderd]

Hier spreekt "de vriend"

Raar genoeg heb ik al een groot systeem omgebouwd met deze methode, waarna het vele malen soepeler werkte. Maar wellicht kan dat gewoon aan de structuur hebben gelegen. Ik vond dit toendertijd een praktische oplossing in ieder geval.

[whoami]

Werken met koppeltabellen biedt in vrijwel alle gevallen een betere performantie dan serializing.
Plus, het is onderhoudbaarder, duidelijker, en je kan er makkelijkere queries voor schrijven en queries die je beter kunt optimalizeren.

Als je een applicatie schrijft, met daarachter een DB, en je wilt dat die applicatie een beetje performant is, dan begint alles met een goed datamodel.

Verwijderd schreef op dinsdag 08 november 2005 @ 12:29:
Hier spreekt "de vriend"

Raar genoeg heb ik al een groot systeem omgebouwd met deze methode, waarna het vele malen soepeler werkte. Maar wellicht kan dat gewoon aan de structuur hebben gelegen. Ik vond dit toendertijd een praktische oplossing in ieder geval.

Ben je bekend met het concept 'indexen' ?

[ Voor 36% gewijzigd door whoami op 08-11-2005 12:30 ]

[NMe]

Verwijderd schreef op dinsdag 08 november 2005 @ 12:29:
Hier spreekt "de vriend"

Raar genoeg heb ik al een groot systeem omgebouwd met deze methode, waarna het vele malen soepeler werkte. Maar wellicht kan dat gewoon aan de structuur hebben gelegen. Ik vond dit toendertijd een praktische oplossing in ieder geval.

Ik ben bang dat het eerder aan het eerdere systeem gelegen zal hebben. MySQL kan gebruik maken van indexen, jij niet, met een veld met comma separated waarden.

[Verwijderd]

-NMe- schreef op dinsdag 08 november 2005 @ 12:27:
Serializen.

Uitgebreider antwoord: probeer maar eens snel te zoeken in een enkel, geserialized veld. Dat gaat met een koppeltabel echt wel sneller, zelfs in MySQL. Luister asjeblieft niet naar je vriend en gebruik gewoon een koppeltabel.

Het idee is dus wel dat alle informatie die in 1 cel zit tegelijk opgevraagd wordt.

Dat hangt er een beejte vanaf wat er in die tabellen staat, en hoeveel records je tabellen gaan bevatten. Maar met een paar goede indexes kom je een heel eind.

Wel een hele hoop.

Hadden we nou om een fles whisky gewed borked?

[frickY]

Serializen geeft veeel meer overhead dan een koppeltabelletje. Om een vergelijking te kunnen doen moet je de kolom selecteren, unserializen, en vervolgens nog een selectie doen met de gegevens uit de array (voor zover ik weet kan MySQL niet serializen, maar zelfs als hij het wel kan blijft een string-operatie zwaarder dan een integer vergelijking).

Draai anders voor de lol maar eens een benchmark met beide methodes

[whoami]

Ik heb hier trouwens nog een leuk linkje voor je.
[rml][ MySQL] LIKE query op komma-gescheiden veld[/rml]

[Verwijderd]

Verwijderd schreef op dinsdag 08 november 2005 @ 12:31:

Hadden we nou om een fles whisky gewed borked?

Je mag met oud&nieuw m'n tequilla opzuipen

Conclusie: ik moet meer leren over indexen. Nuff said

[Verwijderd]

Het argument dat ik hier helemaal niet voorbij hoor komen is dat serialize een taal-gebonden optie is. Voor velen van jullie zijn PHP en MySQL een onlosmakelijke combinatie, maar wat als iemand in de toekomst een odbc koppeling wil maken naar je db of een simpele database export en import wil doen. Zit je mooi te kijken met je geserializde () velden.

[curry684]

whoami schreef op dinsdag 08 november 2005 @ 12:30:
Werken met koppeltabellen biedt in vrijwel alle gevallen een betere performantie dan serializing.

Vrijwel?

Nu maak je me benieuwd naar die ene obscure uitzondering waar comma-separated values met LIKE wel performant uit de bus zouden komen, want ik kan 'm niet bedenken

[whoami]

Ik had het niet over comma separated values, maar over serialized bitfields.

[Woy]

Verwijderd schreef op dinsdag 08 november 2005 @ 12:53:
Het argument dat ik hier helemaal niet voorbij hoor komen is dat serialize een taal-gebonden optie is. Voor velen van jullie zijn PHP en MySQL een onlosmakelijke combinatie, maar wat als iemand in de toekomst een odbc koppeling wil maken naar je db of een simpele database export en import wil doen. Zit je mooi te kijken met je geserializde () velden.

Je kan voor die taal natuurlijk ook je eigen unserialize maken

[Verwijderd]

Serializen is interessant als de structuur van de gegevens niet op voorhand geweten is. VB: een platform dat ik geschreven heb waarmee men berekingsapplicaties kan aanmaken doormiddel van XML te specifieren. De structuur van de gegevens is niet op voorhand bekend en de gegevens moeten niet doorzoekbaar zijn, hiervoor is serializen interessant omdat het de dingen inderdaad simpeler maakt (de XML liet arbitrair complexe constructies toe)

[NMe]

Ook dat kun je met een aantal koppeltabellen oplossen, afhankelijk van wat je precies doet. Granted, je zal elk type waarde als string moeten opnemen, ook als het een integer is, maar het betekent wel dat je indexen kan gebruiken bij het zoeken.

[Verwijderd]

En als ik nu deze tabel heb. Deze tabel is voor een webshop de tabel met producten heeft een kolom p_options_id als deze niet 0 is zijn er product opties. Dit is bijvoorbeeld de kleur van dat product. osCommerce gebruikt hier 4 tabellen voor.

code:

 CREATE TABLE `s_product_options` (

  `product_options_id_internal` int(10) unsigned NOT NULL auto_increment,

  `po_options_id` int(10) unsigned NOT NULL default '0', -- link naar tabel: "s_products"
  `po_language_id` int(10) unsigned NOT NULL default '1',
  
  `po_name` varchar(255) NOT NULL default '', -- Kleur = (heeft als id product_options_id_internal)
  `po_values` text NOT NULL, -- serialized array b.v array(0=groen, 1=geel, 2=rood , 3=paars)
  
  `po_price` decimal(15,4) NOT NULL default '0.0000',
  `po_operator` set( '+' , '-' , '*' , '/' ) NOT NULL default '+',
  
  PRIMARY KEY  ( `product_options_id_internal` ),
  KEY `view_product_options` ( `po_options_id` , `po_language_id` )

) TYPE=InnoDB AUTO_INCREMENT=1;

[ Voor 15% gewijzigd door Verwijderd op 08-11-2005 23:40 ]

[NMe]

Wat is je vraag nu?

Die po_values is in elk geval niet goed. Dit is het schoolvoorbeeld van een tabel die niet goed genormaliseerd is, als je po_values niet afsplitst via een koppeltabel.

Je kan trouwens ook [code=sql] gebruiken, dan wordt je SQL-code gehighlight.

[Verwijderd]

Dan maar een paar tabelletjes er bij, is nog sneller ook als je de indexen goed hebt.

[Verwijderd]

Ik heb het wel eens eerder geroepen, maar voordat een website die ontwikkeld is in PHP i.c.m. MySQL écht moeilijk gaat doen, lees, voordat een server dermate veel requests krijgt dat hij moeilijk te benaderen wordt - waarbij ik er van uit ga dat de structuur optimaal is - moet je echt véél bezoekers krijgen. Denk dat er maar weinig mensen rondlopen hier, with all do respect, die veel te maken hebben met zulke websites. Uitzonderingen daargelaten natuurlijk

En om dan ook nog even ontopic te reageren, een koppeltabel is natuurlijk vele malen beter, IMO.

[PrisonerOfPain]

curry684 schreef op dinsdag 08 november 2005 @ 12:56:
Nu maak je me benieuwd naar die ene obscure uitzondering waar comma-separated values met LIKE wel performant uit de bus zouden komen, want ik kan 'm niet bedenken

Nou vraag ik me wel af, waarom in dit PDF'je over inverted indices dan wel word gekozen voor een manier van 'serializen' in plaats van van een normale koppeltabel. Zelf zou ik voor de koppeltabel gegaan zijn, maar het heeft me toch aan het denken gezet.