[MySQL] Type/Value tabel query voor meerdere "Types"

[Verwijderd]

Ik heb een tabel welke redelijk zal gaan groeien omdat het een tabel is waar ik een type en een value van het type ga opslaan. De enige referentie welke ik gebruik om een WHERE te doen zal een cid zijn:

cid	type	value
1	color	blue
1	color	green
1	shape	round
1	weigt	20
2	color	red
2	shape	square
3	weigt	6

Een simpele query kan je gewoon doen met een WHERE cid='1'.

Het probleem dat ik heb is dat als je op cid en type alles wil queryen dan moet je gaan groupen, opzich ook mogelijk.

Wat ik alleen altijd terug krijg is bij een WHERE cid='1' AND type='color' dat ik wel 2 rows terug krijg maar welke allebei de eerste regel geven dus

blue
blue

en geen:

blue green


Moet je hiervoor iets van een count(*) of een innerjoin gebruiken ?

Mijn uiteindelijke doel is om in een query alle types per groep in een aparte array te krijgen, dus een color array, een shape array, etc, met een WHERE cid='x'.

[ Voor 4% gewijzigd door Verwijderd op 16-12-2009 02:12 ]

[RobIII]

Zonder de hele query kunnen we hier natuurlijk weinig mee; maar ik vermoed dat je dit eens moet lezen: Hoe kom ik van dubbele resultaten in mijn query af? en vervolgens: Hoe werkt dat GROUP BY nu eigenlijk?

Verder is een "type/value" (zoals jij het noemt) tabel (eerder key/value dan) doorgaans een slecht idee; zeker als de values allemaal van verschillende types kunnen zijn. Zo zie ik in je values al ints, kleuren (enums of koppeltabel) en vormen (enums of koppeltabel) en als je kleuren en vormen als string zou gebruiken dan heb je nog steeds dat er verschillende types allemaal in een varchar gemikt worden. Dat levert, in the long run, alleen maar complexe, trage queries op en je gaat geheid méér dan eens jezelf vervloeken om deze opzet gekozen te hebben danwel een dode straat in fietsen om er achter te komen dat je jezelf zo diep in de nesten hebt gewerkt dat je er niet meer uit komt (in het beste geval: tenzij je ranzige hacks gaat toepassen, worst case: rewrite). En dit geldt dubbel-en-dwars als, zoals je zelf al in de eerste alinea aangeeft, de tabel flink gaat groeien. Behalve dat je voor veel zaken geen intrinsieke functies kunt gebruiken vanwege alle "types" die nu zijn "platgemept" naar varchars kun je nu ook geen fatsoenlijke indices gebruiken om maar eens wat te noemen.

Ook is me even niet duidelijk wat je nu precies wil hebben. Je zegt dat je

blue
blue

krijgt en geen

blue green ⁽¹⁾

bedoel je dan niet dat je geen

blue
green ⁽²⁾

krijgt? Want in het eerste geval ⁽¹⁾ kun je ook nog eens gaan kijken naar de (MySQL specifieke(!), en, door mij niet aanbevolen) Group_Concat functie.

Verwijderd schreef op woensdag 16 december 2009 @ 02:11:
Moet je hiervoor iets van een count(*) of een innerjoin gebruiken ?

Tot slot: even op gut-feel en uit de blote bol (ik heb het dus niet nagekeken), maar zie ik jou niet met regelmaat dit soort topics openen? Is een tutorial SQL misschien niet eens een idee? Dit is toch basic normaliseren en als je niet weet of je een count of inner join moet gebruiken (wat allebei totaal iets anders is, de een is een aggregate functie, de ander een type join) dan vraag ik me af of je wel weet welke gereedschappen je eigenlijk allemaal tot je beschikking hebt in SQL en of je die gereedschappen allemaal gebruikt zoals ze bedoeld zijn.

[ Voor 108% gewijzigd door RobIII op 16-12-2009 02:41 ]

[cariolive23]

Verwijderd schreef op woensdag 16 december 2009 @ 02:11:
Ik heb een tabel welke redelijk zal gaan groeien omdat het een tabel is waar ik een type en een value van het type ga opslaan.

