[DB] Kommagescheiden waarden en efficiency?*

[Verwijderd]

In een mysql tabel moet ik voor elke rij 30 id nummers opslaan. Nu kan ik 30 kolommen maken genaamd id1, id2, ..., id30. Nu hoorde ik van iemand die beweerde dat dat niet erg efficient is omdat je tabel zo 30 keer groter zou worden dan als je 1 kolom maakt en daar een string indoet met alle ids gescheiden door komma's. In het programma dat de database gebruikt programmeer je dan ff een lijn die die string ontrafelt en opslaat in een array voor gebruik in het programma.

Nu weet ik niet of dit een betere oplossing is dan 30 kolommen aanmaken. Het lijkt me dat de database meer werk gaat hebben in het geval dat er 30 kolommen komen, maar dat het programma dat de data gebruikt meer werk gaat hebben in het andere geval, want die moet dan voortdurend een array aanmaken met 30 variabelen in. Zowel de database als het programma staan op dezelfde machine.

Dus eh... welke oplossing is beter?

[NMe]

Kommagescheiden waarden horen niet in een relationele database thuis.

Echter, jouw opzet is ook niet goed. Veldnamen met nummers duiden bijna altijd op een slecht genormaliseerd ontwerp. In combinatie met je eigenlijke vraag durf ik wel met enige zekerheid te zeggen dat je je database beter moet gaan normaliseren.

[Verwijderd]

Ik moet toegeven dat ik niet vaak eerder n database structuur heb gebouwd, dus wat je zegt kan heel goed waar zijn

Het idee is dat in bovenstaande tabel elke rij 30 ids bevat. Elk id verwijst in een tweede tabel naar een set data die overeen komt met dat id. Die tabel bevat meer dan 1000 rijen gegevens, waarvan er 30 op elke rij uit tabel 1 van toepassing zijn. Welke 30 van de 1000 dat zijn, wordt bepaald door de 30 opgeslagen id nummers.

Ik vind dit op zich best een prettige oplossing, maar als het beter kan hoor ik het graag.

[NMe]

Wat nou als je later ineens liever 40 links wil leggen in plaats van 30? Kun je dan ineens je hele datastructuur omver gaan gooien.

Je zou er goed aan doen hier eens te beginnen met lezen, en verder wat informatie zoeken over wat koppeltabellen (pivot tables) zijn en hoe je die kunt toepassen. Onmisbare kost voor iedereen die met relationele databases bezig is.

[gorgi_19]

Verwijderd schreef op zondag 11 juni 2006 @ 20:30:
Ik moet toegeven dat ik niet vaak eerder n database structuur heb gebouwd, dus wat je zegt kan heel goed waar zijn

Het idee is dat in bovenstaande tabel elke rij 30 ids bevat. Elk id verwijst in een tweede tabel naar een set data die overeen komt met dat id. Die tabel bevat meer dan 1000 rijen gegevens, waarvan er 30 op elke rij uit tabel 1 van toepassing zijn. Welke 30 van de 1000 dat zijn, wordt bepaald door de 30 opgeslagen id nummers.

Ik vind dit op zich best een prettige oplossing, maar als het beter kan hoor ik het graag.

Waarom vinden mensen 1000 rijen al veel voor een database? Een beetje normale database begint bij een miljoen of 4 aan rijen.

[Verwijderd]

Ik zeg ook niet dat het veel is, ik bedoel dat het niet te doen is om alle mogelijkheden om 30 opties uit 1000 te kiezen apart in een rij te gaan zetten.

[Verwijderd]

-NMe- schreef op zondag 11 juni 2006 @ 20:34:
Wat nou als je later ineens liever 40 links wil leggen in plaats van 30? Kun je dan ineens je hele datastructuur omver gaan gooien.

Nou, dan maak ik gewoon 10 velden bij met id nummers die verwijzen naar die andere tabel net zoals de eerste 30. Lijkt me net erg makkelijk uit te breiden eigenlijk Die link lijkt me wel een interessant artikel, ff helemaal doorlezen.

