[SQL] grote database of veel rekenkracht

[execute|IA]

Ik zit met het volgende probleem in mijn maag en weet niet wat ik nu het beste kan doen. Ook heb ik met de zoekmachine niets kunnen vinden dus bij deze mijn vraag.

Ik heb een database met een aantal persoonsgegevens (ongeveer 20 velden), daarnaast kunnen er ongeveer 80 opties per persoon worden aan en of uitgezet.

Ik kan dan het volgende doen: 1 gigantische tabel maken met 100 velden waarbij ik in 80 velden een 1 of een nul zet indien van toepassing of niet.

of

Ik maak een tabel persoonsgegevens (20 velden) en een tabel mogelijkheden (80 records, 2 velden(id, beschrijving)) en crieer daarnaast een tabel welke een persoon aan de mogelijkheden koppelt indien van toepassing (persoon_id, mogelijkheden_id), (een 1 dus, nullen worden niet geschreven).

Mijn vraag is nu wat kan ik het beste doen? 1 grote tabel maken of 3 kleinere. De laatste manier kost denk ik veel prestatievermogen maar bij de eerste optie vind ik de tabel wel erg groot worden.

Ben benieuwd naar jullie reacties. Want wat is nu de beste oplossing?

[Skaah]

Het maken van een tweede tabel lijkt mij zinloos; er is immers spraken van een 1:1 relatie. Een grote tabel is niet eng, alleen groot.

[Database freak]

Als de optie weinig gebruikt worden kan je het beste meerdere tabellen maken voordeel; je kan nieuwe opties toevoegen zonder de structuur van je database te wijzigen. Als het allen ja/nee opties zijn is elke optie in princiepe met een bit op te slaan. Met één 80/8 = 10 bytes veld kan je zo 80 opties opslaan. 10 bytes per record is niet veel cq. zeer weinig. Je moet enkel dan een filer maken dat als jij optie 54 wil weten je het 54e bit uit het 10-byte veld haald. Dit door de lange / big integer of string die je in dit veld op slaat naar hexa decimaal of binair te vertalen.

Suc6.

[Brothar]

hangt er van af.
Persoonlijk vind ik de 1:N Persoon<==>Ja_Opties een mooie. Maar dit geeft bij elke persoon een zoekaktie in die tabel tot maximaal 80 records.

Waar ligt het zwaartepunt van je applicatie? Bij de persoonsgegevens ? Dan is de meer-tabellen optie wellicht de foede weg.
Maar ligt het zwaartepunt bij de optie-instellingen, dan lijkt het mij verstandiger slechts met 1 tabel van 100 velden te werken: je ziet maximaal 20 records op 1 scherm schat ik, en zo lang zal het niet duren voor dat is ingelezen.
Verder zijn queries dan volgens mij wat makkelijker.

[faabman]

ik zou 3 tabellen aanmaken

tbl_personeel met 1 PK

tbl_koppel_personeel_optie met 2 FK's

tbl_opties met 1 PK

zodoende kun je op lange termijn nooit in de problemen komen...

de complexiteit en lengte van de queries valt imho wel mee en bovedien hebben ze daarvoor volgens mij applicaties als enterprise manager uitgevonden ...

[bartvb]

Even voor de beeldvorming: Wat is 'groot'?

[chem]

Een bitfield (set, enum, (big)int, hoe het dan ook heet) lijkt me de beste oplossing.

[Janoz]

Alhoewel het in de meeste gevallen makkelijker is om gewoon voor de 'meer ruimte' optie te gaan (HD ruimte is veel meer schaalbaarder dan rekenkracht. Met nauwelijks downtime is de HD ruimte te vertigvoudigen. Dat lukt je niet met rekenkracht) ga ik in dit geval toch mee met het koppeltabel voorstel. Een N:M relatie tussen personen en opties. Voordelen zijn legio. Makkelijk opties toe te voegen (zolang ze default op nee moeten staan !) simpel op te vragen welke mensen een bepaalde optie op ja hebben en welke opties bepaalde mensen op ja hebben.

[justmental]

Ligt er ook een beetje aan hoe je de gegevens gaat gebruiken.
Als de verschillende 'opties' aan een persoon in je applicatie hetzelfde gebruikt worden dan is de koppeltabel methode handig.
Worden deze 'opties' niet op dezelfde manier behandeld dan is de kolommen optie handiger.
Uit performance oogpunt is de eerste methode beter als je bij veel functies veel van de opties uit moet lezen. De tweede is over het algemeen trager, maar wordt wel beter als je maar 1 of 2 opties in je functie uitleest.