Waarom ga je dan niet normaliseren? Dan sla je geen dubbele data op en zullen jouw tabellen veel minder groeien dan met jouw huidige model het geval zal zijn. Tevens lost dit vele andere problemen op, dit is een kleine 40 jaar geleden al beschreven door Codd.

[Verwijderd]

cariolive23 schreef op woensdag 16 december 2009 @ 09:12:
[...]

Waarom ga je dan niet normaliseren? Dan sla je geen dubbele data op en zullen jouw tabellen veel minder groeien dan met jouw huidige model het geval zal zijn. Tevens lost dit vele andere problemen op, dit is een kleine 40 jaar geleden al beschreven door Codd.

Opzich zal er geen dubbele data beschikbaar zijn, het lijkt alleen vreselijk veel op elkaar.

Goede voorbeeld zijn bijvoorbeeld mailadressen en domein aliassen. Het type is dan mailadres of alias, de value kan verschillen maar ze kunnen tot dezelfde cid behoren.

[Verwijderd]

Wat is opzich wel grappig vind is dat er wordt gesteld dat ik vaker van dit soort topics open zonder zelf het euvel te zien en met mijn inziens wat "modder" te smijten.

Anyway....

Ik krijg in mijn SQL client namelijk de melding dat er 2 rows geupdate worden als ik iets aanpas in color voor dezelfde cid.

Dit lijkt dus niet te kunnen en ik zal een autoincrement ID moeten toevoegen aan mijn tabel om de onderlinge rows toch te kunnen onderscheiden.

Dat blijkt dus de enige oplossing

[RobIII]

Verwijderd schreef op woensdag 16 december 2009 @ 11:51:
Ik krijg in mijn SQL client namelijk de melding dat er 2 rows geupdate worden als ik iets aanpas in color voor dezelfde cid.

Laat me raden: Je gebruikt "...where cid=x and type=color..." Nogal wiedes dan lijkt me he? Want beide rows voldoen aan die 2(!! hint!!) voorwaarden.

Verwijderd schreef op woensdag 16 december 2009 @ 11:51:
Dit lijkt dus niet te kunnen en ik zal een autoincrement ID moeten toevoegen aan mijn tabel om de onderlinge rows toch te kunnen onderscheiden.

Helemaal niet; een autoincrement hoeft helemaal niet dé oplossing te zijn. Je moet een record op een bepaalde manier kunnen identificeren als je dat ene record specifiek wil bijwerken. In jouw geval ben je niet specifiek genoeg (getuige het feit dat er twee rijen bijgewerkt worden). In feite heb je hier een tabel met een compound key over 3 velden. Of dat zinnig is is een tweede.

[ Voor 4% gewijzigd door RobIII op 16-12-2009 12:00 ]

[Cartman!]

offtopic:
Did you mean: weight

Overigens zou een query SELECT type, value FROM table WHERE cid = 1 AND type = "color" gewoon 2 rows terug moeten geven met blue en green. Wat je plaatste lijkt dus niet helemaal te kloppen dus, wat zit er nog meer in die query?

[jbdeiman]

Verwijderd schreef op woensdag 16 december 2009 @ 10:54:
[...]


Opzich zal er geen dubbele data beschikbaar zijn, het lijkt alleen vreselijk veel op elkaar.

Goede voorbeeld zijn bijvoorbeeld mailadressen en domein aliassen. Het type is dan mailadres of alias, de value kan verschillen maar ze kunnen tot dezelfde cid behoren.

Dat over geen dubbele data:

color zie ik zo al 4 keer staan, dat is een type. Handiger is om een tabel te hebben met alle verschillende typen. Dit valt namelijk ook onder dubbele data. Dat is niet alleen complete rijen die hetzelfde zijn, maar dus ook waarden in een kolom.
Hetzelfde geld voor de kleur, of wou je er ook nog voor proberen te zorgen dat verschillende cid's nooit beiden de kleur rood kunnen hebben?
Alleen de complete combinatie (rij) in je table zal je waarschijnlijk nooit dubbel hebben, maar je kan best dit hebben:
1 | kleur | rood
2 | kleur | rood
3 | kleur | rood
Dit is veel meer data en je slaat dan wel degelijk data dubbel op.

