DB / Query logica op schaalbaarheid

[Blomminator]

Hoi,

ik ben als leerproject een website aan het maken. Ik wil hierin gegevens loggen, van welke routes ik heb geklommen.
Hiervoor heb ik een DB en de volgende theorie.
3 tabellen
- Gebruikers
- Routes
- GebruikersRoutes

In gebruikers alle mensen, alle routes in Routes en in GebruikersRoutes de mix. Wie heeft welke route geklommen. Dit werkt nog niet, maar basaal kan ik wat moet doen.

MAAR! Als ik nu van gebruiker X uit GebruikersRoutes ophaal welke routes deze allemaal geklommen heeft (bijv. 1, 2, 3, 4 & 5) krijg ik een query als

SELECT * FROM `routes` WHERE `routekey` in (1,2,3,4,5)


Op zich prima, maar ik vraag mij af of dit "theoretisch" goed is. Stel iemand heeft 2343912 routes geklommen, dan krijg je een zut van een query.

Behoorlijke beginnersvraag, en ooit heb ik hier goede antwoorden op gehad, maar ik ben dit weer opnieuw aan het leren. Dit is dus een hobbyproject om weer te leren. Goede tips en alles is zeer welkom!

Bedankt !

[SKiLLa]

Tabelnamen zijn normaliter enkelvoud; niet meervoud. Dus Gebruiker, niet Gebruikers. En keys zijn Ids, of noem het anders tenminste sleutel of doe alles in het Engels, maar niet gemixt.

En als je de routes van gebruiker X ophaalt; dan schrijf je toch iets als: select ... from [routes] where [userId] = X ipv alle route-nummers ?

[Orion84]

Kijk eens naar het concept van de JOIN.

[Damic]

Om het antwoord van @Orion84 aan te vullen https://www.w3schools.com/SQL/sql_join.asp

[ Voor 3% gewijzigd door Damic op 03-11-2019 14:41 ]

[Blomminator]

Allen, mijn dank!
Precies wat ik zocht in de JOIN.


In het verleden weleens mee gerommeld, maar kon t niet meer goed bedenken:
SELECT distinct routes.routename FROM routes INNER JOIN usersroutemonitor ON usersroutemonitor.routekey = routes.routekey

De kinderen zijn weg, dus even rustig er mee stoeien. Maar dit is prima basis.

Erg blij mee!

[ Voor 0% gewijzigd door Blomminator op 03-11-2019 16:00 . Reden: Tikfoutje ]

[Kalentum]

SKiLLa schreef op zondag 3 november 2019 @ 13:28:
Tabelnamen zijn normaliter enkelvoud; niet meervoud. Dus Gebruiker, niet Gebruikers.

Onzin! Tabelnamen zijn niet normaliter enkelvoud. Er is geen normaliter. Je databaseserver dwingt niets af.

Ik gebruik al jaren Ruby on Rails en daar is het meervoud. Dus een User object staat in de users tabel. Een Product staat in een products tabel.

Er zijn vast wel academische redenen aan te voeren waarom enkelvoud of meervoud. Zolang je maar consistent bent. Maar het is niet zo dat het per definitie enkelvoud moet zijn.

[ Voor 3% gewijzigd door Kalentum op 03-11-2019 16:48 ]

[Grijze Vos]

Kalentum schreef op zondag 3 november 2019 @ 16:48:
[...]

Er zijn vast wel academische redenen aan te voeren waarom enkelvoud of meervoud. Zolang je maar consistent bent. Maar het is niet zo dat het per definitie enkelvoud moet zijn.

Eerder praktische redenen. O/R mappers mappen tabelnamen naar class names, en daar is enkelvoud handiger. Als je domein taal engels is zijn de meeste O/R mappers nog wel slim genoeg om zelf de conversie naar enkelvoud te doen, maar in andere talen is dat al tricky.

[EfBe]

Kalentum schreef op zondag 3 november 2019 @ 16:48:
[...]
Onzin! Tabelnamen zijn niet normaliter enkelvoud. Er is geen normaliter. Je databaseserver dwingt niets af.

Tabellen zijn het resultaat van een projectie van een abstract entity model, waarbij je normaliter entities met enkelvoudige namen gebruikt ("Customer", "Order" etc.). Een tabel is dan ook een collectie van instances van een entity definitie, de table row. Het is hetzelfde als een collectie van instances van een andere projectie van hetzelfde abstract entity model, bv een class.

Dus jouw 'Onzin' is wat sterk aangezet: tuurlijk mag je lekker zelf weten wat voor namen je aan je tabellen geeft. Het is echter gebruikelijk dat tabellen enkelvoudige namen hebben en de reden daarvoor staat hierboven.

