[sql] waarom relaties in sql opgeven?

[Alarmnummer]

Waarom is het eigelijk verplicht dat je in een sql query relaties zelf moet opgeven? De relaties zijn een onmisbaar onderdeel van het systeem en iedere resultaat die niet voldoet aan die relaties is incorrect, dus waarom worden relaties tussen tabellen niet automatisch toegevoegd aan een query?

dus

seleft merk from persoon, fiets where naam = 'peter';

ipv

seleft merk from persoon, fiets where (naam = 'peter') and (persoon.sofinr=fiets.sofinr);

[ Voor 4% gewijzigd door Alarmnummer op 11-08-2003 12:24 ]

[whoami]

Omdat je misschien wel op 'verschillende' manieren die data - gerelateerde gegevens - wilt ophalen.
Denk aan een LEFT, RIGHT, INNER, CROSS join.
Het DBMS kan niet weten op welke manier je die gegevens wilt ophalen. Je kan nu natuurlijk wel stellen dat dit moet op te vangen zijn door een extra clause in je query, bv:

code:

select naam, groep
FROM personen, groupen
WITH LEFT OUTER JOIN

bv, maar dan is het typen van de gewone join clause nu ook niet zoveel extra werk.

Daarbij kan het natuurlijk wel voorkomen dat je een DBMS systeem hebt, waarbij de relaties niet gelegd werden. (* whoami heeft dit al eens gezien/meegemaakt...)

[ Voor 56% gewijzigd door whoami op 11-08-2003 12:30 ]

[Verwijderd]

Daarnaast kunnen relaties tussen tabellen op meerdere manieren gedefinieerd worden.

[Alarmnummer]

whoami schreef op 11 August 2003 @ 12:28:
Omdat je misschien wel op 'verschillende' manieren die data - gerelateerde gegevens - wilt ophalen.
Denk aan een LEFT, RIGHT, INNER, CROSS join.
Het DBMS kan niet weten op welke manier je die gegevens wilt ophalen.

Een database systeem moet er voor zorgen (imho) dat de gegevens altijd correct zijn, laat hem zelf maar uitzoeken hoe het meest efficient die relaties gelegd moeten worden, maar dat ze gelegd moeten worden is een feit. Ik zie dus niet in waarom een gebruiker het beter kan dan een systeem.

Daarbij kan het natuurlijk wel voorkomen dat je een DBMS systeem hebt, waarbij de relaties niet gelegd werden. (* whoami heeft dit al eens gezien/meegemaakt...)

Tja... je kan het mannelijk geslacht ook niet afrekenen op een handje vol moordenaars die het voorbrengt.

[Alarmnummer]

Verwijderd schreef op 11 August 2003 @ 12:29:
Daarnaast kunnen relaties tussen tabellen op meerdere manieren gedefinieerd worden.

Uiteindelijk zal het relatie gedeelte voor iedere sql query hetzelfde eruit zien (ongeacht het systeem). Laat het systeem er dan zelf maar voor zorgen dat de relaties er op de juiste manier aan toegevoegd worden (dus ongeacht hoe de db relaties heeft gedefinieerd)

[Brothar]

dan hoef je dus ook de tabelnamen niet meer op te geven, maar bijv alleen:
select merk where naam="peter"
want het systeem herkent dat merk uit tabel fiets komt, en naam uit persoon, en vind zelf de relaties tussen die tabellen.

Ik denk alleen dat die logica redelijk wat overhead kost, bovendien mag elke veldnaa maar in 1 tabel voorkomen: dit is een onmogelijkheid bij verwijzende sleutels.

Verder moet je m.i. bedenken wat de geschiedenis is van sql: het stamt van een 25 jaar geleden. En wat sql doet is tabellen vermenigvuldigen. Nu kun je o.b.v. de relaties/indexen die intelligentie misschien wel inbouwen, maar toen zeker niet (toen was de sql-intelligentie ongetwijfeld belangrijker, als de hardware het tenminste aankon)

[ Voor 56% gewijzigd door Brothar op 11-08-2003 12:47 ]

[koli-man]

