[database] hoe zeer veel velden aanpakken

[? ?]

..

[ Voor 99% gewijzigd door ? ? op 25-01-2013 09:48 ]

[AtleX]

Je zegt zelf al dat het om een boomstructuur gaat, dat kan je toch prima normaliseren?

[NMe]

Normaliseren en met behulp van een koppeltabel een en ander wat opsplitsen. Heck, desnoods een bitmask, maar 90 velden voor wat checkboxjes....

[Ravefiend]

NMe schreef op donderdag 05 februari 2009 @ 11:31:
Normaliseren en met behulp van een koppeltabel een en ander wat opsplitsen. Heck, desnoods een bitmask, maar 90 velden voor wat checkboxjes....

Op T staat ook ergens zoiet ... hmmz .. hierzo:

http://tweakers.net/my.tnet/profile

[whoami]

Radiobuttons sla ik op een één veldje, met een integer waarde. integer = 1 dat duidt aan dat de eerste radiobox aangeduid is, 2 de tweede, enz.

Dus, je koppelt eigenlijk wat UI logica aan je data ? Wat als je later je UI aanpast, en er ergens een radiobutton moet tussenkomen ?

[ Voor 5% gewijzigd door whoami op 05-02-2009 11:41 ]

[? ?]

..

[ Voor 123% gewijzigd door ? ? op 25-01-2013 09:48 ]

[McVirusS]

Als het toch al FK is naar andere tabel waarom gebruik je dan niet gewoon een koppeltabel?

records
-------
record_id
naam_persoon

opties
-------
optie_id
waarde

records_opties
--------------------
optie_id
record_id

[Erkens]

Ravefiend schreef op donderdag 05 februari 2009 @ 11:38:
[...]


Op T staat ook ergens zoiet ... hmmz .. hierzo:

http://tweakers.net/my.tnet/profile

Dat wordt gewoon netjes met een koppeltabel gedaan, dus 1 tabel met alle mogelijke opties en een tabel met enkel de userID en de "optieID". Het zijn namelijk ongeveer 140 opties momenteel, en als je wat wilt gaan nieuwe opties zou willen toevoegen/verwijderen dan denk ik niet dat de database dat leuk vind

[? ?]

..

[ Voor 113% gewijzigd door ? ? op 25-01-2013 09:48 ]

[McVirusS]

"Uit" hoef je toch niet op te slaan? Dan komt die waarde gewoon niet voor in de koppeltabel, dus alleen de opties die gekozen zijn worden gekoppeld.

[Niemand_Anders]

Er zijn diverse manieren om het aantal velden beheersbaar te maken. Hieronder twee methodes welke mij snel te binnen schieten.

Manier 1: Aangezien je zelf aangeeft dat veel checkboxen andere checkboxen tonen kun je heel erg goed met associatieve tabellen (1-op-1 relatie) gaan werken. Wat het is vast wel mogelijk om checkboxen te groeperen. Voor elke groep kun je een associatieve tabel gebruiken en je hoeft pas de gegevens op te halen op het moment dat ze getoond dienen te worden.
Eventueel zou je een view kunnen maken welke alle associatieve tabellen aan elkaar koppelt.

Manier 2: Gebruik de checkbox en radiobutton gegevens in een xml document en sla dat op in de database.
Via een GUI XML schema zou je kunnen eenvoudig aangeven in welke volgorde de checkboxen/radiobuttons getoond dienen te worden. Op het moment dat een checkbox waarde niet direct vanuit de database benaderbaar hoeft te zijn is dit een efficiënte en eenvoudige methode. Daarbij hebben de meeste database servers ook wel wat xml-query support.

Overigens zijn 90 byte (tinyint) velden efficiënter dan 90 bool (bit) velden. Vrijwel alle database engine zetten bool waardes om naar byte values waarbij vaak meerdere bit velden gecombineerd worden. Daarom kun je bij de meeste database engines ook geen indexen op deze velden plaatsen.

[Creepy]

era.zer schreef op donderdag 05 februari 2009 @ 12:01:
Een koppeltabel heb ik niet gedaan (ok mis misschien), het item moet alle opties hebben namelijk ofwel met de waarde uit ofwel met de waarde aan. Maar vooral, met koppeltabel heb je ook 90 rijen en die mag je ophalen en tonen op je form (ook veel werk).
trouwens is 90x één bit (12byte of zelfs als het een byte zou zijn 90 byte) belachelijk weinig. En met een aparte tabel heb je 90x 2 ints = 360 byte?

Maar wat ik vooral wil weten is hoe je die data (hoe het ook moge opgeslaan zijn) overbrengt op een gui, als je weet dat er een een boomstructuur in zit. (en een met bv 4-5 levels)

Die rijen haal je in 1 keer op m.b.v. een join en gaan. Dat gaat qua performance echt geen impact hebben

