[PHP] - limit insert in mysql DB op basis van eerdere query

[Blomminator]

Even een vraag waar ik niet van weet hoe ik het moet benaderen.
Ik heb een DB met 4 tabellen.
- land
- stad
- locatie
- route

Stel, je hebt een route om af te vinken, dan wil je die opslaan.
Dan kan ik alles wel opslaan, dat is oké. Maar ik wil voorkomen dat iemand een stad gaat opslaan in een ander land. Dat kan natuurlijk niet..

Maar kun je dan bij een insert ook een JOIN ofzo doen, of in welke hoek moet ik dit denken?

ligt in het verlengde van dit eerdere topic;
DB / Query logica op schaalbaarheid


Alvast bedankt !

[armageddon_2k1]

Tja, is een lastige vraag die je stelt, want je hebt het eigenlijk over domein logica tijdens het inserten in de DB, wat ik zelf niet prettig vind. Het probleem is echter dat het niet altijd vast staat tot welk land een stad behoort (Sebastopol of, dichter bij huis, Baarle).

Ik zou, om flexibiliteit te behouden, dat soort dingen altijd in de laag voordat je naar je DB gaat doen. Een DB is, voor mij, sec een opslag, waar de logica erachter in de applicatie eromheen zit. Dus ik zal niet snel de logica af proberen te vangen in je query, maar juist al daarvoor. Dat is bij jou dus in je PHP code voordat je naar de DB schrijft.

Dan hou je dus alle logica van wat wel en niet mag in 1 laag en is het andere puur waar het voor bedoelt is... opslag. Anders, een paar jaar verder, knalt je applicatie opeens met een error code en debug je je suf omdat je logica op meerdere plekken hebt liggen.

- Domein logica voordat je op gaat slaan in je DB
- DB logica (dubbele ID's, missing constraints etc) in je DB

Op die manier handelt elke service z'n respectievelijk stuk af. Google voor de lol maar eens naar Layered Architecture.

Waarom zouden mensen zomaar steden op kunnen slaan trouwens? Dat betekent dat je ook gewoon steden zou kunnen toevoegen die niet bestaan?

[ Voor 28% gewijzigd door armageddon_2k1 op 03-12-2019 17:49 ]

[Blomminator]

Thnx voor de gedachtegang!


Ik heb nu een query die alle landen, steden, locaties en routes ophaalt. Zodat je kunt opslaan.
Maar ik krijg nu de volgende gedachte gang. (maar daar ontbreekt mijn kennis voor... helaas).

Stel je wilt een route in Belgie afvinken. Dan selecteer je EERST belgie, en DAN laadt het script pas alle Belgische Steden. Na selectie worden alle bijbehorende locaties geladen, en tot slot alle routes.
Dan is het keurig opgelost.

Alleen is dat via php niet echt handig, want dan moet je - voor zover ik weet - elke keer submitten, verwerken, presenteren. Liever via "Lazy Loading / ajax". Maar ik ben developer met NUL ervaring.. dus dit is een vingeroefening om eea gaande te krijgen, in de hoop ervaring op te maken, en later werk er in.

Wat ik bijvoorbeeld ook merk in de queries. Ik wil liever 1 lange query en dan enkele velden presenteren maar dat lukt vooralsnog niet. Dus dan maar 3 queries.. maar goed, da's niet zo chic.

Iemand nog behoefte aan een gezellige stagiair PHP developer regio Utrecht!? HBO Communicatie & Multimedia gedaan, kan t een beetje maar zoek werkervaring...


Landen/Steden etc zelf aanmaken kan nu iedereen maar in de toekomst alleen "SuperUsers"

[armageddon_2k1]

Wat je zegt dat het niet handig is in PHP zie je toch verkeerd :-)
Een paar goeie queries zijn bloedsnel en een PHP genereert bloedsnel een pagina.

Dus op zich is de simpele oplossing prima:
- query data
- verwerk data
- presenteer resultaat
- verwerk input

Daar kan je makkelijk 90% van alle zinnige use-cases mee dekken. Ik zou niet snel naar lazy-loading/AJAX/React en al dat soort dingen grijpen als het gewoon zo simpel kan

Onderschat de power van een DB niet.

Dus dan maar 3 queries.. maar goed, da's niet zo chic.

3 aparte queries zijn leesbaarder als ontwikkelaar dan 1 mega....

Probeer niet te optimaliseren voor een probleem dat er misschien helemaal niet is. Optimaliseren is fokking moeilijk en een juiste architectuur verzinnen ook. Begin dus klein en simpel en als je tegen grenzen aanloopt is de kans groot dat je weet waarom.

[ Voor 29% gewijzigd door armageddon_2k1 op 03-12-2019 18:10 ]

[Blomminator]

Ohja, ik ga geen ajax of iets erbij proberen. Heb mijn handen hier al vol aan. En soms kom ik best een heel eind, maar tegelijk voel je dat dingen sneller/mooier kunnen, maar ja, ga dat eens in je eentje bedenken aan de keukentafel.