Niet in alle gevallen moet je dit op deze manier oplossen, omdat (bijvoorbeeld) voor namen van personen ook verschillende schrijfwijzen e.d. mogelijk zijn. Die sla je ook niet op in een losse tabel.

In dit soort situaties als waarin jij nu zit te werken is een koppeltabel een veel snellere oplossing om mee te werken en ook om te onderhouden.
Ook het zoeken en koppelen van gegevens met een simpele select query is dan niet zo'n probleem.

[Verwijderd]

Cartman! schreef op woensdag 16 december 2009 @ 12:00:

offtopic:
Did you mean: weight

Yep, was een test dus maakte me niet echt uit en scheelde een letter typen

[Cartman!]

Misschien kun je ook m'n andere opmerking meenemen, en natuurlijk die van jbdeiman.

[japaveh]

@Cartman!: Maar daar los je het probleem wat RobIII schetst toch ook niet direct op? Je blijft dan met het probleem zitten dat de waarde (value) gewoon als varchar moet worden gekozen om alle verschillende waardes op te slaan terwijl je dat juist niet wil. Ik zou dat liever opsplitsen naar een string voor een random waarde, naar TIME voor een tijdwaarde en naar een INT voor een getal etc.

Ik moet zelf zeggen dat ik het probleem achter Key-Value pairs al wel begrijp maar het is mij ook nog niet gelukt om een goede oplossing te vinden zonder te grijpen naar andere Dbase oplossingen als Bigtable.

[Cartman!]

Dat los je daar niet mee op nee maar de kans is er dat het ook enkel gebruikt wordt als string en dan is het in (een klein aantal situaties) wel te verantwoorden imo.

[TeeDee]

* TeeDee ziet even zo gauw het volgende:

Een tabel Color, Shape, Weight en een koppeltabel. Duidelijker kan imo niet. Wil je een andere property aan je entiteit toevoegen ontkom je er niet aan om een edit op je Datamodel te doen*.

Je zou eventueel ook de Enums (Color, Shape en Weight) buiten je model kunnen houden en die in je logic kunnen plaatsen*. Er is imo geen makkelijke oplossing om dit te verwezenlijken. Tenzij je een DB in een DB gaat bouwen, maar dat is simpelweg niet handig, want je ziet nu al de problemen.

Als je ook naar jouw vraag kijkt: Cid 1 heeft meerdere Color property's tw: blue en green. Het tonen hiervan doe je in je view. Niet vanuit je DB. Alles wat je DB voor je kan doen is mooi meegenomen, maar overdrijf het niet.

* Een aanpassing op je entiteit (bijv. een property 'Manufacturer') zorgt of in je DB of in je logic voor een aanpassing. Daar ontkom je met dit soort dingen nu eenmaal niet aan.

[ Voor 7% gewijzigd door TeeDee op 16-12-2009 22:32 ]

[Verwijderd]

TeeDee schreef op woensdag 16 december 2009 @ 22:25:
* TeeDee ziet even zo gauw het volgende:

* Een aanpassing op je entiteit (bijv. een property 'Manufacturer') zorgt of in je DB of in je logic voor een aanpassing. Daar ontkom je met dit soort dingen nu eenmaal niet aan.

Kijk dit is nuttige informatie welke je feedback geeft

Dank !

[TeeDee]

Verwijderd schreef op donderdag 17 december 2009 @ 13:05:
[...]


Kijk dit is nuttige informatie welke je feedback geeft

Dank !

Voor hetzelfde geld heb ik complete onzin zitten verkondigen. Maar goed, RobIII heeft in de eerste reply al kernwoorden (enums, koppeltabellen) aangegeven.

[Verwijderd]

Ik ben voor apacke bijvoorbeeld een uit gaan zoeken hoe je kunt normaliseren.