Alarmnummer schreef op 11 August 2003 @ 12:35:
[...]

Uiteindelijk zal het relatie gedeelte voor iedere sql query hetzelfde eruit zien (ongeacht het systeem). Laat het systeem er dan zelf maar voor zorgen dat de relaties er op de juiste manier aan toegevoegd worden (dus ongeacht hoe de db relaties heeft gedefinieerd)

Is het niet zo, dat ditgene met een OO database gerealiseerd wordt?

[Varienaja]

Waar ik pas echt naar van word is dat gezeur over group by functies.

Iedere keer vergeet ik 'm weer en dan zegt Oracle dat ik de group-by mis. Laat 'm dat ding er dan zelf bijzetten dan :-P

_{Ook hier: wie weet wil de gebruiker wel iets heel anders..}

[Annie]

Alarmnummer schreef op 11 August 2003 @ 12:33:
[...]

Een database systeem moet er voor zorgen (imho) dat de gegevens altijd correct zijn,

klopt. En daarvoor bestaan dus ook de FK constraints zodat bij bewerkingen op de data de integriteit bewaakt kan worden.

Alarmnummer schreef op 11 August 2003 @ 12:33:
laat hem zelf maar uitzoeken hoe het meest efficient die relaties gelegd moeten worden, maar dat ze gelegd moeten worden is een feit.

Klopt niet helemaal. Misschien ligt er nog wel een tweede FK tussen persoon en fiets, welke moet de database dan pakken?

[Alarmnummer]

Brothar schreef op 11 augustus 2003 @ 12:43:
dan hoef je dus ook de tabelnamen niet meer op te geven, maar bijv alleen:
select merk where naam="peter"
want het systeem herkent dat merk uit tabel fiets komt, en naam uit persoon, en vind zelf de relaties tussen die tabellen.

Idd. En dat is dus ook precies wat ik verwacht als het systeem waar ik aan werk queries binnenkrijgt. Zo gauw bepaald kan worden uit welke tabel een column gehaald kan worden, dan hoeft de table er niet meer als prefix ervoor opgegeven te worden. En verder is het ook niet nodig om een from clause nog te gaan vullen. Aan de hand van de columns in de querie, kan vastgesteld worden welke tabellen allemaal nodig zijn (dus direct voor de aanwezig columns, maar ook indirect voor de tussenliggende tabellen tussen expliciet bepaalde tabellen).

Ik denk alleen dat die logica redelijk wat overhead kost, bovendien mag elke veldnaa maar in 1 tabel voorkomen: dit is een onmogelijkheid bij verwijzende sleutels

Computers zijn snel zat en queries kunnen ook gereused worden, dus dat mag de pret niet drukken.

Verder moet je m.i. bedenken wat de geschiedenis is van sql: het stamt van een 25 jaar geleden. En wat sql doet is tabellen vermenigvuldigen. Nu kun je o.b.v. de relaties/indexen die intelligentie misschien wel inbouwen, maar toen zeker niet (toen was de sql-intelligentie ongetwijfeld belangrijker, als de hardware het tenminste aankon)

Misschien tijd om rdbms volledig in te laten slapen (en ook meteen in de prullemand te gooien)

[Freee!!]

Minimaal één goede reden om de relaties expliciet aan te geven is, dat de velden waarover de relatie ligt niet dezelfde naam hoeven te hebben en soms zelfs niet kunnen hebben (SELF JOIN op verschillende velden). Hier op mijn werk hebben we een systeem waarbij de eerste twee tekens van de naam van een veld direct aangeven uit welke tabel het veld komt. Handig als je dus behalve met SQL je de tabellen ook met andere methodes in programma's wilt benaderen.

[mvdejong]

Denk eens na wat je bedoelt met "relaties". Ik denk dat je het hebt over een mengsel van "relational constraints" en "stored procedures", maar de consequenties daarvan zijn in de huidige implementaties gelukkig niet zover strekkend als je denkt.

