Voor elke user een nieuwe database
Ik ben nog vrijwel een beginner in PHP, en moet voor mijn stage een opdracht doen.
Ik moet namelijk een beveiligde omgeving maken, wat uiteindelijk al aardig gelukt is, maar deze moet ik nu verder gaan uitbreiden.
Nu zit ik met een klein probleempje.
Het maken van accounts maken werkt, en dat door te voegen in de database in tables.
Echter wil mijn opdrachtgever nu dat er voor elke user automatisch een nieuwe database wordt aangemaakt met bepaalde tables, alleen weet ik niet precies hoe ik dit voor elkaar krijg, welke PHP code en queries ik daarvoor moet gebruiken.
Het moet namelijk gewoon een registratie form zijn om een account aan te maken, en bij het aanmaken van een account moet er dus een nieuwe database komen.
Ik weet van mezelf dat dit niet echt efficient is, maar mijn opdrachtgever wil dit meer uit voorzorg.
Stel de boel crasht, dat dan niet de hele database verloren gaat, maar misschien maar een bepaalde user.
Zou iemand mij hiermee een beetje op de juiste weg willen helpen?
Alvast bedankt!
- Aar - op 23/09/2014 10:09:08:
Vreemd idee om voor elke user een nieuwe database te maken. Je kan de data prima in een enkele database opslaan. Gewoon even kijken naar 'Databasenormalisatie'.
Bedankt voor je reactie.
Echter wil hij het zo, en niet anders.
Hij zegt dat hij het ook zo doet bij zijn eigen gemaakte systeem.
Ik vind het zelf overigens ook wel ver gezocht hoor, maargoed, hij wil het.
Gewoon mee om de tafel zitten en vertellen dat 1543 databases onderhouden veel lastiger én vooral duurder is dan een enkele. Wat nu als je een extra veld wilt maken per user?
Gewijzigd op 23/09/2014 10:19:56 door - Ariën -
- Aar - op 23/09/2014 10:19:10:
Altijd leuk, opdrachtgevers zonder kennis die het beter denken te weten ;-)
Gewoon mee om de tafel zitten en vertellen dat 1543 databases onderhouden veel lastiger én vooral duurder is dan een enkele. Wat nu als je een extra veld wilt maken per user?
Gewoon mee om de tafel zitten en vertellen dat 1543 databases onderhouden veel lastiger én vooral duurder is dan een enkele. Wat nu als je een extra veld wilt maken per user?
Naja je kan zeggen wat je wil hoor, maar kennis heeft hij echt wel.
Maar ik geef je gelijk hoor! Ik zou het zelf ook nooit doen.
Maar helaas moet het nu eenmaal.
Zet een kostenberekening neer voor het aanpassen van 1 veld met tijdsduur en doe dit maal 1257 databases, wat je steeds dus dan moet herhalen.
Dan moet hij vast wel omgaan...
Gewijzigd op 23/09/2014 10:30:57 door - Ariën -
- Aar - op 23/09/2014 10:28:28:
Overtuigen....
Zet een kostenberekening neer voor het aanpassen van 1 veld met tijdsduur en doe dit maal 1257 databases, wat je steeds dus dan moet herhalen.
Dan moet hij vast wel omgaan...
Zet een kostenberekening neer voor het aanpassen van 1 veld met tijdsduur en doe dit maal 1257 databases, wat je steeds dus dan moet herhalen.
Dan moet hij vast wel omgaan...
Kan het nog eens proberen hem over te halen ja.
Had ik al eens eerder geprobeerd, maar hij wou het toch graag in losse databases.
Ik vraag me dan ook inderdaad af hoe hij dat doet met zijn systeem (Die volop in gebruik is door erg grote bedrijven).
Maar los van de wenselijkheid...
Je kunt een SQL-tekstbestand maken met meerdere CREATE TABLE-queries. Die hoef je niet allemaal zelf te schrijven: je kunt bijvoorbeeld met phpMyAdmin een lege model/standaard-database met een "master" exporteren naar een .sql-tekstbestand.
Daarnaast schrijf je een klein installatiescript dat een query met CREATE DATABASE kan uitvoeren en vervolgens het .sql-tekstbestand met de CREATE TABLE-queries inleest en uitvoert.
Verder goed letten op de rechten: klanten mogen vervolgens niet zelf een CREATE DATABASE kunnen uitvoeren; dat recht is voorbehouden aan je "installer". Geef die bij voorkeur een eigen account op de databaseserver.
Ward van der Put op 23/09/2014 11:11:46:
Technisch kan het zinvol zijn als je bijvoorbeeld klanten wilt kunnen laten verhuizen/vertrekken met alleen hun database. Anders moet je ingewikkeld gaan doen met het lostrekken en verwijderen van die data uit de data van alle andere klanten.
Maar los van de wenselijkheid...
Je kunt een SQL-tekstbestand maken met meerdere CREATE TABLE-queries. Die hoef je niet allemaal zelf te schrijven: je kunt bijvoorbeeld met phpMyAdmin een lege model/standaard-database met een "master" exporteren naar een .sql-tekstbestand.
Daarnaast schrijf je een klein installatiescript dat een query met CREATE DATABASE kan uitvoeren en vervolgens het .sql-tekstbestand met de CREATE TABLE-queries inleest en uitvoert.
Verder goed letten op de rechten: klanten mogen vervolgens niet zelf een CREATE DATABASE kunnen uitvoeren; dat recht is voorbehouden aan je "installer". Geef die bij voorkeur een eigen account op de databaseserver.
Maar los van de wenselijkheid...
Je kunt een SQL-tekstbestand maken met meerdere CREATE TABLE-queries. Die hoef je niet allemaal zelf te schrijven: je kunt bijvoorbeeld met phpMyAdmin een lege model/standaard-database met een "master" exporteren naar een .sql-tekstbestand.
Daarnaast schrijf je een klein installatiescript dat een query met CREATE DATABASE kan uitvoeren en vervolgens het .sql-tekstbestand met de CREATE TABLE-queries inleest en uitvoert.
Verder goed letten op de rechten: klanten mogen vervolgens niet zelf een CREATE DATABASE kunnen uitvoeren; dat recht is voorbehouden aan je "installer". Geef die bij voorkeur een eigen account op de databaseserver.
Bedankt :)
Voor mij is het nog (zelfs met jouw uitleg) erg lastig, maar ik zal proberen er wat mee te doen :)
Ik zie mij niet bij verzekeraar X weggaan, en de database met al mijn gegevens overbrengen naar verzakeraar Y. Dus in dit geval omdat het voor het opslaan van leden is, zou ik kiezen om een enkele database te gebruiken.
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.
Beste is om hem over de streep te trekken, laat de ITérs maar beslissen over een goede structuur i.p.v. iemand die het beter denkt te weten.
Gewijzigd op 23/09/2014 11:22:32 door - Ariën -
- Aar - op 23/09/2014 11:20:39:
Het ligt er aan waarvoor de database gebruikt worden. Als de gebruikers zelf eigen beheer hebben over de indeling, zoals bij een een webhosting, dan kan ik Ward's argument goed indenken. Maar als elke databases een vaste indeling en opbouw hebben, een administratiesysteem dus, dan gaat dit niet op.
Ik zie mij niet bij verzekeraar X weggaan, en de database met al mijn gegevens overbrengen naar verzakeraar Y. Dus in dit geval omdat het voor het opslaan van leden is, zou ik kiezen om een enkele database te gebruiken.
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.
Beste is om hem over de streep te trekken, laat de ITérs maar beslissen over een goede structuur i.p.v. iemand die het beter denkt te weten.
Ik zie mij niet bij verzekeraar X weggaan, en de database met al mijn gegevens overbrengen naar verzakeraar Y. Dus in dit geval omdat het voor het opslaan van leden is, zou ik kiezen om een enkele database te gebruiken.
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.
Beste is om hem over de streep te trekken, laat de ITérs maar beslissen over een goede structuur i.p.v. iemand die het beter denkt te weten.
Je hebt gelijk hoor.
Ik zal het er nog eens met hem over hebben zodra hij op kantoor is :)
Goed punt ook: inventariseer wat er technisch nodig is voor updates plus back-ups en wat dat gaat kosten.
Wordt met users eigenlijk bedrijven/websites bedoeld, dan kan ik me voorstellen dat iedere website/bedrijf z'n eigen database krijgt (met daarin z'n eigen users).
Maar goed, als er dus maar 1 website is en voor die ene website ga je voor iedere user een aparte database maken, dan ben ik het volledig met Aar eens. Dat is complete onzin.
Ozzie PHP op 23/09/2014 11:32:21:
Hangt inderdaad van de situatie af lijkt mij. Als het om users gaat BINNEN 1 WEBSITE, dan zet je die allemaal in dezelfde database.
Wordt met users eigenlijk bedrijven/websites bedoeld, dan kan ik me voorstellen dat iedere website/bedrijf z'n eigen database krijgt (met daarin z'n eigen users).
Maar goed, als er dus maar 1 website is en voor die ene website ga je voor iedere user een aparte database maken, dan ben ik het volledig met Aar eens. Dat is complete onzin.
Wordt met users eigenlijk bedrijven/websites bedoeld, dan kan ik me voorstellen dat iedere website/bedrijf z'n eigen database krijgt (met daarin z'n eigen users).
Maar goed, als er dus maar 1 website is en voor die ene website ga je voor iedere user een aparte database maken, dan ben ik het volledig met Aar eens. Dat is complete onzin.
Voor elke user moeten er een groot aantal gegevens opgeslagen worden, zoals bedrijf, gebruikers bij dat bedrijf (lopen op in de duizenden), enz.
Ja... en? Daar is een database nu ook precies voor bedoeld ;)
Als het dus om 1 bedrijf/website gaat, dan heeft dat ene bedrijf normaal gesproken 1 database, en niet voor iedere user een aparte database.
Dat zijn nu zaken die je niet efficient kan doen als je alles in losse databases opslaat. Ook een berekening om te kijken welke groepen winkels de meeste aantallen hebben, is zo goed als not-done. Dus juist met het opslaan in meerdere databases help je juist de manier van het werken met een database om zeep en zou je bij wijze van spreke net zo goed een kaartenbak kunnen gebruiken.
Een database is niet alleen bedoeld voor het opslaan, maar ook om te kunnen filteren en sorteren op de inhoud, en dat is met dit systeem lastig tot niet te doen.
Gewijzigd op 23/09/2014 11:51:29 door - Ariën -
Ik kan mij zo voorstellen dat hij die verbouwing te tijdrovend, duur en risicovol vindt. De technisch superieure oplossing is dan bedrijfseconomisch onaantrekkelijk.
Joshua van den Hoonaard op 23/09/2014 09:58:28:
Ik weet van mezelf dat dit niet echt efficient is, maar mijn opdrachtgever wil dit meer uit voorzorg.
Stel de boel crasht, dat dan niet de hele database verloren gaat, maar misschien maar een bepaalde user.
Stel de boel crasht, dat dan niet de hele database verloren gaat, maar misschien maar een bepaalde user.
Als het puur om het niet verliezen van data gaat, zou ik kijken naar replication.
Dan kan je er bijna 100% zeker van zijn dat je niets verliest.
Duizenden records zegt niets, daarbij kan je als denkt dat tabellen echt uit het jasje gaan groeien, partitioning gebruiken.
Een aanbieding kan 1 artikel hebben, maar een artikel kan meerdere aanbiedingen hebben
Producten:
- Artikel (tabel)
-- Artikel ID
-- Artikel naam
-- Artikel omschrijving
-- Artikel prijs
- Aanbiedingen (tabel)
-- Aanbieding id
-- Aanbieding prijs
-- Artikel ID
Klanten:
- Users (tabel)
-- User ID
-- Voornaam
-- Achternaam
-- Etc.
- User_aankopen (koppel tabel voor "Users en Artikelen", een user kan meerdere artikelen kopen,
en een artikel kan door meerdere users gekocht worden)
-- User ID
-- Artikel ID
Facturen:
- Facturen (tabel, heel simpel voorbeeld, hoort anders natuurlijk)
-- Factuur ID
-- Factuur bedrag
We kunnen nu met een JOIN query snel en simpel een gebruiker ophalen, de producten te bekijken die hij/zij heeft besteld, en zien of de facturen zijn betaald.
Dan kun je toch ook voor die ene specifieke toepassing een EXTRA database maken?
Het hangt er vanaf wat er met die users moet gebeuren. Zijn het algemene users met vergelijkbare eigenschappen, of zijn het allemaal verschillende "eilandjes". Daar kan alleen de TS antwoord op geven.
Toevoeging op 23/09/2014 12:15:24:
Heb nu in ieder geval genoeg argumenten om het anders te doen dan dat hij wenst. haha :)