Archief - Database probleem

Geachte,

Ik zit al met het volgende probleem / vragen,

In de beginjaren toen database ontstonden werkten veel projecten op de manier van "tabel", en vervolgens een rij cols. Bv een tabel met al je contacten in, vervolgens (100 contacten) van telkens een 15 tal cols.

De "hedendaagsere" manier van werken is (of ik lees dit her en der) is plat te werken, bv voor elke contact heb je 15 records met telkens een eigen waarde in. Deze zijn verbonden aan elkaar via een uniek ID. Op die manier heb je veel mogelijkheden van data uit lezen. Ook kan je perfect een dynamisch systeem maken die er voor kan zorgen dat je zowat alles kan opslaan in één zelfde structuur zonder ook maar één tabel te moeten aanpassen.

Maar,

Nu is mijn vraag,

Wat als je een database hebt met 300 000 variabele artikelen. Waar er bv 60 verschillende soorten artikelen zijn met telkens afzonderlijke eigenschappen (en ook gedeelde eigenschappen) Dan zit je al snel met een tabel van 300 000 (unieke artikelen) x aantal eigenschappen (die ingevuld zijn)

Een database plat staan is handig omdat je hier variabel data kan uitlezen, maar wat met "ik wil alles van 12 V + Met als kleur Rood, + ...).

Op welke manier doe je best de uitlezing dan online? Want ik kan me niet voorstellen dat je "on the fly" op een db van meer dan een miljard records gaat queryen, + het is plat?


Graag uw reactie!

Ook al eens naar NoSql gekeken?

Ze noemen dit normalisatie. Maar normalisatie tot het uiterste drijven zorgt - zoals je zelf al vermoedt - tot een enorme performantiehit. Een combinatie van tabellen en normalisatie is vaak de beste oplossing.

Vaak gaat men ook genormaliseerde databanken "cachen" door ook de niet genormaliseerde tabellen te voorzien voor queries die vaak uitgevoerd worden. Door middel van triggers en dergelijke kan je heel wat toeren uithalen om dit te bereiken.

Ik snap nie tegoei wa ge bedoelt met "online uitlezing", maar een database moet ontworpen worden en dat kan op verschillende manieren.

Een gigantische tabel zoals jij zegt is niet altijd wenselijk. Stel dat ge een personen-tabel hebt, waarin alle informatie staat zoals adres, favoriete films, favoriete muziek en favoriete drank, dan ga je heel veel redundantie (dubbele nutteloze informatie) krijgen.

Stel dat je zo een tupel (een rij in een tabel) zou hebben met favoriete drank "cola" en een andere tupel met "fanta". (met favoriet bedoel ik dan niet DE favoriete, maar gewoon EEN favoriet). Dan zou je twee keer alle favoriete films + muziek + adres in die tabel hebben staan, wat niet leuk is

Daarom gaan ze, zoals Cycloon zegt, zo een tabel normaliseren. In dit geval zou ge een tabel hebben met naam + adres, eentje met naam + favoriete films, eentje met naam + favoriete muziek en eentje met naam + favoriete drank. Als naam je primary key is tenminste. En dan is querying en opslag optimaal.

Maar stel dat je een tabel hebt "naam, straat, huisnummer, telefoonnummer, leeftijd". Dan is nutteloos om dit te normaliseren, omdat al die kolommen rechtstreeks afhankelijk zijn van elkaar.

Wat als je een database hebt met 300 000 variabele artikelen. Waar er bv 60 verschillende soorten artikelen zijn met telkens afzonderlijke eigenschappen (en ook gedeelde eigenschappen) Dan zit je al snel met een tabel van 300 000 (unieke artikelen) x aantal eigenschappen (die ingevuld zijn)

Klik om te vergroten...

Als ge echt naar grote key-value stores wilt gaan, NoSql draait daar rond, wel qua querying niet zo simpel

Een database plat staan is handig omdat je hier variabel data kan uitlezen, maar wat met "ik wil alles van 12 V + Met als kleur Rood, + ...).

Klik om te vergroten...

Wilt iemand dat echt? iemand wilt niemand een bepaald type artikel en daar verder gedetailleerd gaan zoeken
vb electro spullen site, vandenborre is een goed voorbeeld van een leuke zoek functie en dat is per type artikel (zelfs meer dan 60 types)

Wat ik zou doen is vrij gedenormaliseerd te werk gaan en van die 60 artikels kijken als ik er daar nog een paar samen in een tabel zou kunnen stoppen
Daarop dan de specifieke artikel-type search

En de volledige beschrijving als text intern opslaan en daarop een full-text catalog search maken.
voor den typische textbox search

Bedankt voor onderstaande reactie.

Ik snap volledig wat je hier wil zeggen, normalizere is goed, maar over normalizeren is dit zeker niet.

Vandaag heb ik in mijn 60 tal soorten artikelen gekeken wat de gemeenschappelijke zijn, vervolgens deze op geslaan als effectief een coll (zoek probleem opgelost) vervolgens data waar ik zelden op zoek heb ik op geslaan in een andere tabel (of eigenlijk kan je het ook in een text veld steken als array (serialize, unserialize).

Heb net mijn plat modem om gezet naar dit model en zo goed als al mijn problemen qua snelheid, zoeken, zijn opgelost!

Als ik mijn les in school van jaren geleden nog eens her bekijk dan was toen alles normalizeren wat de klok sloeg. Echter in de parktijk heeft dit soms emense problemen. (in mijn ogen)