Om jouw voorbeeldje aan te spreken : je zal in een goed opgezette database die modern genoeg is (constraints en procedures zijn aanmerkelijk recenter dan SQL op zich) inderdaad wel kunnen specificeren dat de invulling van het veld "sofinr" in de "fiets"-tabel alleen mag gebeuren met de waarden die "sofinr" in de "persoon"-table, maar het hangt maar helemaal af van de wensen die jij met die query hebt of je die koppeling ook wil hebben bij elke query die beide tabellen raakt. Zo'n constraint op SELECT enz. i.p.v. alleen op UPDATE/INSERT enz. zou bijv. het moeilijk maken een query te bouwen waarin je vraagt om alle mensen die geen fiets hebben.

Bovendien, het komt in wat complexere databases veel voor dat relaties tussen 2 tabellen op vele sleutels (soms samengestelde) zijn gedefinieerd, en de keuze voor de sleutel kan alleen in de query zelf worden bepaald, door de eisen die de programmeur aan die query stelt :

Een extreem voorbeeld krijg je als je een familie-database samenstelt, waarbij je een afzichtelijke lijst relaties binnen dezelfde "persoon" tabel hebt : zelfs in het minimale geval heb je de relaties "is kind van" / "is ouder van", en als je iets efficienter wil zijn komen er snel nog andere familie-verhoudingen bij.

Een andere vorm van complexiteit is de M:N relatie, bijv. als je het hebt over personen en adressen : een persoon kan op meerdere adressen wonen (bijv. studenten met een kamer die in het weekeinde thuiskomen), en op een adres kunnen meerdere personen wonen.

In beide gevallen wordt het onmogelijk om bij queries altijd de database te laten uitzoeken welke relatie in het specifieke geval de juiste is.

Een bijkomend verschijnsel (en een van de redenen waarom constraints en procedures in de database zelf niet altijd gewenst zijn) is dat je de functionaliteit van je database op 2 plaatsen vastlegt, deels in de database, deels in de applicaties. Bovendien zijn constraints en procedures nogal hongerig als het om performance gaat. Met name voor single-application databases (databases die enkel als "prive-opslag" dienen voor een bepaalde applicatie) verdient het vaak de voorkeur alle functionaliteit binnen de applicatie te beleggen.

[Alarmnummer]

Annie schreef op 11 August 2003 @ 12:50:
Klopt niet helemaal. Misschien ligt er nog wel een tweede FK tussen persoon en fiets, welke moet de database dan pakken?

Daarom moet idd ook de impliciet nodige tabellen bepaald worden. Stel dat persoon een fiets heeft, en een fiets is gemaakt door een bepaald bedrijf. En ik wil het bedriijf weten waarbij de fiets van een persoon is gemaakt, dan moet fiets als impliciete tabel tussen worden gevoegd.


select bedrijfnaam where voornaam = 'peter';


Het systeem moet het maar vertalen naar:

select bedrijfnaam from persoon, fiets, bedrijf where persoon.sofinr = fiets.sofinr and fiets.bedrijfsnr=bedrijf.bedrijfnr and voornaam = 'peter'

Het enigste probleem dat ik hierbij zie is hoe het systeem de tussenliggende tabellen moet gaan bepalen. Dit probleem kan je perfect vergelijken met de traveling salesman 'probleem', en heeft helaas ook de bijbehorende complexiteit.

[ Voor 3% gewijzigd door Alarmnummer op 11-08-2003 12:57 ]

[whoami]

Alarmnummer schreef op 11 August 2003 @ 12:33:
[...]

Een database systeem moet er voor zorgen (imho) dat de gegevens altijd correct zijn, laat hem zelf maar uitzoeken hoe het meest efficient die relaties gelegd moeten worden, maar dat ze gelegd moeten worden is een feit. Ik zie dus niet in waarom een gebruiker het beter kan dan een systeem.

Ik heb het niet over gebruikers, maar over programmeurs.
Als jij 2 tabellen hebt, die met elkaar in relatie staan (bv. Personen en Woningen).
Een Persoon kan 0, 1 of meerdere woningen hebben.
Een programmeur moet bv iets schrijven die een lijstje weergeeft van alle personen die woningen hebben, of een lijst generen van alle personen en hun woningen, en ook de personen die geen woningen hebben moeten op die lijst voorkomen, dan ga je een ander join type nodig hebben.
Het is dus ook een soort van flexibiliteit die je krijgt. Het nadeel is dan wel dat je wat meer typewerk hebt.