Ik gebruik al jaren Ruby on Rails en daar is het meervoud. Dus een User object staat in de users tabel. Een Product staat in een products tabel.

Er zijn vast wel academische redenen aan te voeren waarom enkelvoud of meervoud. Zolang je maar consistent bent. Maar het is niet zo dat het per definitie enkelvoud moet zijn.

Ja per definitie moet het enkelvoud zijn. Je mag meervoudige namen gebruiken natuurlijk. Wat ik in de afgelopen tig jaar gezien heb aan modellen geeft 1 duidelijk beeld: wanneer de tabellen meervoudige namen hebben lijkt het erop dat die tabellen met de hand zonder achterliggend model zijn gedefinieerd. Het laat zich raden hoe geweldig die modellen werken na een zekere periode

[ Voor 0% gewijzigd door EfBe op 05-11-2019 09:45 . Reden: Engrish... :X ]

[Lethalis]

Kalentum schreef op zondag 3 november 2019 @ 16:48:
[...]
Er zijn vast wel academische redenen aan te voeren waarom enkelvoud of meervoud. Zolang je maar consistent bent. Maar het is niet zo dat het per definitie enkelvoud moet zijn.

Het is een relatie in een relationeel model Waarbij een relatie al een verzameling van gegevens is.

Op het moment dat je meervoud gebruikt, zeg je eigenlijk dat het een verzameling van een verzameling is. Mij is dan ook altijd geleerd dat ik enkelvoud moet gebruiken.

Of concreet:

De Gebruiker relatie kan bestaan uit de GebruikerId en Naam gegevens.
De verzameling van alle GebruikerId en Naam gegevens omvat dus alle gegevens van de Gebruiker relatie.

Je zegt in feite alleen maar dat er een verband bestaat tussen de GebruikerId en Naam gegevens.

[ Voor 31% gewijzigd door Lethalis op 05-11-2019 10:02 ]

[BertS]

Maar de tabel met gebruikers is volgens jouw redenatie een verzameling van een verzameling: de samenhang tussen de velden (GebruikerId en Naam) is een verzameling. Maar de verschillende gebruikers die er in staan vormen ook een verzameling.
Dus een Verzameling (Gebruikers) van een Verzameling (Gebruiker)

[Kalentum]

mijn 'Onzin!' is net zo sterk aangezet als 'Tabelnamen zijn normaliter enkelvoud; niet meervoud'. Normaliter is niet objectief.

In mijn geval (Ruby on Rails) geldt convention over configuration en dat betekent dat ik dus doe wat het framework adviseert. Rails neemt aan dat een class User een corresponderende tabel 'users' heeft.

Anyways het internet staat vol met pro's en cons van beide keuzes. Als je maar consequent bent anders wordt het een bende.

[Gomez12]

Grijze Vos schreef op zondag 3 november 2019 @ 21:49:
[...]

Eerder praktische redenen. O/R mappers mappen tabelnamen naar class names, en daar is enkelvoud handiger. Als je domein taal engels is zijn de meeste O/R mappers nog wel slim genoeg om zelf de conversie naar enkelvoud te doen, maar in andere talen is dat al tricky.

Het is maar net wat je praktische redenen noemt.
In wezen zeg jij :
- Als je domein taal engels is
- Als je O/R mapper custom slimheid bevat
dan kan je vaak van enkelvoud naar goed meervoud gaan in je O/R mapper, maar soms gaat het ook fout.

Als je zo graag je objecten meervoud wilt hebben, dan zou ik eerder pleiten voor ook meervoud in je tabelnamen, dan ben je niet meer afhankelijk van of engels je domeinnaam is en of je O/R mapper genoeg slimheid bevat. Dan heb je gewoon 100% "juist" objectnamen.

Oftewel ik vind hetgene wat jij noemt een hele slechte reden, er worden hier wel andere goede redenen genoemd, maar deze "praktische redenen" zijn gewoon onzin.

[Grijze Vos]

Gomez12 schreef op dinsdag 5 november 2019 @ 11:43:

Als je zo graag je objecten meervoud wilt hebben, dan zou ik eerder pleiten voor ook meervoud in je tabelnamen, dan ben je niet meer afhankelijk van of engels je domeinnaam is en of je O/R mapper genoeg slimheid bevat. Dan heb je gewoon 100% "juist" objectnamen.

Ik wil mijn objecten juist in enkelvoud hebben. De redenaties erbij zijn "verzachtende omstandigheden" waardoor het minder uitmaakt als je toch meervoud gebruikt in je tabellen.

