[sql] query probleempje

[Verwijderd]

ik heb een probleem met een query op te bouwen...

ik heb 3 tabellen

code:

logindata       gebruikersgegevens     auto_gegevens.
uid| username     uid| naam       uid| type
--------------   ----------------    --------------
1  | ShockWave   1  | John Plusje    1  | Kadett D
5  | test       5  | test         5  | test

nu wil ik graag dat het volgende uit de quey komt:

code:

UID | naam    | type
1   | John Plusje | kadett d
5   | test    | test

dus ik heb de volgende query bedacht:
SELECT logindata.uid, naam, type FROM logindata, gebruikersgegevens, auto_gegevens WHERE 1

code:

maar dan komt dit eruit:
1   John Plusjé   kadett d 
5   John Plusjé   kadett d  
1   test        kadett d
5   test        kadett d
1   John Plusjé   test  
5   John Plusjé   test  
1   test        test  
5   test        test

iemand enig idee? ik zit een beetje vast

[raptorix]

Als het allemaal een-op-een relaties zijn waarom zet je het dan in 3 tabellen?

[Janoz]

Je moet in je query wel duidelijk aangeven op wat voor manier je de verschillende tabellen wilt joinen. Anders pakt de DB gewoon alle mogenlijkheden bij elkaar (zoals je ziet)

PS:raptorix maakte een nog veel betere opmerking over je db structuur luister naar hem!!

[Verwijderd]

ik heb nu:

SELECT logindata.uid, naam, type FROM logindata, gebruikersgegevens, auto_gegevens WHERE logindata.uid = gebruikersgegevens.uid AND logindata.uid = auto_gegevens.uid

deze doet wel wat ik wil maar kan het niet simpeler?

ik doe dit trouwens omdat ik in die tabellen nog meer gegevens heb staan en dit de enige pagina is waar ik uit 3 tabellen gegevens nodig heb... op de rest van de pagina's is het mooi uit 1 tabel te halen. tevens is nu de data overzichtelijk in de database opgeslagen.

[SWINX]

nee, je zult de relaties tussen die drie tabellen aan moeten geven, dus het word vanzelf een iets langere query

[Verwijderd]

SELECT logindata.uid, naam, type FROM logindata, gebruikersgegevens, auto_gegevens WHERE 1

maak daar 's van

SELECT logindata.uid, naam, type FROM logindata, gebruikersgegevens, auto_gegevens where logindata.uid = gebruikersgegevens.uid AND auto_gegevens.uid = logindata.uid

tevens nog wat opmerkingen,
zoals al gezegd werd, is dit een 1-op-1 relatie, waarom douw je dit niet in 1 tabel?
ten tweede, je noemt de ene tabel gebruikersgegevens en de andere auto_gegevens (met underscore), beetje inconsistent vind je niet?

edit:
damn, net te laat

[Janoz]

Op donderdag 21 maart 2002 12:05 schreef ShockWave het volgende:
ik heb nu:

SELECT logindata.uid, naam, type FROM logindata, gebruikersgegevens, auto_gegevens WHERE logindata.uid = gebruikersgegevens.uid AND logindata.uid = auto_gegevens.uid

deze doet wel wat ik wil maar kan het niet simpeler?

ik doe dit trouwens omdat ik in die tabellen nog meer gegevens heb staan en dit de enige pagina is waar ik uit 3 tabellen gegevens nodig heb... op de rest van de pagina's is het mooi uit 1 tabel te halen. tevens is nu de data overzichtelijk in de database opgeslagen.

Het is maar wat je overzichtelijk noemt..PErsoonlijk vind ik het een stuk overzichtelijker waneer die gegevens mooi in 1 tabel bij elkaar staan (Er zijn meer mensen die daar zo over denken trouwens).. Dat je op andere pagina's alleen een gedeelte van die gegevens nodig hebt is IMHO geen reden om ze maar op te splitten. Je kunt toch gewoon de benodigde velden tussen je select en where zetten? Heb je geen last van de andere velden in het record..

[Verwijderd]

ik zou het in een tabel kunnen duwen alleen heb ik dan een tabel van 50 kolommen breed en 100 rijen... ik vind dat een beetje onoverzichtelijk...

[Janoz]

Op donderdag 21 maart 2002 12:09 schreef ShockWave het volgende:
ik zou het in een tabel kunnen duwen alleen heb ik dan een tabel van 50 kolommen breed en 100 rijen... ik vind dat een beetje onoverzichtelijk...

Is goed joh, blijf maar eigenwijs ..

[Verwijderd]