[whoami]

Alarmnummer schreef op 11 augustus 2003 @ 12:35:
[...]

Uiteindelijk zal het relatie gedeelte voor iedere sql query hetzelfde eruit zien (ongeacht het systeem). Laat het systeem er dan zelf maar voor zorgen dat de relaties er op de juiste manier aan toegevoegd worden (dus ongeacht hoe de db relaties heeft gedefinieerd)

Niet akkoord; zie ook m'n eerdere post:

code:

LEFT JOIN tabel2 ON tabel1.id = tabel2.f_id
INNER JOIN tabel2 ON tabel1.id = tabel2.f_id
CROSS JOIN tabel2 ON tabel1.id = tabel2.f_id

zijn 3 verschillende joins.

[mvdejong]

Alarmnummer schreef op 11 August 2003 @ 12:56:
[...]

Daarom moet idd ook de impliciet nodige tabellen bepaald worden. Stel dat persoon een fiets heeft, en een fiets is gemaakt door een bepaald bedrijf. En ik wil het bedriijf weten waarbij de fiets van een persoon is gemaakt, dan moet fiets als impliciete tabel tussen worden gevoegd.


select bedrijfnaam where voornaam = 'peter';


Het systeem moet het maar vertalen naar:

select bedrijfnaam from persoon, fiets, bedrijf where persoon.sofinr = fiets.sofinr and fiets.bedrijfsnr=bedrijf.bedrijfnr and voornaam = 'peter'

Het enigste probleem dat ik hierbij zie is hoe het systeem de tussenliggende tabellen moet gaan bepalen. Dit probleem kan je perfect vergelijken met de traveling salesman 'probleem', en heeft helaas ook de bijbehorende complexiteit.

Dank je voor het ingooien van je eigen glazen.
Want stel nu eens dat ik bedoelde met de query dat ik wilde weten welke "peter" er bij dat bedrijf werken ? In een wat complexere database (ik denk alles vanaf een dozijntje tabellen) zijn er meerdere relaties te verzinnen tussen tabellen die niet eens een (primaire) sleutel delen.

[djluc]

Het idee om relaties als consistency check te automatiseren, oftwel het opgeven van keys in de database waaraan voldaan moet worden is wel mogelijk(Acces?). Bijvoorbeeld de waarde in het veld bedrijfsid moet ook in het veld id van de tabel bedrijven staan. Verder kun je niet veel automatiseren omdat je dan vrijheid als programmeur zijnde inlevert en dat willen we niet Onze klanten trouwens ook niet want dan kunnen we minder aangepaste zaken maken.

[whoami]

Over het weglaten van de FROM clause:
Dat zou dan dus impliceren dat een veldnaam geen 2x mag voorkomen. Je hebt bv. een tabel Personen met daarin een veld naam. Als je dan nog een andere tabel hebt met een veld 'naam', dan heb je een probleem.
En hoe zit het dan met ad-hoc queries? Stel, je wilt een query uitvoeren die data nodig heeft van een andere server (al dan niet linked), hoe doe je dat dan?

[jvdmeer]

Ik denk dat TS wel een punt heeft: Vergelijk het met bijv. MS Access. Zodra je bij de relaties de juiste relaties eenmalig heb aangegeven, zal de query-builder uit zichzelf de juiste tabellen en joins formuleren. Maar dit geldt dan hooguit voor tabellen waar maximaal 1 join tussen bestaat.

Dus om terug te komen op de fiets en zijn eigenaar:
Het DBMS zal nooit zelf kunnen kiezen tussen de volgende twee gevallen:

SQL:

seleft merk 
  from persoon, fiets 
  where (naam = 'peter') and (persoon.id=fiets.eigenaar);

SQL:

seleft merk 
  from persoon, fiets
  where (naam = 'peter') and (persoon.id=fiets.berijder);

[ Voor 4% gewijzigd door jvdmeer op 11-08-2003 13:26 ]

[Alarmnummer]

Ik zie zelf ook dat ik een steek heb laten vallen. Ik ben op dit moment bezig met het afhandelen van queries in een expertsysteem. Hierbij wil ik zoveel mogelijk door het expertsysteem op het gebied van queries laten afleiden en zo weinig mogelijk door de knowledge engineer (programmeur van het expertsysteem) laten doen. Ik ben dus aan het experimenteren hoe ik dus zoveel mogelijk kan automatiseren.

[Varienaja]

whoami schreef op 11 August 2003 @ 13:22:
Over het weglaten van de FROM clause:
Dat zou dan dus impliceren dat een veldnaam geen 2x mag voorkomen.

Och.. wij hebben bij ons bedrijf verschillende views, die adresgegevens bij bepaalde objecten laten zien. Als ik twee van die views join dan krijg ik soms twee keer de adresgegevens. De BDE van borland maakt van iedere tweede kolom dan gewoon een andere naam. Dan krijg je dus:
ID, Straatnaam, Straatnaam_1, Huisnr, Huisnr_1, etc.

[ACM]

Overigens is dit wel vooral voor het Rdbms principe zo, er zijn meerdere databasesoorten, waarbij Rdbms-en weliswaar de meest gebruikte zijn, maar zeker niet de enige.

Wellicht zou je eens naar Xplain en soortgelijke (mijn docent zou boos worden als ik dit zei ) databases moeten kijken:

quote: http://www.berenddeboer.net/xplain/

Xplain is a beautifully orthogonal database manipulation and query language. Orthogonal means that with Xplain there is usually only one solution, not dozens like in SQL. Xplain straight-forwardly supports aggregation and generalization. Or in other words, it supports has-a and is-a relations, the only possible relations. Because it supports is-a relations, it is a very natural component in an object-oriented environment.

De relaties worden daar impliciet gegarandeerd, hoewel ik door mijn ervaring met SQL-databases er regelmatig tegen aan liep dat dat juist een beperking werd. Andere typen databases zijn natuurlijk de OO-databases, die wellicht beter aansluiten op OO eisen

[ATS]

En welke straatnaam bedoel ik dan als er in zowel een tabel persoon als in een tabel bedrijf het veld straatnaam voorkomt in de volgende 'query':

code:

select bedrijfsnaam, achternaam, straatnaam

Dit is ambivalent: wil ik de straatnaam van het bedrijf, of van de persoon zien?

[Alarmnummer]

ATS schreef op 11 August 2003 @ 13:57:
En welke straatnaam bedoel ik dan als er in zowel een tabel persoon als in een tabel bedrijf het veld straatnaam voorkomt in de volgende 'query':

code:

select bedrijfsnaam, achternaam, straatnaam

Dit is ambivalent: wil ik de straatnaam van het bedrijf, of van de persoon zien?

Dat kan je fixen door de tabel als prefix op te nemen, dus Persoon.straatnaam.

[ Voor 5% gewijzigd door Alarmnummer op 11-08-2003 14:13 ]

[Alarmnummer]

ACM schreef op 11 August 2003 @ 13:55:
Overigens is dit wel vooral voor het Rdbms principe zo, er zijn meerdere databasesoorten, waarbij Rdbms-en weliswaar de meest gebruikte zijn, maar zeker niet de enige.

Ik weet het, maar ik modeleer de database ook niet, dat doet onze knowledge engineer, en voor expertsystemen is het ook vrij gebruikelijk om te werken met rdbm-systeem. Voor mijn eigen projecten ga ik binnenkort experimenteren met JDO. Hierbij maakt het voor mij in ieder geval niet meer zoveel uit wat voor systeem eronder zit, omdat door bytecode generatie de mapping plaats vind.

Wellicht zou je eens naar Xplain en soortgelijke (mijn docent zou boos worden als ik dit zei ) databases moeten kijken:

Ik zal er zeker even naar kijken.