[pedorus]

In het kader van praktische redenen: In het Engels is het enkelvoud van gebruiker "user", echter is dat veelal een reserved word. En die zou ik nooit aanraden als tabelnaam.. "users" daarentegen is veelal prima en die tabel bevat normaal ook meerdere gebruikers en niet slechts 1 gebruiker, wat de naam dus ook nog eens omschrijvender maakt.

Het hele idee van een SQL database is dat je er makkelijk SQL queries op kan doen, met tabelnamen als "User" kan dat gewoon niet. En een niet-Engelse naam als "Gebruiker" voor een tabel vind ik sowieso niet ok, dan sluit je vooral heel veel programmeurs/gebruikers uit. En namen met een hoofdletter erin kunnen ook voor problemen zorgen (bijv. mariadb/mysql op Windows).

Kalentum schreef op zondag 3 november 2019 @ 16:48:
Dus een User object staat in de users tabel.

En dat is precies zoals ik het graag zie.

[BarôZZa]

Tabelnamen en velden zijn normaliter in het latijn. Anders ben je een prutser.

[EfBe]

pedorus schreef op dinsdag 5 november 2019 @ 22:51:
In het kader van praktische redenen: In het Engels is het enkelvoud van gebruiker "user", echter is dat veelal een reserved word. En die zou ik nooit aanraden als tabelnaam.. "users" daarentegen is veelal prima en die tabel bevat normaal ook meerdere gebruikers en niet slechts 1 gebruiker, wat de naam dus ook nog eens omschrijvender maakt.

Het is wat lastiger, maar ook weer niet zoveel lastiger. [user] en je bent klaar. Of "User", of `User`, al naar gelang de RDBMS smaak die je gebruikt.

Het hele idee van een SQL database is dat je er makkelijk SQL queries op kan doen, met tabelnamen als "User" kan dat gewoon niet. En een niet-Engelse naam als "Gebruiker" voor een tabel vind ik sowieso niet ok, dan sluit je vooral heel veel programmeurs/gebruikers uit. En namen met een hoofdletter erin kunnen ook voor problemen zorgen (bijv. mariadb/mysql op Windows).

De naam wrappen in "", ``, of [] lost die problemen op. Tuurlijk, als je die characters niet wilt typen dan zul je een andere naam moeten kiezen, maar dat neemt niet weg dat maar wat kiezen zonder een theoretische reden riekt naar prutsen. "Ff een tabelletje erbij en klaar"...

[pedorus]

EfBe schreef op woensdag 6 november 2019 @ 08:25:
Het is wat lastiger, maar ook weer niet zoveel lastiger. [user] en je bent klaar. Of "User", of `User`, al naar gelang de RDBMS smaak die je gebruikt.

Wat makkelijk is dat toch. Zo gebruik ik in programmeercode ook altijd namen als "for", want je kan toch escapen? (in de meeste talen dan)

De naam wrappen in "", ``, of [] lost die problemen op. Tuurlijk, als je die characters niet wilt typen dan zul je een andere naam moeten kiezen, maar dat neemt niet weg dat maar wat kiezen zonder een theoretische reden riekt naar prutsen. "Ff een tabelletje erbij en klaar"...

De 2 redenen die ik noem zijn zowel praktisch als theoretisch. Maar anders is er ook nog wel een autoriteitsargument als dat je meer aanspreekt. De SQL ANSI standaard gebruikt zelf ook meervoud: Wikipedia: Information schema. Waren ze daar ook aan het "prutsen"?

[Gomez12]

pedorus schreef op woensdag 6 november 2019 @ 09:30:
[...]

Wat makkelijk is dat toch. Zo gebruik ik in programmeercode ook altijd namen als "for", want je kan toch escapen? (in de meeste talen dan)

Escapen is niet erg en zo af toe gewoon de standaard, ik zie vaak genoeg situaties waar reserved words gewoon binnen het domeinmodel vallen, dan kan je of moeilijk gaan doen of gewoon escapen...

[...]

De 2 redenen die ik noem zijn zowel praktisch als theoretisch. Maar anders is er ook nog wel een autoriteitsargument als dat je meer aanspreekt. De SQL ANSI standaard gebruikt zelf ook meervoud: Wikipedia: Information schema. Waren ze daar ook aan het "prutsen"?

Ah, je bedoelt de standaard waar eigenlijk geen enkele huidige rdbms zich meer aan houd omdat die te beperkt en te rigide is?
Ik zeg kijk naar de praktijk en niet naar een niet-gebruikte standaard...