ik wil helemaal niet eigenwijs zijn.... maar -> persoonlijk <- vind ik dit overzichtelijker wat is daar mis mee....

[Verwijderd]

ik ben het trouwens wel met je eens dat logindata inderdaad beter in een tabel kan staan samen met de gebruikersgegevens... dan heb je inderdaad 1 tabel minder en het is dan inderdaad overzichtelijker...

[Verwijderd]

Op donderdag 21 maart 2002 12:05 schreef ShockWave het volgende:
ik heb nu:

SELECT logindata.uid, naam, type FROM logindata, gebruikersgegevens, auto_gegevens WHERE logindata.uid = gebruikersgegevens.uid AND logindata.uid = auto_gegevens.uid

deze doet wel wat ik wil maar kan het niet simpeler?

nee , tenzij je het in 1 tabel ramt.

[Crazy D]

Op donderdag 21 maart 2002 12:08 schreef Janoz het volgende:
Het is maar wat je overzichtelijk noemt..PErsoonlijk vind ik het een stuk overzichtelijker waneer die gegevens mooi in 1 tabel bij elkaar staan (Er zijn meer mensen die daar zo over denken trouwens)..

Een loginnaam en een normale naam lijken me typisch iets wat je bij elkaar wilt zetten. Tjah, een auto... wat als je nou 2 auto's hebt? In een aparte tabel kan dat zonder dat je de overige gegevens dubbel in je db krijgt. Maar uhmm does normalizeren ring a bell?

[Janoz]

Met databases wordt al jaren gewerkt en er is dus ok veel onderzoek naar gedaan. Hieruit zijn bepaalde richtlijnen ontstaan mbt de meest efficiente structuur voor gegevens in databases. 1 daarvan is dat in de meeste gevallen tabellen met een 1 op 1 relatie samengevoegd horen te worden. Als jij het beter denkt te weten dan die 40 jaar ervaring van de hele DB-gemeenschap dan noem ik je eigenwijs ...

[Verwijderd]

crazy_d zoals jij het zegt klopt het inderdaad.... logindata en gebruikersgegevens kan ik beter samenvoegen en de autogegevens apart omdat (en daarom heb ik het gedaan) ik zelf ook 2 auto's heb en die dus met mijn uid worden opgeslagen in de auto tabel...

normaliseren ken ik wel...

[Verwijderd]

janoz je hebt gelijk..... ik heb me inderdaad al bedacht logindata en gebruikersgegevens damen te voegen (1 op 1 relatie) en auto apart te houden...

Ik ben nu wel een stukje wijzer geworden (gaat snel hoor bij mij):)

[Verwijderd]

Je kant het wel overzichtelijker vinden door met meerdere tabellen te werken maar het kost wel iets meer ruimt En dus is je query langer bezig om info op te zoeken, of je moet gaan indexeren maar volgens mij gaat dat nog niet echt lukken...btw, hoe groot worden je tabellen eigenlijk?

[Verwijderd]

in iedere tabel komen nu 100 users dus dat is nog weinig en de grootste tabel bevat nu 25 kolomnmen dus het valt wel mee....

[Verwijderd]

Oww, das inderdaad nog goed te overzien. Met de ruimte hoef je dan ook niet zoveel rekening te houden maar vind je het geen uitdaging om het systeem te optimaliseren?

[Rataplan]

Janoz, zou je zo vriendelijk willen zijn even Crazy_D's post te lezen? En dan je eigen post even te relativeren?

Voor het programmeren van een beetje multitierapp heb je bijvoorbeeld vaak meer logins per user. Hoe je dat wil implementeren verschilt per geval, maar - nog even afgezien van het feit dat Shockwave zelf nergens de 1-1 relatie aangeeft - het is uit bovenstaande gegevens niet eenduidig af te leiden hoe user/login-data genormaliseerd moet worden. Uit de vraagstelling weer wel, maar dat is een heeeel ander verhaal Die auto's, tja, als je die in dezelfde tabel zet ben je, zoals Crazy D aangeeft, natuurlijk echt suf bezig. En dan nog "You're not expected to understand this" in je sig zetten, niet te zuinig zeg. Als mensen je niet hoeven te begrijpen heb je hier de verkeerde baan.

Kort en goed: zeker van een moderator verwachten we hier natuurlijk niet dat 'ie gaat roepen "we zijn al 40 jaar bezig dus we hebben gelijk dus jij bent eigenwijs". Weer afgezien van het feit dat jij niet namens mij spreekt, en dus(!) niet namens de "hele DB-gemeenschap"

Shockwave verwijs ik trouwens gewoon naar mysql.com. Zoek daar ook eens op "DISTINCT SYNTAX"! Valt ongeloveloos veel te leren, daar.