Vandaag de gedachte eens stage te lopen ergens. Ik heb tijd zat, en dan leer je denk ik vrij veel snel in de praktijk.

Maar goed, ik zal kijken of ik dit met een query kan maken. Het is vast mogelijk maar de vraag is vooral.. kan ik het.

Wordt vervolgd!

Nb; Moest net hardop lachen over je Signature! TOP!

[EvilWhiteDragon]

@armageddon_2k1, Ik ben het op zich met je stelling eens dat je niet onnodig moet optimaliseren. Waar ik het niet mee eens ben is er dus maar 3 queries van maken omdat dat beter leesbaar is. Denk bij dit soort data opvragingen ook aan stored procedures en views in de database. Zo hoef je ook niet onnodig data uit de database te trekken om te verwerken. Daarnaast is ook dat goed onderhoudbaar te maken, al moet je er misschien 3 minuten langer over nadenken (DB source control, naamgeving etc.).

Teruglezend komt dit wat belerender over dan de bedoeling is

Bonus:
Ingewikkelde queries zou ik bij voorkeur in de database opslaan, om de code leesbaar te houden en zodat de database er execution plans voor maakt en bewaard. Kleine moeite en wel zo efficiënt en netjes.

[ Voor 16% gewijzigd door EvilWhiteDragon op 03-12-2019 18:38 ]

[Blomminator]

In the meantime...

SELECT route.location, route.segment, route.routename, location.country FROM route JOIN location ON route.location = location.name

Met deze query heb ik in 1x alle info die ik nodig. Alle landen, alle locaties, alle segmenten én alle routes.

En dan in een tabel presenteren, zodat de "waardes" die bij elkaar horen bij elkaar staan...

Country

Location

Segment

Routes

CHECK/UNCHECK

Dan is het presenteren een stuk mooier opgelost dan 3 x query draaien.

En dan maak ik dit alles in 1 formulier en alle AANGEVINKTE waardes kunnnen worden bijgewerkt in de DB. Dan zoek ik de route op, en markeer die als geklommen, en dan is het dikke prima.
Denk ik... nog steeds Theorie!

[Blomminator]

@EvilWhiteDragon

Ingewikkelde queries zou ik bij voorkeur in de database opslaan, om de code leesbaar te houden en zodat de database er execution plans voor maakt en bewaard. Kleine moeite en wel zo efficiënt en netjes.

Eh? Opslaan in de DB? Ik sla nu alleen DATA op in de DB, en met php haal ik die data op, verwerk en stop er weer in terug.

Hoe kun je een query opslaan?
Bedoel je een aparte tabel, met complexe queries? En dan zeggen
"Select query1 from queries"
En dat die dan wordt verwerkt op de pagina?

[Sandor_Clegane]

Blomminator schreef op dinsdag 3 december 2019 @ 18:57:
@EvilWhiteDragon

[...]


Eh? Opslaan in de DB? Ik sla nu alleen DATA op in de DB, en met php haal ik die data op, verwerk en stop er weer in terug.

Hoe kun je een query opslaan?
Bedoel je een aparte tabel, met complexe queries? En dan zeggen
"Select query1 from queries"
En dat die dan wordt verwerkt op de pagina?

Hij heeft het over stored procedures met parameters. Deze "leven" in de database en worden aangeroepen door je code, Doordat ze leven in de DB kan deze slimme trucjes uithalen om ze te optimaliseren.

Voor je vraag: dit soort dingen vallen onder validatie van de input. En dit is "business logica" en deze kun je in je DB afdwingen met allerlei constraints maar je kunt ze ook in je applicatie code afhandelen.

Voor beide zijn er voors en tegens.

[EvilWhiteDragon]

Blomminator schreef op dinsdag 3 december 2019 @ 18:57:
@EvilWhiteDragon

[...]


Eh? Opslaan in de DB? Ik sla nu alleen DATA op in de DB, en met php haal ik die data op, verwerk en stop er weer in terug.

Hoe kun je een query opslaan?
Bedoel je een aparte tabel, met complexe queries? En dan zeggen
"Select query1 from queries"
En dat die dan wordt verwerkt op de pagina?

Opslaan is misschien wat onhandig geformuleerd. Ik bedoelde in de vorm van stored procedures en views. Daarmee kan je stukken logica in de database plaatsen.

[Blomminator]

Inmiddels weer een tijd verder en ik sukkel rustig door. Ik ben even van php afgestapt om de mysql/phpmyadmin weer een te scherpen. Kwartjes vallen weer langzaam.

Het is nu genormaliseerd, en ik heb een aantal constraintst ingesteld. Dat lijkt goed te werken.

1 ding waar ik nu over twijfel (het werkt wel, maar wat ik mooier...?) ;
Ik heb 4 tabellen:
1) Route
2) Segment
3) Stad
4) Land

En ik heb in Route aangegeven in welk Segment deze ligt. En in Segment, in welke Stad dit ligt. En in Stad in welk land deze ligt.

Zo kan ik alle data mooi herleiden.

Lijkt mij mooi, maar hoor graag als het anders mooier/beter is.