[Verwijderd]

80 opties?

Waarom geen int(80) veld in je (hoofd)tabel?
En die vervolgens vullen met, afhankelijk van de keuzes, 1'en en 0'en.

Dus:
01010101001001101011010011110010110

[ /einde flauw voorbeeld ]

Ik neem namelijk aan dat je niet dagelijks de keuzes moet veranderen dus een optie als de mijne is zeker geen slechte lijkt me!
Succes.

edit:

Ik weet niet wat je er mee wil en moet bereiken, als er op gezocht moet worden zul je toch een andere structuur moeten creeëren.
Als er niet op gezocht moet worden is het een prima oplossing, maar daarentegen lijkt het er op dat het een dating-site cq site met verschillende persoongegevens oid wordt, en dan zal er gezocht moeten worden!

[ Voor 37% gewijzigd door Verwijderd op 04-02-2004 13:15 ]

[drm]

ivy:
80 opties?

Waarom geen int(80) veld in je (hoofd)tabel?
En die vervolgens vullen met, afhankelijk van de keuzes, 1'en en 0'en.

Dus:
01010101001001101011010011110010110

Alsjeblieft zeg, dat meen je toch niet? Kan je zelf niet bedenken wat voor enorme onderhoudbaarheids- en schaalbaarheidsproblemen je hiermee gaat krijgen, nog afgezien van de enorme inefficientie en het niet of amper kunnen querien op dat soort gegevens...

---

Het is uiteindelijk heel simpel: je moet gewoon normaliseren. Je hebt personen en opties. 1 Optie kan bij meerdere mensen voorkomen en een mens kan meerdere opties hebben, hence je hebt een n:m relatie, en dat doe je gewoon met een koppeltabel. Ik kan me geen voordelen bedenken van andere manieren boven deze, juist omdat een taal als SQL ook op dat soort gegevens is ingesteld. Onderhoudbaarheid en schaalbaarheid is dan ook optimaal; het verwijderen / toevoegen van opties wordt eenvoudig en het aangeven van eigenschappen van opties zelf (velden in de opties tabel) wordt ook makkelijk (beschrijving, naam, rechten ...?)

[lier]

drm schreef op 04 februari 2004 @ 13:36:
[...]
Alsjeblieft zeg, dat meen je toch niet? Kan je zelf niet bedenken wat voor enorme onderhoudbaarheids- en schaalbaarheidsproblemen je hiermee gaat krijgen, nog afgezien van de enorme inefficientie en het niet of amper kunnen querien op dat soort gegevens...

---

Het is uiteindelijk heel simpel: je moet gewoon normaliseren. Je hebt personen en opties. 1 Optie kan bij meerdere mensen voorkomen en een mens kan meerdere opties hebben, hence je hebt een n:m relatie, en dat doe je gewoon met een koppeltabel. Ik kan me geen voordelen bedenken van andere manieren boven deze, juist omdat een taal als SQL ook op dat soort gegevens is ingesteld. Onderhoudbaarheid en schaalbaarheid is dan ook optimaal; het verwijderen / toevoegen van opties wordt eenvoudig en het aangeven van eigenschappen van opties zelf (velden in de opties tabel) wordt ook makkelijk (beschrijving, naam, rechten ...?)

Met het eerste deel ben ik het helemaal eens.
Een int met lengte 80 (of meer bij meer opties) gebruiken voor zoiets is ronduit belachelijk.

De vraag van een of meer tabellen is niet zo te beantwoorden. Norrmaliseren van gegevens is goed (ook al zou je uit performanceredenen kunnen kiezen om niet "volledig" te normaliseren), maar volgens mij is in jouw verhaal sprake van een 1 op 1 relatie. De verschillende opties worden allemaal gezet (of niet ?). Daarom dan een tabel...

[execute|IA]

lier schreef op 04 februari 2004 @ 13:53:
[...]


Met het eerste deel ben ik het helemaal eens.
Een int met lengte 80 (of meer bij meer opties) gebruiken voor zoiets is ronduit belachelijk.