[Lethalis]

pedorus schreef op dinsdag 5 november 2019 @ 22:51:
En een niet-Engelse naam als "Gebruiker" voor een tabel vind ik sowieso niet ok, dan sluit je vooral heel veel programmeurs/gebruikers uit.

Ik vind dat altijd zwaar overdreven. Als je een domein / data modelleert, wil je zoveel mogelijk natuurlijke taal gebruiken die overeenkomt met de werkelijkheid.

Het vertalen ervan zorgt dan alleen voor ruis.

Dat doe ik alleen maar bij internationale projecten. Als ik weet dat het alleen in Nederland gebruikt zal worden, dan vind ik het zonde van de tijd en energie.

En bij ons komen werken wordt hem sowieso niet als je geen Nederlands kan.

[PatrickH89]

Lethalis schreef op woensdag 6 november 2019 @ 10:21:
[...]

Ik vind dat altijd zwaar overdreven. Als je een domein / data modelleert, wil je zoveel mogelijk natuurlijke taal gebruiken die overeenkomt met de werkelijkheid.

Het vertalen ervan zorgt dan alleen voor ruis.

Dat doe ik alleen maar bij internationale projecten. Als ik weet dat het alleen in Nederland gebruikt zal worden, dan vind ik het zonde van de tijd en energie.

En bij ons komen werken wordt hem sowieso niet als je geen Nederlands kan.

Ieder heeft zo zijn voorkeur. Omdat mijn programmeertaal in het Engels is heb ik als voorkeur om alles in het Engels te doen.

Vreemd dat dit topic vervallen is in een discussie over conventies waar zoals gewoonlijk weer mensen zitten die denken dat hun conventie de enige mogelijke conventie is en dat al het andere onzin is. Een conventie is goed op het moment dat het consistent wordt doorgevoerd in de code base, verder is het absoluut niet relevant.

[Janoz]

PatrickH89 schreef op woensdag 6 november 2019 @ 10:29:
[...]
Ieder heeft zo zijn voorkeur. Omdat mijn programmeertaal in het Engels is heb ik als voorkeur om alles in het Engels te doen.

Voorkeur is misschien leuk, handig is het niet. De extra ruis maakt het alleen maar foutgevoelig. Goed, als je zelf het domein bepaald zou ik ook voor Engels kiezen omdat de rest van de programmeertaal Engels is, maar dat is de minst belangrijke reden.

Vreemd dat dit topic vervallen is in een discussie over conventies waar zoals gewoonlijk weer mensen zitten die denken dat hun conventie de enige mogelijke conventie is en dat al het andere onzin is. Een conventie is goed op het moment dat het consistent wordt doorgevoerd in de code base, verder is het absoluut niet relevant.

Met discussie is niks mis hoor. Ik ben het wel met je eens dat het belangrijker is je aan een conventie te houden dan wat nu daadwerkelijk die conventie is. Ze zijn echter wel degelijk relevant. Je kunt wel heel onconventionele conventies aanhouden, maar hou er dan wel rekening mee dat dat de onderhoudbaarheid en overdraagbaarheid van je project zeer nadelig beïnvloed. Blijkbaar is het in de Ruby wereld gebruikelijk om tabellen meervoud te noemen, doe dat daar dan ook. Bij Hibernate daarentegen is enkelvoud de norm.

[PatrickH89]

Janoz schreef op woensdag 6 november 2019 @ 11:14:
[...]

Met discussie is niks mis hoor. Ik ben het wel met je eens dat het belangrijker is je aan een conventie te houden dan wat nu daadwerkelijk die conventie is. Ze zijn echter wel degelijk relevant. Je kunt wel heel onconventionele conventies aanhouden, maar hou er dan wel rekening mee dat dat de onderhoudbaarheid en overdraagbaarheid van je project zeer nadelig beïnvloed. Blijkbaar is het in de Ruby wereld gebruikelijk om tabellen meervoud te noemen, doe dat daar dan ook. Bij Hibernate daarentegen is enkelvoud de norm.

Ik bedoelde dat vooral in relatie tot OP. Het heeft namelijk weinig te maken met de vraag. Discussie over conventies is prima, maar mensen moeten in gedachten houden dat conventies per definitie niet set in stone zijn. Met betrekking tot namen van tabellen in databases heb je de vrijheid om dit naar eigen situatie in te vullen. Ik ben zeker van mening dat het het beste is om de conventies van je framework/ORM aan te houden in veruit de meeste situaties.
Ik kan me wel ergeren aan de stelligheid van de reactie waar de discussie mee begon, dat is namelijk gewoon pure onzin (de conventie niet per sé, maar de stelligheid dat dit het geval is in alle gevallen).