In elk geval bedankt voor de hulp

[Freee!!]

Na het doorlezen van de hele draad, ben ik het toch echt met -NMe- eens dat een koppeltabel een stuk flexibeler en daarmee handiger is. Denk maar eens aan de mogelijkheid dat sommige rijen maar 25 waardes hoeven te bevatten en een enkele al 31.

[whoami]

Eens met NMe en Mr. Liu.
Een koppeltabel lost dergelijke problemen op, tenzij je echt een goede reden hebt om het niet zo te doen.

Trouwens: of je nu 30 kolommen gaat hebben, of één kolom met komma separated values (wat zowiezo not done is), dan zal je met die comma-separated string meer plaats innemen.
Voor zo'n separated string heb je nl. minstens een varchar (30) nodig om je 30 waardes op te slaan (als je waarde max. 1 lang is), en je hebt dan nog eens 29 posities nodig om je komma's of whatever in op te slaan. Bij een volledige bezetting heb je dus 59 bytes nodig.
Als je voor 30 kolommen kiest, heb je al geen plaats nodig om die separators op te slaan.

Maar goed, zowiezo zijn beide opties niet goed. Hoe ga je een ingewikkelde query hier op los laten ? Lees bv ook eens deze draad:
[rml][ MySQL] LIKE query op komma-gescheiden veld[/rml]

[NMe]

Verwijderd schreef op zondag 11 juni 2006 @ 21:43:
Nou, dan maak ik gewoon 10 velden bij met id nummers die verwijzen naar die andere tabel net zoals de eerste 30. Lijkt me net erg makkelijk uit te breiden eigenlijk

Je tabel aanpassen is nog het eenvoudigste gedeelte. Daarna moet je alle queries in je hele applicatie nog van een update voorzien.

Als je netjes een koppeltabel gebruikt is het aantal id's dat je in kan vullen zo variabel als je zelf wil, en hoef je simpelweg nooit je databaseontwerp aan te passen als je ineens 40 velden wil linken in plaats van 30.

[.oisyn]

whoami schreef op zondag 11 juni 2006 @ 21:56:
Trouwens: of je nu 30 kolommen gaat hebben, of één kolom met komma separated values (wat zowiezo not done is), dan zal je met die comma-separated string meer plaats innemen.
Voor zo'n separated string heb je nl. minstens een varchar (30) nodig om je 30 waardes op te slaan (als je waarde max. 1 lang is), en je hebt dan nog eens 29 posities nodig om je komma's of whatever in op te slaan. Bij een volledige bezetting heb je dus 59 bytes nodig.
Als je voor 30 kolommen kiest, heb je al geen plaats nodig om die separators op te slaan.

Helaas, bij een varchar moet ook de lengte opgeslagen worden (hoe weet het rdbms anders hoe lang de string is?). Bij een enkele kolom kost dit hoogstens een byte, bij meerdere kolommen moeten er meerdere lengtes opgeslagen worden.

Maar goed, niet dat ik csv-fields in een db wil verdedigen ofzo

[NMe]

offtopic:
Om het jezelf makkelijker te maken zou je (in het hypothetische geval dat je tòch comma seperated zooi in je DB gaat rossen) het scheidingsteken voor en achter elk teken moeten zetten, zodat zoeken met LIKE vergemakkelijkt wordt. Bij de files die je DB gebruikt staat er alleen een scheidingsteken tussen de velden, terwijl het in het andere geval ook voor en achter het veld staat, wat dus twee extra scheidingstekens zou opleveren. Minimaal 2 bytes verschil dus, plus de "echte" scheidingstekens die je DBMS zelf nodig heeft.

[Verwijderd]

Na het lezen van dat artikel en de voorbeelden door te spitten was ik ook al tot de conclusie gekomen dat een tabel met een rij per kiezer en gekozen optie een beter idee is. Waarschijnlijk kom ik nu een stuk verder. Bedankt voor de suggesties