[Verwijderd]

ik ben nu hard bezig met mijn database te normaliseren en eerst fatsoenlijke tabellen op te bouwen voordat ik verder ga met programmeren....

allemaal bedankt voor de hulp en ik kan nu voorlopig weer vooruit.

[Janoz]

Op donderdag 21 maart 2002 14:05 schreef Rat het volgende:
Janoz, zou je zo vriendelijk willen zijn even Crazy_D's post te lezen? En dan je eigen post even te relativeren?

Als ik zeg dat er een smilie bij staat en ik het niet kwaad bedoel vind je dat zeker zwak

Voor het programmeren van een beetje multitierapp heb je bijvoorbeeld vaak meer logins per user. Hoe je dat wil implementeren verschilt per geval, maar - nog even afgezien van het feit dat Shockwave zelf nergens de 1-1 relatie aangeeft - het is uit bovenstaande gegevens niet eenduidig af te leiden hoe user/login-data genormaliseerd moet worden. Uit de vraagstelling weer wel, maar dat is een heeeel ander verhaal Die auto's, tja, als je die in dezelfde tabel zet ben je, zoals Crazy D aangeeft, natuurlijk echt suf bezig.

Ik geef duidelijk aan dat dit over 1 op 1 relaties gaat. Mijn opmerking gaat over het feit dat de topicstarter 1 op 1 relaties liever toch scheidt omdat hij denkt dat dit overzichtelijker is.Niet elke reactie in een thread is een reactie op de startpost.

En dan nog "You're not expected to understand this" in je sig zetten, niet te zuinig zeg. Als mensen je niet hoeven te begrijpen heb je hier de verkeerde baan.

Dat is een quote die ik tegenkwam toen ik bezig was voor een practicum OS. Dit stond in het commentaar van 1 van de bestanden, en omdat ik dat wel een leuke uitspraak vond heb ik het in mijn sig gezet. Als je problemen met mijn sig hebt, kun je dit melden in SU.

Kort en goed: zeker van een moderator verwachten we hier natuurlijk niet dat 'ie gaat roepen "we zijn al 40 jaar bezig dus we hebben gelijk dus jij bent eigenwijs". Weer afgezien van het feit dat jij niet namens mij spreekt, en dus(!) niet namens de "hele DB-gemeenschap"

Dat is om aan te geven waarom ik het wat eigenwijs van hem vond. Ik bedoelde die opmerking niet kleinerend oid. Ik wilde hiermee aangeven dat over dit probleem al heel lang nagedacht is. Maar als jij niet overtuigd bent van het feit dat je 1 op 1 relaties gewoon in dezelfde tabel zou moeten zetten, dan spreek ik idd niet voor jou...

Shockwave verwijs ik trouwens gewoon naar mysql.com. Zoek daar ook eens op "DISTINCT SYNTAX"! Valt ongeloveloos veel te leren, daar.

Distinct bied in dit geval niet de oplossing waar de topicstarter naar zoekt.

[Crazy D]

Op donderdag 21 maart 2002 12:17 schreef Janoz het volgende:
Met databases wordt al jaren gewerkt en er is dus ok veel onderzoek naar gedaan. Hieruit zijn bepaalde richtlijnen ontstaan mbt de meest efficiente structuur voor gegevens in databases. 1 daarvan is dat in de meeste gevallen tabellen met een 1 op 1 relatie samengevoegd horen te worden. Als jij het beter denkt te weten dan die 40 jaar ervaring van de hele DB-gemeenschap dan noem ik je eigenwijs ...

Noem me maar wat je wilt
Ik had denk ik het 1 op 1 stukje gemist. Ik ga er gewoon vanuit dat als je wat persoonsgegevens bij elkaar wilt pletten, en je wilt ook bijhouden wat voor auto iemand heeft, dat in een aparte tabel gaat omdat je nou eenmaal meer dan 1 auto kan hebben. Of een auto en een motor/boot/rolschaatsen...

40 jaar, da's langer als dat ik oud ben Wie ben ik om daar tegenin te gaan

[Janoz]

Op donderdag 21 maart 2002 12:12 schreef ShockWave het volgende:
ik wil helemaal niet eigenwijs zijn.... maar -> persoonlijk <- vind ik dit overzichtelijker wat is daar mis mee....

ff voor de duidelijkheid... mijn geschiedenis verhaaltje sloeg op deze reactie. Dat schijnt niet bij iedereen overgekomen te zijn

Het 1:n verhaal van crazy_d zou ik niet eens durfen tegen te spreken...

[ACM]

Nog even doorgaand op wat handig is.