De vraag van een of meer tabellen is niet zo te beantwoorden. Norrmaliseren van gegevens is goed (ook al zou je uit performanceredenen kunnen kiezen om niet "volledig" te normaliseren), maar volgens mij is in jouw verhaal sprake van een 1 op 1 relatie. De verschillende opties worden allemaal gezet (of niet ?). Daarom dan een tabel...

Ik heb het al geprobeerd met 1 tabel maar dat bleek toch niet echt efficient werken. Ook als ik gegevens wil toevoegen aan een optie kan ik beter met meerdere tabeleln werken. Het is uiteindelijk overzichtelijker.

Maar toch bedankt voor jullie reacties

[Grijze Vos]

'Vroeger' was het heel normaal om het op de 0/1 manier te doen zoals hier omschreven wordt hoor. Denk eraan dat elk 'gewoon' getal binair te schrijven is. Met 10 opties, kun je met alle getallen tussen de 0 en de 1023 alle opties dekken.

1001010101 = 597

Stamt een beetje uit de tijd van het assembly-programmeren ^^.

Een optie waar je wel aan kunt denken, is wat ik nu heb voor mijn users. Geef elke user een FK naar de 'opties' tabel. vervolgens maak je de opties tabel, met een PK (waarnaar via de user's FK naar wordt verwezen), en de 80 opties. Uitbreiding van de opties geeft een modificatie in deze tabel, zou in principe niet zo'n ramp moeten zijn. Toevoegen van deze optie doe je met een default setting van 0 of 1 zo regelen.

Als elke user totaal verschillende opties draait is dit niet zo'n geweldig alternatief, maar als verschillende groepen users dezelfde opties krijgen toegewezen (als een soort user-level implementatie), dan is dit wel handig. (Het was me niet helemaal duidelijk of het ging om zelf in te stellen opties door de user, of door de 'admin'. In ieder geval een nuttige toevoeging voor mensen die de search gebruiken, denk ik.)

[drm]

Grijze Vos:
'Vroeger' was het heel normaal om het op de 0/1 manier te doen zoals hier omschreven wordt hoor. Denk eraan dat elk 'gewoon' getal binair te schrijven is. Met 10 opties, kun je met alle getallen tussen de 0 en de 1023 alle opties dekken.

Dat is heus niet nieuw voor mij, maar is allesbehalve handig in een database. Het heeft zo al een aantal verschrikkelijke nadelen:
• Er kan niet op geindexeerd worden. Je moet tenslotte bitwise querien.
• Je kunt heel lastig joinen (wat wordt de on clause?) en dus slecht in 1 keer van 1 gebruiker alle opties te pakken krijgen.
• Je maakt heel snel fouten.
• De uitbreidbaarheid is heel slecht, omdat bij elke optie die er later bijkomt, de veldgrootte 1 bit meer wordt, terwijl dat met een gewone primary key gewoon weer een extra ophoginkje zit. (Het voorbeeld dat je zelf noemt geeft het al aan: 10 mogelijkeden heeft een veld nodig van minimaal 10 bits, alle waarden voor x: 0 ≤ x ≤ 1023. Bij een gewone integer PK zou dat echter gewoon 1023 mogelijkheden zijn.)

Alles bij elkaar is het gewoon helemaal niet voor SQL geschikt.

Nog daar gelaten dat hier werd geopperd een int(80) veld te nemen wat waarschijnlijk lastig wordt qua grootte, maar er vooral een behoorlijk verschil zit tussen 10⁸⁰ en 2⁸⁰.

[Glimi]

Grijze Vos schreef op 06 februari 2004 @ 03:08:
'Vroeger' was het heel normaal om het op de 0/1 manier te doen zoals hier omschreven wordt hoor. Denk eraan dat elk 'gewoon' getal binair te schrijven is. Met 10 opties, kun je met alle getallen tussen de 0 en de 1023 alle opties dekken.

1001010101 = 597

Bitfield coding is idd heel normaal, tegenwoordig gebruiken we nog steeds veelvuldig de methode, bijvoorbeeld bij constantes om zo optellingen te kunnen krijgen, welke een uniek getal geven.
Echter het blijft ronduit belachelijk en nooit wijd gebruikt binnen SQL, omdat SQL gebaseerd is op relationele databases, welke zich baseren op atomiciteit van de gegevens.
Zo'n bitfield is dus alles behalve dat.