[BadpunK]

SKiLLa schreef op zondag 3 november 2019 @ 13:28:
Tabelnamen zijn normaliter enkelvoud; niet meervoud. Dus Gebruiker, niet Gebruikers. En keys zijn Ids, of noem het anders tenminste sleutel of doe alles in het Engels, maar niet gemixt.

En als je de routes van gebruiker X ophaalt; dan schrijf je toch iets als: select ... from [routes] where [userId] = X ipv alle route-nummers ?

Check de default 'tables' in een Oracle database maar eens. Toch meervoud, namelijk:

- all_tables
- all_tab_columns
- all_users

Etc.

[sig69]

Jeej weer een discussie over hoe je tabellen in een database noemt! Het boeit mij echt niks meer, ik hou de conventie aan die in een database gebruikt wordt. ORM mapper er overheen en klaar. Persoonlijk heb ik heus wel een voorkeur, en die gebruik ik in nieuwe projecten.

[SKiLLa]

Kalentum schreef op zondag 3 november 2019 @ 16:48:
[...]


Onzin! Tabelnamen zijn niet normaliter enkelvoud. Er is geen normaliter. Je databaseserver dwingt niets af.

Ik gebruik al jaren Ruby on Rails en daar is het meervoud. Dus een User object staat in de users tabel. Een Product staat in een products tabel.

Er zijn vast wel academische redenen aan te voeren waarom enkelvoud of meervoud. Zolang je maar consistent bent. Maar het is niet zo dat het per definitie enkelvoud moet zijn.

Ja, er zijn inderdaad een heleboel goede redenen om het in enkelvoud te houden. Dat als onzin wegzitten is pure onwetendheid; doe je huiswerk i.p.v. maar wat te roepen. En dat je favoriete RoR ORM mapper het in meervoud doet, doet daar niets aan af; spring jij ook zomaar in de sloot als een ander het doet zonder zelf na te denken ?

- Ordening van namen: Order, OrderDetail ipv OrderDetails, Orders
- Samenvoegingen: OrdersDetails ???
- Onregelmatige meervouden
- Logische representatie van 1 rij van data: vrijwel altijd 1 object / dataset, niet meervouden; SELECT [Id] FROM [Users] WHERE [Users].Name = 'whatever'

En ja, natuurlijk is de naming-convention niet heilig, maar lulraak meervouden gebruiken wordt over het algemeen wel echt als een beginnersfout gezien ...

[The Eagle]

BadpunK schreef op woensdag 6 november 2019 @ 23:03:
[...]


Check de default 'tables' in een Oracle database maar eens. Toch meervoud, namelijk:

- all_tables
- all_tab_columns
- all_users

Etc.

Klopt dat die in meervoud zijn. Echter:
- dat is metadata en geen transactiedata
- ALL_% is datgene wat jij als gebruiker mag zien cq rechten toe hebt van je eigen en andere schema's, en dus logischerwijs altijd meervoud. Zo is er ook user_tab_columns bijvoorbeeld, dat zijn echt die van jezelf.
- het zijn stiekem geen van allen tabellen maar allemaal views

Mijn Oracle 11g DBA I en II begint wat roestig te worden maar dat weet ik nog

Daarnaast: taal is niet triviaal. Als je naar applicatietabellen van SAP gaat kijken hebben ze allemaal Duitse namen

[BadpunK]

The Eagle schreef op zondag 10 november 2019 @ 15:46:
[...]

Klopt dat die in meervoud zijn. Echter:
- dat is metadata en geen transactiedata
- ALL_% is datgene wat jij als gebruiker mag zien cq rechten toe hebt van je eigen en andere schema's, en dus logischerwijs altijd meervoud. Zo is er ook user_tab_columns bijvoorbeeld, dat zijn echt die van jezelf.
- het zijn stiekem geen van allen tabellen maar allemaal views

Mijn Oracle 11g DBA I en II begint wat roestig te worden maar dat weet ik nog

Daarnaast: taal is niet triviaal. Als je naar applicatietabellen van SAP gaat kijken hebben ze allemaal Duitse namen

Ik ben volledig bekend met de materie. Zodoende heb ik enkele quotes geplaatst bij het woord tabel.

De tinned can omgeving van SAP producte is mij ook bekend. Je ziet de niets zeggende namen enkel als je op de database inprikt. Connectors of producten van derden, die minder lowlevel tonen niet de Duitse namen. Laat staan de technische tijdslijnen binnen de tabellen.