Performance technisch/opslag technisch is het imho ook wat beter iets kleinere tabellen te hebben. Zeker als je van die ene tabel steeds maar 3 kolommen nodig hebt en een enkel keertje een stuk of 40. (zelfs bij een 1-1 relatie)

En wat crazy_d al zegt een user kan ook geen of meer dan één auto hebben.
[edit]
Maar Crazy_D's argument is verreweg het sterkste.

[Verwijderd]

Wat dacht je van deze query?

code:

SELECT gebruikersgegevens.*, auto_gegevens.type 
FROM gebruikersgegevens 
INNER JOIN auto_gegevens ON (auto_gegevens.uid = gebruikersgegevens.uid)

eventueel met

code:

GROUP BY gebruikersgegevens.uid 
ORDER BY gebruikersgegevens.naam

succes

[Rataplan]

Op donderdag 21 maart 2002 14:31 schreef Janoz het volgende:

Als ik zeg dat er een smilie bij staat en ik het niet kwaad bedoel vind je dat zeker zwak

Jazekers

Ik geef duidelijk aan dat dit over 1 op 1 relaties gaat. Mijn opmerking gaat over het feit dat de topicstarter 1 op 1 relaties liever toch scheidt omdat hij denkt dat dit overzichtelijker is.

Mijn punt is dus dat de topicstarter het nergens over 1-1 relaties heeft. Toch zeg jij hierboven:

(...) tabellen met een 1 op 1 relatie samengevoegd horen te worden. Als jij het beter denkt te weten (...)

Dus dan denk ik: dat is een reactie op de startpost. Niet zo gek, toch? Volgens mij heb je of de startpost niet gelezen, of 'm niet begrepen.

Als je problemen met mijn sig hebt, kun je dit melden in SU.

Ik heb een probleem met het feit dat jij mensen eigenwijs vindt zonder (volgens mij) te begrijpen wat ze willen. Om daar vervolgens op basis van generieke statements een waardeoordeel over te geven vind ik niet netjes van je... Je sig op zich was me eerder opgevallen en ook ik vind 'm grappig

Ik bedoelde die opmerking niet kleinerend oid. Ik wilde hiermee aangeven dat over dit probleem al heel lang nagedacht is.

Nogmaals: als je niet op de topicstarter reageert, kan je'm volgens mij niet eigenwijs noemen, en als je wel op hem reageerde zit je opmerking er naast. Alles in 1 tabel mikken is hier beperkt (of zelfs niet) van toepassing. Dat weten we op grond van de beschikbare gegevens nou eenmaal niet!

Maar als jij niet overtuigd bent van het feit dat je 1 op 1 relaties gewoon in dezelfde tabel zou moeten zetten, dan spreek ik idd niet voor jou...

Phew Maar dat zei ik dus niet. Ik ben er niet van overtuigd dat de topicstarter het over 1-1-relaties heeft, dat heb jij ervan gemaakt. Niet mijn woorden verdraaien, svp.

Distinct bied in dit geval niet de oplossing waar de topicstarter naar zoekt.

Ja, mag ik ook eens? Het zoeken naar distinct (waar je halfgelukte newbie-queries soms best goed mee kan patchen ) levert (duh) de SELECT-syntax-pagina op. En zoals ik al zei, daar valt een hoop informatie over topicstarter's vraag uit te halen.

Volgens mij dan, he.

edit:
En ondertussen leveren mensen als ACM en LightWaver wel nuttige informatie

[raptorix]

Wat een gemiereneuk zeg, jesus.

[Verwijderd]

in plaats van <tabel1> INNER JOIN <tabel2> ON ...
Er een NATURAL JOIN van maken. Dan gebeurt ON automatisch, mits er een veld met dezelfde naam in beide tabellen is.
Dit gaat natuurlijk mis, zodra 2 tabellen meer dan 1 veld gelijk hebben

[Verwijderd]

hmmmmm, NATURAL JOIN is nieuw voor mij.
Maar och, ik probeer toch zoveel mogelijk de namen gescheiden te houden zodat ik weet bij welke tabel wat hoort (meestal door de eerste 3 letters van de tabel naam voor de veldnamen te zetten).

[Verwijderd]

NATURAL INNER JOIN zal misschien nog beter werken
Natural is een voorvoegsel voor alle 'normale' join-types in SQL. Je kan dus ook een NATURAL RIGHT OUTER JOIN doen...
En wat die doet, mag je zelf opzoeken

[Verwijderd]

Wat INNER, OUTER etc etc doet dat weet ik, allen NATURAL was me nog niet bekend. Maar bedankt voor de tip