Je kunt opzich een basic vhost configfile in een tabel onderbrengen, dit lijkt me ook logisch.

Het probleem is dat je toch aparte tabellen voor redirect, aliassen, etc nodig hebt. Aangezien dit nogal wat tabellen kunnen worden moet je een keus maken.

Je kunt dan alle opties netjes in een tabel knallen op een manier welke altijd makkelijk over te zetten in naar zijn eigen tabel in plaats van overal "nutteloze" tabellen voor te maken.

Voor redirects, aliassen snap ik het bijvoorbeeld wel deze worden veel gebruikt, maar niet voor alle opties welke je wil kunnen zetten. een KeyColumn is dan handiger lijkt me.

[RobIII]

Verwijderd schreef op zondag 20 december 2009 @ 15:55:
Ik ben voor apacke bijvoorbeeld een uit gaan zoeken hoe je kunt normaliseren.

Je kunt opzich een basic vhost configfile in een tabel onderbrengen, dit lijkt me ook logisch.

Het probleem is dat je toch aparte tabellen voor redirect, aliassen, etc nodig hebt. Aangezien dit nogal wat tabellen kunnen worden moet je een keus maken.

WTH heeft normaliseren met Apache, vhosts, redirects en aliassen van doen

Verwijderd schreef op zondag 20 december 2009 @ 15:55:
Je kunt dan alle opties netjes in een tabel knallen op een manier welke altijd makkelijk over te zetten in naar zijn eigen tabel in plaats van overal "nutteloze" tabellen voor te maken.

Define "nutteloze" tabellen

Verwijderd schreef op zondag 20 december 2009 @ 15:55:
Voor redirects, aliassen snap ik het bijvoorbeeld wel deze worden veel gebruikt, maar niet voor alle opties welke je wil kunnen zetten. een KeyColumn is dan handiger lijkt me.

Knock yourself out. Maar zeg niet dat we je niet gewaarschuwd hebben

[Creepy]

Verwijderd schreef op zondag 20 december 2009 @ 15:55:
*verhaal*

Sorry, maar het feit dat je zegt dat je een basic vhost in 1 tabel kunt zetten geeft aan dat je het normaliseren nog niet helemaal onder de knie hebt.

[Verwijderd]

RobIII schreef op zondag 20 december 2009 @ 17:06:
Knock yourself out. Maar zeg niet dat we je niet gewaarschuwd hebben

Je bent aan zelf aan het trollen. DONT.

[ Voor 55% gewijzigd door Creepy op 20-12-2009 20:24 ]

[Verwijderd]

Creepy schreef op zondag 20 december 2009 @ 17:28:
[...]

Sorry, maar het feit dat je zegt dat je een basic vhost in 1 tabel kunt zetten geeft aan dat je het normaliseren nog niet helemaal onder de knie hebt.

Waar bazeer je dat op dan ? Jij gaat dus per setting welke je kan doen een tabel aanmaken

[MueR]

Sorry dit ik dit even kwijt moet, maar waarom open je hier eigenlijk nog topics? Je slaat constant advies van doorgewinterde programmeurs in de wind, blijft tot in het oneindige je eigen standpunten verdedigen, zelfs als het hele topic tegen je zegt dat het een slechte opzet/slecht idee/onwerkbare oplossing is. Misschien moet je eens open staan voor ideeen van anderen?

Als ik zo door je posthistory hier en in SEA kijk, heb je een probleem met normaliseren van data. Maar elke keer dat het ter sprake wordt gebracht door een user, reageer je op een manier die mij doet vermoedden dat je denkt de wijsheid in pacht te hebben. Kritiek die je krijgt doe je af als "trollen" of je reageert botweg dat de ander "zelf moet weten of hij op die manier op zn bek wil gaan". Dat is natuurlijk geen manier van werken. Jij vraagt om input, anderen geven die, dan moet je niet lomp terugstampen omdat het niet voldoet aan jouw eigen denkwijze. Als je komt om jaknikkerij te lezen ben je hier echt verkeerd, daarvoor zitten er teveel echte programmeurs hier.