Hoe sla je nu informatie over een optie op? Ik neem aan dat een optie ook een naam/omschrijvig moet hebben op het formulier. Waar laat je die informatie nu?

Als je een extra tabel hebt waarin je de opties los opslaat kan je daar gelijk de boomstructuur ook in meenemen. Over hoe je een boomstructuur (of een menu structuur) moet opslaan zijn al heel wat topics voorbij gekomen dus daar is echt wel wat over te vinden

Daar dan dus een koppeltabel aavast die opties met gebruikers koppelt en gaan. Dan kan je in de toekomst bijven uitbreiden/aanpassen qua opties zonder je database model aan te hoeven passen.

[ Voor 5% gewijzigd door Creepy op 05-02-2009 13:05 ]

[Zoijar]

Wat voor boom structuur?

Je kan zoiets doen (misschien, als ik het goed begrijp?)

code:

Users:
user_id   etc.
-------

Options:
option_id   option_group_fk   option_name
---------

OptionGroups:
option_group_id   option_group_parent_fk   option_group_name
---------------

UserOptions:
user_id_fk   option_id_fk
-------------------------

en dan de nodige join queries... geen zin om uit te schrijven

[NMe]

era.zer schreef op donderdag 05 februari 2009 @ 11:46:
[...]

Maar normaliseren omdat het een boomstructuur is:
Stel je hebt de root en dan A B C D met daaronder allemaal opties. bedoel je dan een aparte tabel met de kinderen van telkens A, B, C, D ?Dan heb je 4 tabellen met elk 20 velden. dat verandert niet veel?

Je kan hier inderdaad vier tabellen gebruiker zoals Zoijar hierboven al zegt, maar niet op de manier die jij hier impliceert. A, B, C en D hoeven niet elk een eigen tabel te hebben.

[Saven]

misschien 1 veld en daar al die data in eern array stoppen die je serialized ?
lijkt mij de meest handige optie
dan alleen een foreach loop en zo kun je kijken welke checkboxen geset zjin enzo

[TeeDee]

Saven schreef op donderdag 05 februari 2009 @ 18:18:
misschien 1 veld en daar al die data in eern array stoppen die je serialized ?
lijkt mij de meest handige optie
dan alleen een foreach loop en zo kun je kijken welke checkboxen geset zjin enzo

Pardon? Ondanks dat je met serialisatie aan de slag gaat lijkt me dit absoluut niet de handigste optie.
* TeeDee ziet al problemen met incorrecte configs door een foutje in het serialisatie proces, handmatige edits die niet meer te doen zijn (mits je natuurlijk een handige editor hiervoor hebt) en weet ik veel wat nog meer.

[Saven]

waarom zou het serialisatie proces fout gaan? dat kan net zo goed overal fout gaan dus maakt niets uit imo.
en waarom is het niet handig volgens jou? ben ik wel benieuwd naar

[Cartman!]

Oa. omdat je niet meer op database niveau kunt selecteren natuurlijk. Ga eens snel jezelf inlezen op normalisatie voordat je nog meer van zulke slechte ideeen geeft...

[TeeDee]

- Wat als je een systeem moet gaan onderhouden/aansluiten wat geen serialisatie heeft.
- Stel; je slaat je een config/setting/weet ik veel wat op in de DB en besluit om vervolgens je class aan te passen. Is jouw serialisatie zo vergevingsgezind dat dat helemaal goed gaat?
- Hoe wil jij in je serialised veld gaan zoeken?
- Je DB gebruik je om relationele data in op te slaan. Doe dat dan ook en maak er geen rommel van.
- Maak een koppeltabel, een 'veldinfo' tabel en je bent klaar. Doe dan niet zo moeilijk door te denken dat het op deze manier wel handig is.

@RobIII hieronder: dat zeg ik, alleen vind ik zoiets vanzelfsprekend dat ik nog de mogelijke extra nadelen aan een serialisatie proces richting je DB.

[ Voor 11% gewijzigd door TeeDee op 05-02-2009 21:41 ]

[RobIII]

TeeDee schreef op donderdag 05 februari 2009 @ 20:03:
* TeeDee ziet al problemen met incorrecte configs door een foutje in het serialisatie proces, handmatige edits die niet meer te doen zijn (mits je natuurlijk een handige editor hiervoor hebt) en weet ik veel wat nog meer.

Dat is nog wel je minste probleem. Het druist gewoon in tegen elke normalisatieregel elk nut van een RDBMS .

[NMe]

RobIII schreef op donderdag 05 februari 2009 @ 21:33:
[...]

Dat is nog wel je minste probleem. Het druist gewoon in tegen elke normalisatieregel elk nut van een RDBMS .

Het is in een paar situaties best handig. Alleen in deze niet bepaald.