Database verbinding(en)

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Sander Z

Sander Z

27/11/2015 10:57:32
Quote Anchor link
Ik heb gezocht op Google maar kan met de antwoorden daar alle kanten op. Dus weet ik nog steeds niet wat "best practice" is. Misschien kunnen jullie mij helpen duidelijkheid te scheppen.

Voordat je iets kunt plaatsen/lezen etc in een tabel moet je natuurlijk verbinding hebben met de database.
Maar wanneer maak je nu de verbinding en wanneer sluit je deze?

Ik kan bij het starten van een PHP pagina de verbinding maken en op het einde van de PHP deze weer sluiten. Of is het beter om deze telkens na iedere query uitvoering te sluiten en bij een nieuwe weer opnieuw verbinding te maken?

Hoe ik het nu doe:
Ikzelf gebruik als laatste stukje beveiliging verschillende rechten voor de verschillende queries.
SELECT is read.
INSERT, UPDATE etc is write.
DROP, ALTER etc is admin.
Ik start wanneer ik de EERSTE query uitvoer de verbinding met de daarbijhorende rechten. Deze verbinding sluit ik niet. Wanneer ik dan weer een query uitvoer waarvoor dezelfde rechten nodig zijn kan ik deze direct uitvoeren. Ga ik dan een query uitvoeren waarvoor andere rechten nodig zijn dan maak ik een nieuwe verbinding met de bijhorende rechten. En zo gaat dat door.
Op het einde van PHP wordt de verbinding dan uiteindelijk gesloten (__destruct)

Is dit de "juiste" methode of moet ik het toch anders aanpakken?
Gewijzigd op 27/11/2015 10:58:33 door Sander Z
 
PHP hulp

PHP hulp

14/11/2024 04:43:24
 
Ben van Velzen

Ben van Velzen

27/11/2015 11:21:34
Quote Anchor link
In de meeste gevallen is 1 databaseverbinding meer dan voldoende. In de grotere applicaties zie je nog wel eens aparte lees en schrijfverbindingen, zodat er goed gewerkt kan worden met replicatie.
 
Ivo P

Ivo P

27/11/2015 11:58:54
Quote Anchor link
ik geef de user waarmee de script connecten alleen de rechten die voor gewoon gebruik nodig zijn:
insert, update, select en delete.
Eventueel nog iets met temp-tables;

dat is doorgaans genoeg. De connectie gaat altijd met deze gebruiker.

Voor beheer van de site is er dan een andere gebruiker die bijvoorbeeld DROP, ALTER en CREATE rechten heeft om de structuur van de database aan te passen.

Ik denk dat dat voldoende beveiliging is voor de meeste situaties.
Jouw aanpak vereist volgens mij een boel overhead ivm het bijhouden of de huidige connectie wel voldoende rechten heeft om een handeling uit te voeren.
Daarbij geeft het connecten zelf ook nog eens vertraging.
 
Sander Z

Sander Z

27/11/2015 13:22:05
Quote Anchor link
@Ben:
Ik geef toch de voorkeur aan meerdere verbindingen icm de uit te voeren statement. Better safe than sorry.
Het heeft een naam maar het komt op dit neer:
Qua beveiliging: Je kunt beter alles dichtzetten en alleen toelaten wat jij ingesteld hebt. Dan het open laten staan en sluiten waarvan jij denkt dat het niet goed is. Blijkt het dat er dan toch een methode is waardoor een gebruiker kwaad kan doen dan kan hij (bij alles open) dit uitvoeren omdat jij hier nog niets tegen gedaan hebt.
Gebruik je de 1e optie (alles dicht) dan kan die gebruiker het niet uitvoeren en zul je alleen aanpassingen hoeven maken als je iets toch wilt toestaan.
De echte beschrijving/tekst is vele malen mooier en duidelijker. Maar denk dat je het idee wel begrijpt. :)


@Ivo:
Als ik zoals jij aangeeft insert, select etc samenvoeg dan heb ik inderdaad zo goed als altijd maar 1 verbinding nodig en hoeft deze tussentijds niet meer gewijzigd te worden.
Het controleren of de verbinding met de juiste rechten gemaakt is is namelijk maar 1 if statement. Denk dat het op die manier niet te veel handelingen en overhead zijn.

Thanks
Gewijzigd op 27/11/2015 13:27:30 door Sander Z
 
Ben van Velzen

Ben van Velzen

27/11/2015 14:09:39
Quote Anchor link
Ik begrijp het idee, alleen is het in mijn ogen niet heel zinvol. Het idee van Ivo is dan vele malen beter, omdat je nooit DDL hoeft te doen vanuit je applicatie. Als je dit tot in het extreme wilt doortrekken kun je ook alleen rechten geven op views en/of stored functions/procedures.
 
Thomas van den Heuvel

Thomas van den Heuvel

27/11/2015 14:58:24
Quote Anchor link
Ben van Velzen op 27/11/2015 14:09:39:
Het idee van Ivo is dan vele malen beter, omdat je nooit DDL hoeft te doen vanuit je applicatie.

Inderdaad, de structuur van je database zal in het gebruik niet vaak wijzigen lijkt mij, en als dit wel het geval is dan wordt het wellicht tijd om je architectuur eens onder de loep te nemen :).

Er spelen een aantal zaken:
Het hangt af van je applicatie
Het is onmogelijk om op voorhand te zeggen wat de beste manier is, deze bestaat simpelweg niet. Stel je applicatie omvat een forum, dan verwacht ik dat er continu read/write operaties zijn, dus dan zou ik daar geen aparte connecties voor gaan opzetten. Stel je applicatie is een blog, het "publiek" zal doorgaans enkel "lezen", te meer omdat blogs volgens mij tegenwoordig allerlei externe comment-systemen hebben (disqus of hoe het ook het). Voor je backend zou je dan een lezen/schrijven connectie kunnen hebben, en als je echt structuur wilt veranderen zou je dat nog via een database-mananger (phpMyAdmin) of prompt kunnen regelen. Zoals je wellicht ziet, er zijn legio oplossingen denkbaar (die mede bepaald worden door de aard en het gebruik van de applicatie).

Maar wat zeker belangrijk is:
Een databaseconnectie is een (zeer) dure (en beperkte) resource
Naarmate een site meer verkeer heeft wordt dit steeds belangrijker, maar het zou een streven moeten zijn om altijd zo zuinig mogelijk om te springen met je resources. Als je de keuze hebt om iets met één connectie op te lossen, of met twee, zou ik altijd gaan voor de oplossing met één.

Er zijn verschillende plekken waar je de mate van interactie met je database kunt vastleggen
Dit kan prima in de applicatielaag. Hiermee zeg ik niet dat al je connecties maar via de root-user / accounts met root privileges moeten gaan he :). Maar met een rechtensysteem die bepaalt tot welke pagina's/code/functionaliteit je toegang hebt die op zijn beurt weer bepaalt welke database-manipulaties je kunt uitvoeren is een prima valide strategie. Hierbij zul je wel wat security richtlijnen moeten volgen en voorzichtig moeten omspringen met al je (user) data. Hierbij is het ook verstandig om te werken met lagen in plaats van een single-line-of-defense tegen misbruik.
Gewijzigd op 27/11/2015 15:03:39 door Thomas van den Heuvel
 
Sander Z

Sander Z

27/11/2015 15:34:28
Quote Anchor link
Check! Ik begrijp het...

Dank voor alle antwoorden!
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.