offtopic:
En leer de edit knop nou eens gebruiken. Dat dubbelposten is irritant

On topic:
Meerdere tabellen wil je wel gaan gebruiken. Je hebt een attribute color, niet een attribute met type color. Je gaat met meerdere tabellen veel meer controle hebben over de data in die tabellen, om nog maar te zwijgen van de voordelen mocht je dit systeem ooit willen uitbreiden.

Verwijderd schreef op zondag 20 december 2009 @ 17:35:
Waar bazeer je dat op dan ? Jij gaat dus per setting welke je kan doen een tabel aanmaken

Om een voorbeeld te geven. Een vhost heeft properties meer dan alleen een naam. Behalve de simpele one-liner settings (listen IP/port, document root, server admin enzo), zijn er voor die document root ook nog diverse instellingen mogelijk. Wil je echt voor elke mogelijk setting een apart veld in je tabel maken? Of ga je gewoon een groot TEXT veld maken waar je willekeurige configuraties in kwijt kan? Zal prettig werken. Totaal geen validatie op mogelijk. Fijn als een prutser in het <LIMIT GET,POST> stuk een deny from all zet. Weet jij niet. Of zelfs een compleet invalide input geeft waardoor je vhost stuk is.

[curry684]

Verwijderd schreef op woensdag 16 december 2009 @ 02:11:
Ik heb een tabel welke redelijk zal gaan groeien omdat het een tabel is waar ik een type en een value van het type ga opslaan.

Oeh een database in een database, oftewel een metadatabase

Tip als je geen pro bent: niet doen. Zoals je aan dit topic al ziet levert het je meer koppijn op dan wat anders, en dan overzie je zonder de benodigde ervaring ook geen enkele consequentie op het gebied van performance, extensibility en doorzoekbaarheid.

Verwijderd schreef op zondag 20 december 2009 @ 17:35:
[...]

Waar bazeer je dat op dan ? Jij gaat dus per setting welke je kan doen een tabel aanmaken

Nee alleen waar dat nodig is. Dat is normaliseren, attributen naar een eigen tabel afsplitsen die dat modeltechnisch voor hun relaties behoeven. Een vhost in 1 enkele tabel proppen gaat je niet lukken, al is het maar om bijv. de one-to-many relatie met aliassen. Evenmin duwt creepsel je naar het andere uiterste van 'alles een eigen tabel', zo is de ServerName uniek voor een specifieke vhost en dus een logisch attribuut van de table VirtualHost.

Je kunt allebei de uitersten leuk benoemen maar ontbeert de ervaring om te zien of kunnen deduceren waar in het midden 'de waarheid' ligt. Niks mis mee, meeste ICT'ers zijn niet enorm bedreven in architectuur en het ontwerpen van grote databases... maar als je dan om hulp komt vragen hier zou het je iig sieren als je op een fatsoenlijke manier naar de pro's zou luisteren ipv een grote mond teruggeven. Jij komt om hulp vragen met je topic, wees blij dat je het krijgt.

[Creepy]

MueR en curry684 maaien mooie het gras voor mijn voeten weg
Echt: als je denkt het normaliseren goed onder de knie te hebben dan is dit topic inderdaad overbodig. Het lijkt er echter op dat dat (nog) niet het geval is. Dat is niet erg, we hebben het allemaal moeten leren. Waarbij dit onderwerp voor sommige figuren een eitje is, is het voor anderen heel erg lastig.

Om dan maar de adviezen hier te (gaan?) negeren en sommigen hier maar gewoon trolls te noemen gaat te ver. Erger nog: je bent gewoon zelf aan het trollen. Je denkt zelf dingen te weten maar vraagt wel om bevestiging elke keer hier. En dan zulke reacties als je zaken hoort die je eigenlijk niet aan staan? Sorry, maar dan houdt het op. Als je hier advies wilt krijgen is dat prima, maar ga dan wel op een normale manier met dat advies om.

[ Voor 10% gewijzigd door Creepy op 20-12-2009 20:25 ]