Hoster, via php databases aanmaken (php bepaalt de naam)

[Zonnetje83]

Mijn vraag:
Ik heb lokaal een flinke website / applicatie ontwikkeld en ben daar nog mee bezig, die elke klant die wij krijgen een eigen database geeft.
Werkt via php en deze maakt middels mysql commando's bij elke nieuwe aanmelding een nieuwe database aan met een eigen naam .

Om deze tijdelijk tijdens de ontwikkeling voor een andere persoon te ontsluiten heb ik bij strato een klein hostingpakket afgenomen (zie hieronder). Nu blijkt (info kon ik eerder nergens vinden) dat deze de databases zelf aanmaakt en dat volgens een door hen gedicteerde benaming doet.

Ik kan dus kennelijk niet zelf de benaming kiezen (of ik moet verkeerd lezen). Ben nog aan het mailen met Strato, maar daar gaat tijd overheen.

In de tussentijd, is hetgeen ik vraag zo'n aparte vraag? of had ik bij een andere hoster een pakket af moeten nemen? De uiteindelijke site zal, zodra hij klaar is, een paar duizend databases (klanten) moeten kunnen handlen, ook weer met door ons zelf bedachte namen.

Zie ik iets over het hoofd, is mijn idee van één database per klant niet juist/handig of moet ik een andere hoster zien te vinden (en hebben jullie tips?)?

Het gaat er dus om dat ik dus databases met eigen naam via php / Mysql aan wil kunnen maken.


