Voor elke user een nieuwe database
- Aar - op 23/09/2014 11:20:39:
Los van het feit dat hij alles in losse database opslaat, maakt mij nieuwsgierig hoe hij ze allemaal backupt. je moet je backup-script dan ook steeds aanpassen, dat hij een extra database meeneemt. Al met al... enorm omslachtig gedoe.
bijvoorbeeld met
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
#!/bin/sh
date=`date -I`
for i in /var/lib/mysql/*/; do
dbname=`basename $i`
echo $dbname
rm /backup/$dbname.sql.3
mv /backup/$dbname.sql.2 /backup/$dbname.sql.3
mv /backup/$dbname.sql.1 /backup/$dbname.sql.2
mv /backup/$dbname.sql /backup/$dbname.sql.1
/usr/bin/mysqldump -uroot -mypassowrd --host=127.0.0.1 --routines $dbname > /backup/$dbname.sql
done
date=`date -I`
for i in /var/lib/mysql/*/; do
dbname=`basename $i`
echo $dbname
rm /backup/$dbname.sql.3
mv /backup/$dbname.sql.2 /backup/$dbname.sql.3
mv /backup/$dbname.sql.1 /backup/$dbname.sql.2
mv /backup/$dbname.sql /backup/$dbname.sql.1
/usr/bin/mysqldump -uroot -mypassowrd --host=127.0.0.1 --routines $dbname > /backup/$dbname.sql
done
Joshua van den Hoonaard op 23/09/2014 12:15:21:
Heb nu in ieder geval genoeg argumenten om het anders te doen dan dat hij wenst. haha :)
Een klant moet niet gaan bepalen hoe jij het moet doen. Je kan je klant adviseren wat jou het beste lijkt en dat proberen te verkopen. Klanten bekijken een website vaak alleen vanuit de front-end en niet vanuit de back-end. Sommige denken dat ze alles erover weten, maar uiteindelijk maken ze het jou, hunzelf en nu ook ons :P wat lastig. Klant is koning, maar geen keizer. Hij wil efficientie, een goede prijs en een goed systeem. Bang dat ie data gaat verliezen? Gebruik cronjobs, of maak elk uur handmatig een backup... Ik heb zelf een VPS met ongeveer 25 databases, deze worden om de 6 uur gedumpt voor een backup.
Ozzie PHP op 23/09/2014 12:15:21:
@Ward:
Dan kun je toch ook voor die ene specifieke toepassing een EXTRA database maken?
Dan kun je toch ook voor die ene specifieke toepassing een EXTRA database maken?
Dan krijg je gedoe bij queries met JOINs over meerdere tabellen uit de applicatiespecifieke database plus de standaarddatabase. Niet doen. Je kunt voor het overzicht en het beheer beter een PREFIX_ aan tabellen meegeven met de applicatienaam, dat is de best practice.
Uiteindelijk bleek het dus zo te zijn dat de users allemaal wel in één tabel komt te staan en in één database.
Echter zullen de users een hoop gegevens invoeren, en daarvoor moet elke user een aparte database toegewezen krijgen op basis van hun klantnummer.
Dus bijvoorbeeld: user1 met klantnummer 4453, moet via een paneel toegang krijgen tot de gegevens die in de database genaamd 4453 staat.
Ook voor mij is dit nog lastig te programmeren, maar als ik er niet uitkom weet ik waar ik in ieder geval terecht kan.
In ieder geval bedankt voor al jullie reacties.
4453 zou namelijk gemakkelijk als getal gezien kunnen worden.
Bijvoorbeeld DB4453 niet.
geeft sowieso bij mij een foutmelding.
mét backtics mag je de raarste namen gebruiken, maar vergeet ze een keer en in het gunstigste geval krijg je een foutmelding.
Joshua van den Hoonaard op 24/09/2014 12:32:56:
Ik heb het er nog eens over gehad met mijn opdrachtgever.
Uiteindelijk bleek het dus zo te zijn dat de users allemaal wel in één tabel komt te staan en in één database.
Echter zullen de users een hoop gegevens invoeren, en daarvoor moet elke user een aparte database toegewezen krijgen op basis van hun klantnummer.
Uiteindelijk bleek het dus zo te zijn dat de users allemaal wel in één tabel komt te staan en in één database.
Echter zullen de users een hoop gegevens invoeren, en daarvoor moet elke user een aparte database toegewezen krijgen op basis van hun klantnummer.
Duidelijk, ik neem aan dat de users zelf hun eigen database kunnen invullen qua structuur, voor een eigen applicatie? In dat geval is het creëren van een database per user correct.
En anders moet de opdrachtgever het zelf maar weten, vind ik ;-)
Gewijzigd op 24/09/2014 15:30:45 door - Ariën -