[DB] algemeen: oude en nieuwe producten / snelheid

[easydisk]

Ik zat laatst te denken: Je hebt een database (draaiend met mysql) en een tabel met producten of iets, je kan dan de actieve producten van de oude (welke je niet meer verkoopt) scheiden door:
-de oude weg te halen, maar tja wel zonde van de informatie en je orders die aan zo'n product gekoppeld zitten raken dus ook verloren, tenzij je de informatie overneemt in de order (zoals oscommerce doet bijv.)
-een kolom met product_disabled of zo te maken Y/N (je laat alleen actieve producten zien, maar oders blijven toch de info houden over de oude producten)...

maar als je de oude producten nu verplaatst naar een andere tabel ?
Voordelen zijn dat sql queries wel (redelijk) snel blijven, je de informatie toch behoud en je orders aan products_id's blijven kloppelen. Nadeel.. Je moet meer regels programmeren als je oude orders wilt bekijken, namelijk de 2 tabellen door nemen.

Heeft dit toch voordelen of ook nadelen ? Wil je later je oude producten/orders/leerlingen/gegevens naar een andere tabel verhuizen ? Wie doet dit ? en vanaf hoeveel records doe je het ? of zijn er andere mogelijkheden ?

Oh ja en het upgraden van hardware/extreme servers gebruiken laten we buiten beschouwing..

[whoami]

Wat versta je met veel records in een tabel ?

Als je een beetje een goede index - strategie hebt, mag het opzich niet zo veel uitmaken dat er 1000.000 records in je tabel zitten.
In sommige gevallen kan het echter interessant zijn om oude gegevens (historische gegevens) naar een 'history' tabel te verplaatsen.

Als je 'inactieve' records gaat verwijderen, dan ga je een probleem hebben met referentiele integriteit.

[djluc]

Het is veel werk en voor een productentabel volgens mij ook totaal overdreven? Ik neem aan dat je geen miljoenen producten in je db hebt staan? Bijvoorbeeld: je wilt een prijsgrafiek maken van de ontwikkeling van de prijzen van MP3 spelers. Dan wil je dit doen van zowel de producten die je nog op de site hebt staan als de oude producten. Dan moet je al meteen alle gegevens van de 2 tabellen gaan joinen. Zo kost alles om te ontwikkelen veel meer werk. Je moet kijken wat uiteindelijk het beste resultaat voor de beste prijs/kosten opleverd.

[easydisk]

Ik kwam er op aan de hand van het bekijken van oscommerce (kan goed groeien qua optie mogelijkheden, maar toch niet echt super qua snelheid) en ooit zelf geschreven scriptjes en vroeg me dus af hoe dat normaal zou gebeuren, bijv in het bedrijfs leven.

Het is meer gewoon even denken over of het een goed idee zou zijn. Je informatie tuurlijk wel lang genoeg in de normale tabel houden om niet te veel moeten joinen maar ook weer snel/handig. Uiteraard is het per keer verschillend, maar ja soms kan je niet in de toekomst kijken en moet je op het ergste voorbereid zijn..

Implementatie in een huidig systeem hoeft niet al te moeilijk te zijn: een script wat je 1x per (half)jaar draait en alleen als je iets wilt zoeken in de oude gegevens moet je het aanpassen. En de aanpassingen zijn over het algemeen niet van grote aard: kolom namen, informatie, koppelingen, etc blijven het zelfde.

Overigens was de nadruk hier misschien teveel gelegd op producten (wie heeft er nu 200.000 procuten te koop ) maar het kan tuurlijk ook voor klant gegevens gaan of leerlingen of metingen van de temperatuur sinds 1900 of zo.
Daarnaast is het tuurlijk erg 'vaag' zal je niet weet of je over 10 of 10 miljoen regels praat maar het gaat hier meer om het idee.

[Johnny]

Als je met zoveel data werkt dat het performance problemen geeft, en je een beperkt gedeelte van die data vaak nodig hebt dan is er volgens mij maar een voor de hand liggende optie: caching, op die manier haal je een performancewinst zonder dat je het hele datamodel moet omgooien.