Relevante software en hardware die ik gebruik
Strato PowerWeb Basic
(https://www.strato.nl/hosting/)
PHP, Mysql, jQuery etc.


Wat ik al gevonden of geprobeerd heb
Strato dus, lijkt niet handig.
Flink gegoogeld, weinig gevonden.
TransIP lijkt bijv. wél toe te staan dat je de naam zelf kiest, maar tot nu toe zie ik alleen dat dat kan via een webinterface, terwijl ik dat juist via php van mijn site zelf wil laten doen.

[Croga]

Ik verwacht dat bij Strato alle klanten op dezelfde MySQL instance zitten. En ja, dan bepaalt de hoster dus de naam van de database. Dat is niet heel erg raar. Maar ja, wat verwacht je voor €1 per maand?

Ik draai zelf op een SimpleHosting account van Gandi voor €8 per maand en daar heb ik een eigen MySQL instance. Met als gevolg dat ik zelf bepaal hoe mijn databases en accounts heten. Daar hebben ze slechts het geheugen, de CPU en de opslag beperkt waardoor het dus ook niet meer uit maakt.

Of je oplossing handig is kan ik niet zeggen. Dat ligt heel erg aan de applicatie. Het is in ieder geval niet veel gebruikt; meestal heb je óf één PHP applicatie waarbij wellicht per klant een tabel aan gemaakt wordt (maar meestal dat niet eens) óf voor iedere klant een aparte instance van de applicatie die dan ook zijn eigen database heeft. Maar ik heb je applicatie niet ontwikkeld dus ik kan niet zeggen of in jouw geval de keuze wellicht de juiste is.

[AW_Bos]

Je kan Strato vragen of ze een API bieden zodat je zelf je hostingplatform kan uitbreiden met extra databases. Dan kan je in een handomdraai van uit je eigen script, en in een vlotte flow een heel platform klaar maken voor je klant, met de database erbij.

Ik weet dat Plesk en DirectAdmin als hostingpanels (als de hostingpartijen dat aanbieden) sowieso een API hebben.

[REDSD]

Strato is niet de juiste hosting voor de oplossing inderdaad, een eigen server of een server waar je een mysql gebruiker kan aanmaken met genoeg rechten om databases aan te maken is wat je nodig hebt.

Een aparte database per klant kan slim zijn, het verkleint de kans dat gegevens van andere klanten zichtbaar worden door bugs.

[mamorunl]

AW_Bos schreef op maandag 13 april 2020 @ 22:10:
Je kan Strato vragen of ze een API bieden zodat je zelf je hostingplatform kan uitbreiden met extra databases. Dan kan je in een handomdraai van uit je eigen script, en in een vlotte flow een heel platform klaar maken voor je klant, met de database erbij.

Ik weet dat Plesk en DirectAdmin als hostingpanels (als de hostingpartijen dat aanbieden) sowieso een API hebben.

Klopt, maar ook die (DirectAdmin in ieder geval - Plesk geen ervaring mee) dicteren nog half een eigen naam, namelijk de userid_<dbname>. Het zit dichterbij, maar misschien nog niet helemaal wat je zoekt.

[AW_Bos]

Dat is wel weer zo, maar waarom moet het een eigen naam zijn? Wat is er mis met een prefix?
Anders moet je maar een eigen LAMP-stack bouwen, vrees ik, omdat je op een shared hosting toch een prefix nodig moet hebben om de databases van andere klanten uit elkaar te houden.

[ Voor 3% gewijzigd door AW_Bos op 13-04-2020 22:14 ]

[Croga]

AW_Bos schreef op maandag 13 april 2020 @ 22:14:
Anders moet je maar een eigen LAMP-stack bouwen, vrees ik, omdat je op een shared hosting toch een prefix nodig moet hebben om de databases van andere klanten uit elkaar te houden.

Mwah... Er zit nog wel heel veel tussen shared hosting en een eigen LAMP stack..... Zoals al gemeld doet Gandi dat met SimpleHosting (wat in feite een managed VPS is), dan heb je nog managed dedicated hosting, normale VPS en vast nog heel veel andere opties.

En als ik het zo bekijk is Strato zelfs nog best behoorlijk duur.... Voor hetzelfde geld heb je een simpel hosting bij Gandi waar je veel meer controle over hebt.

[DJMaze]

REDSD schreef op maandag 13 april 2020 @ 22:12:
Aparte database per klant kan slim zijn, het verkleint de kans dat gegevens van andere klanten zichtbaar worden door bugs.

Neen, hij draait één php script.
Hij zou dan alles apart moeten uitrollen per unix user + php-fpm instance + mariadb unix_socket authentication.
Anders kan een bug alsnog alle mysql login configuraties lezen.

Stop je php scripts in /usr/share/php/, dan kan je centrale opcache klein blijven.
1000'en klanten doe je niet ff zomaar, er klopt iets niet in de basis van het verhaal, en dat is niet het woord "database".

[ Voor 19% gewijzigd door DJMaze op 13-04-2020 22:53 ]

[REDSD]

DJMaze schreef op maandag 13 april 2020 @ 22:47:
[...]

Neen, hij draait één php script.
Hij zou dan alles apart moeten uitrollen per unix user + php-fpm instance + mariadb unix_socket authentication.
Anders kan een bug alsnog alle mysql login configuraties lezen.

Stop je php scripts in /usr/share/php/, dan kan je centrale opcache klein blijven.
1000'en klanten doe je niet ff zomaar, er klopt iets niet in de basis van het verhaal, en dat is niet het woord "database".

True, maar dan nog verkleint het de kans, omdat er maar op 1 punt in de code bepaald hoeft te worden welke database aangesproken moet worden.

[Zonnetje83]

Bedankt iedereen voor de reacties!

Omdat ik tijdelijk de website (achter een inlog) voor een medewerker online wil hebben, dacht ik bij strato wel een tijdelijke, redelijke oplossing te gaan hebben. vandaar dat ik ook voor een relatief goedkoop abo gekozen heb en ik heb specifiek opgelet dat er meerdere Mysql database mogelijk waren, naast andere zaken.
Wat ik niet wist is dat de databases dus door hen gemanaged en genaamd worden en dat staat dus haaks op onze werkwijze. Ik zal een tijdelijke work-around maken zodat eea toch via Strato gaat werken, in de tussentijd ontwikkel ik natuurlijk op mijn lokale omgeving.

@DJMaze: ik snap niet wat je bedoelt met ''er klopt iets niet in de basis van het verhaal". Ik hoop juist op meedenken of dit wel the way to go is.

Het gaat in essentie om max een paar duizend klanten en dus databases, geen miljoenen o.i.d. . Ik heb ondertussen via Googlen nog wat sites en antwoorden gevonden, waarbij voors en tegens genoemd worden.
Dus dat helpt ook.

@Croga : bedankt voor je input / reactie. Sowieso gaat het hier om een tijdelijke oplossing voor een paar maanden en dus niet om de uiteindelijke commercieel open staande site, dus ik neem jouw opmerkingen mee richting live-datum, thanks.

[DJMaze]

Zonnetje83 schreef op dinsdag 14 april 2020 @ 14:37:
ik snap niet wat je bedoelt met ''er klopt iets niet in de basis van het verhaal". Ik hoop juist op meedenken of dit wel the way to go is.

Heb je de rest van mijn reactie op REDSD zijn post wel begrepen?
En dat is nog niet eens het grootste probleem.

REDSD kaart terecht de implicaties van een lek aan.
Echter is CREATE DATABASE een query waarvoor je hele specifieke rechten nodig hebt.
Men zou, in theorie, bij een lek dus ook DROP ALL DATABASES kunnen uitvoeren op de SQL connectie.

Als je niet helemaal begrijpt waarom hosting providers dit dus niet voor niks afschermen, dan moet je je nog even achter je oren krabben en in je code duiken of die wel zo veilig is.

[CodeCaster]

Wat DJMaze bedoelt: is een database-per-klant wel de oplossing die je zoekt? Waarom wil je dit? Kun je énige context geven over wat je applicatie biedt, en wat een "klant" precies inhoudt en kan in deze applicatie?

Want als je echt per user, per login, een aparte database optuigt met exact dezelfde structuur als alle andere users, waarom hebben je tabellen dan niet gewoon een UserId-kolom, waarin je de "eigenaar" van het record opslaat?

DJMaze schreef op dinsdag 14 april 2020 @ 15:36:
[...]
REDSD kaart terecht de implicaties van een lek aan.
Echter is CREATE DATABASE een query waarvoor je hele specifieke rechten nodig hebt.
Men zou, in theorie, bij een lek dus ook DROP ALL DATABASES kunnen uitvoeren op de SQL connectie.

Het kan natuurlijk dat de registratiepagina een eigen SQL-login heeft, dat die een gebruikersrecord in een centrale tabel aanmaakt, en daarbij de credentials genereert en opslaat voor de database voor die gebruiker. En dat de gebruiker, na een login, met zijn eigen database verbindt met zijn eigen credentials.

Maar de grote vraag blijft: waarom zou je dat doen?

[DJMaze]

CodeCaster schreef op dinsdag 14 april 2020 @ 15:46:
waarom hebben je tabellen dan niet gewoon een UserId-kolom, waarin je de "eigenaar" van het record opslaat?

Omdat je dan overal je PHP code moet aanpassen om te zorgen dat UserId 1 niet de dingen van UserId 2 kan lezen/aanpassen/etc.
Dat zou dus betekenen dat hij van 0 weer zijn programma moet ontwikkelen.

Zoals ik al zei: het probleem is niet de database

Ik heb hier ergens een enkele database setup (dus het UserId model zegmaar) en bij een DB upgrade/aanpassing:

• 1 database te upgraden
• een recreate table duurt lang door de 1.000.000'en records
• db stuk = iedereen stuk

Ik heb hier ergens een multi database setup (dus geen UserId model zegmaar) en bij een DB upgrade/aanpassing:

• veel databases te upgraden
• geen recreate table die minuten/uren duurt
• db stuk = niet iedereen stuk

Het is maar waar je voor kiest (Aria, MyISAM, InnoDB, NDB, MyRocks, TokuDB, etc.).

[ Voor 38% gewijzigd door DJMaze op 14-04-2020 16:24 ]

[Zonnetje83]

Het kan natuurlijk dat de registratiepagina een eigen SQL-login heeft, dat die een gebruikersrecord in een centrale tabel aanmaakt, en daarbij de credentials genereert en opslaat voor de database voor die gebruiker. En dat de gebruiker, na een login, met zijn eigen database verbindt met zijn eigen credentials.

Maar de grote vraag blijft: waarom zou je dat doen?

Dit is precies zoals in het opgebouwd heb. De één database met userID in elke table had ik als eerst opzet, maar met name de veiligheid dat iedereen zijn eigen database heeft en dus niet de gegevens van een ander mogelijkerwijze in kan zien (door een verkeerde query o.i.d.), of bijv versiebeheer/ maatwerk per klant is dit idee ontstaan.

Ik hoopte op advies en natuurlijk mag ik op zaken gewezen worden die ik wellicht anders had moeten of nog kan doen, maar Sommige berichten komen erg belerend of kleinerend op mij over. Misschien niet zo bedoeld, het is getypt en soms lees je dat verkeerd, maar toch, het voelt niet heel welkom.

Daar bedoel ik overigens jouw reacties niet mee.

Hoe dan ook, ik claim niet dat ik de wijsheid in pacht heb en dat is juist waarom ik naar advies vraag.

Ik besefte me sowieso nog voor deze vraag terdege dat ik vóór live gang een specialist in de arm moet nemen.

Mocht daaruit idd komen dat er toch een userID kolom i.p.v. aparte databases moet komen, dan is dat gezien hoe eea nu gebouwd word ook nog wel te doen. Veiligheid, performance en beheersbaarheid voorop.

[DJMaze]

@Zonnetje83 gescheiden databases is prima. Als eentje groot wordt, zet je die op een eigen VPS.
Dan moet je admin script dus wel kunnen kiezen op welke server je een account zet.
Je zou dan ook kunnen kiezen voor een Percona/Galera HA cluster, of de logins van iedereen wel in een centraal systeem (SSO, hoeft niet DB te zijn).

Maar dat is allemaal voor latere zorg.
Zet gewoon een goedkope VPS online en je kan alle kanten op.

[Josk79]

Zonnetje83 schreef op maandag 13 april 2020 @ 21:59:
Mijn vraag:
Zie ik iets over het hoofd, is mijn idee van één database per klant niet juist/handig of moet ik een andere hoster zien te vinden (en hebben jullie tips?)?

Het gaat er dus om dat ik dus databases met eigen naam via php / Mysql aan wil kunnen maken.

Of jou systeem handig is hangt van je toepassing af.

Of het veilig is hangt van je implementatie af. Indien bijv. eerst credentials van een klant worden opgezocht in een tabel in een centrale database waarin alle credentials staan kan bij een lek in dat gedeelte iemand mogelijk toch bij de data van alle klanten komen, bijv...

[Zonnetje83]

Beste iedereen,

Ik ben ondertussen bij Strato weg en ik heb o.a. Gandi (op aanraden van @Croga ) en antagonist benadert.

De laatste geeft aan dat zelf een 'create database' via een php script uitvoeren niet mogelijk is - je moet dat handmatig via het DirectAdmin panel doen. Van Gandi krijg ik tot op heden geen antwoord.

Heeft iemand hints of tips waar ik nog meer zou kunnen kijken? Of dat Gandi bijv. dit wel toestaat?
Of moet ik naar een vps gaan kijken? Op dit moment nog liever niet, want we zitten nog in de testfase. Later kan dat uiteraard wel.

De hele opzet zoals deze nu is is dat ik niet telkens voor elke klant handmatig een database aan moet gaan maken, maar dat mijn php-script gewoon een 'create database' voor me doet.

[ewoutw]

Zonnetje83 schreef op vrijdag 8 mei 2020 @ 10:59:
...

De hele opzet zoals deze nu is is dat ik niet telkens voor elke klant handmatig een database aan moet gaan maken, maar dat mijn php-script gewoon een 'create database' voor me doet.

Ik ken persoonlijk geen hosters die dit toestaan (van de meeste weet ik het simpel niet). Beperkingen waren voor mij de reden om mijn eigen sites te gaan hosten. Maar deze beperking is vanuit hosters wel logies en begrijpelijk.

Er zullen ongetwijfeld hosters zijn die dit wel doen maar die zullen wat aan de duurdere kant zijn. Ik begrijp dat het alleen voor een simpele test is en niet de de omgeving waar die uit eindelijk gaat draaien.

Ik zelf zou voor de test omgeving zelf iets hosten. Dat kan een simpele WAMP zijn. 5 min en je bent up en running. Maar ook een RaspbarryPi of een synology-nas zouden prima voor kunnen zijn.

[ Voor 4% gewijzigd door ewoutw op 08-05-2020 11:26 ]

[Zonnetje83]

ewoutw schreef op vrijdag 8 mei 2020 @ 11:24:
[...]

...
Ik zelf zou voor de test omgeving zelf iets hosten. Dat kan een simpele WAMP zijn. 5 min en je bent up en running. Maar ook een RaspbarryPi of een synology-nas zouden prima voor kunnen zijn.

Bedankt voor je antwoord en advies!

Ik draai al tijden Mamp (op een Mac) en dat gaat prima. Maar dat is voor mij hier in huis natuurlijk. Als we hier werken werkt dat uitstekend. Maar als we remote werken, dus niet.

Op mijn Synology NAS zou het inderdaad ook kunnen, maar ik ben om eerlijk te zijn huiverig om dat te doen omdat ik in de logs van mijn router zie dat er elke 5 seconden geprobeerd wordt om bij ons binnen te komen. Als ik een whois o.i.d. doe dan zijn dat een stuk of 10-20 IP's die uit Rusland, Brazilië en dat soort landen komen.

Het voelt daarom niet goed voor me om poorten open te gaan zetten....

Ik ga binnenkort naar een andere provider dus zal het dan wel over zijn, maar voor nu voelt het niet goed.

Daarom dacht ik: ik zoek een poster en klaar zijn we. Maar dat blijkt toch lastiger te zijn dan gedacht. En ik zie het om een aantal redenen niet zitten om alle klanten in één grote database te plaatsen.

[Rannasha]

Zonnetje83 schreef op vrijdag 8 mei 2020 @ 11:31:
[...]

Op mijn Synology NAS zou het inderdaad ook kunnen, maar ik ben om eerlijk te zijn huiverig om dat te doen omdat ik in de logs van mijn router zie dat er elke 5 seconden geprobeerd wordt om bij ons binnen te komen. Als ik een whois o.i.d. doe dan zijn dat een stuk of 10-20 IP's die uit Rusland, Brazilië en dat soort landen komen.

Het voelt daarom niet goed voor me om poorten open te gaan zetten....

Ik ga binnenkort naar een andere provider dus zal het dan wel over zijn, maar voor nu voelt het niet goed.

Dat soort poortscans zullen niet weg zijn als je naar een andere provider overstapt. Daar zal iedereen last van hebben, zeker als je open poorten hebt. Dit moet je simpelweg afvangen met goede beveiliging.

[RangedNeedles]

Op dit moment nog liever niet, want we zitten nog in de testfase. Later kan dat uiteraard wel.

FWIW, ik zou gewoon voor een VPS gaan. Ik weet dat je in de testfase zit maar ik zit bijvoorbeeld bij DigitalOcean en daar heb je letterlijk in minuten een VPS (droplet) die je $5 per maand kost. Zelfs in een testfase is $5 echt peanuts.

[emnich]

@Zonnetje83 Je bent nu al een tijd verder dan het begin van het topic maar heb je de voor- en nadelen van een aparte DB's vs gedeelde DB's nu helder zodat je een goede afweging hebt gemaakt?

[Zonnetje83]

emnich schreef op vrijdag 8 mei 2020 @ 12:00:
@Zonnetje83 Je bent nu al een tijd verder dan het begin van het topic maar heb je de voor- en nadelen van een aparte DB's vs gedeelde DB's nu helder zodat je een goede afweging hebt gemaakt?

Dat denk ik wel, alhoewel ik ook wel weet dat ik niet alle aspecten helder kan krijgen omdat ik geen expert ben. Gezien de usecase die we hebben lijkt het het beste om voor iedere klant een aparte database te hebben.

[Zonnetje83]

SanderL schreef op vrijdag 8 mei 2020 @ 11:42:
[...]

FWIW, ik zou gewoon voor een VPS gaan. Ik weet dat je in de testfase zit maar ik zit bijvoorbeeld bij DigitalOcean en daar heb je letterlijk in minuten een VPS (droplet) die je $5 per maand kost. Zelfs in een testfase is $5 echt peanuts.

Het gaat me ook niet om het geld, een paar euro paar maand puur voor het testen denk ik niet over na. al kost het in die periode 10-15 euro. Later, als het serieus gaat draaien, dan zullen de kosten serieus hoger eigen.

Ik heb al het nodige gelezen over een VPS. Feitelijk heb ik dat jaaaren geleden (jaja, vrij oude knar hier ) ook al eens gehad. Tenminste, dat denk ik. Je krijgt dan van hen, afhankelijk van wat je afspreekt/afneemt een virtuele of zelfs dedicated server, die je zelf vervolgens inricht? Meestal een linux-OS erop en inrichten maar.

[Zonnetje83]

Rannasha schreef op vrijdag 8 mei 2020 @ 11:41:
[...]


Dat soort poortscans zullen niet weg zijn als je naar een andere provider overstapt. Daar zal iedereen last van hebben, zeker als je open poorten hebt. Dit moet je simpelweg afvangen met goede beveiliging.

Snap ik, maar zoveel als het er nu zijn dat is bizar. elke 3 seconden al een paar maanden onafgebroken. Geen idee waarom ineens, nooit gehad.