advies database meerdere gebruikers
Het aantal gebruikers op termijn is lastig in te schatten. Het is een zeer specifieke doelgroep en dit heb ik zelf in de hand. Nu zijn het 3 gebruikers en laat ik het voor de toekomst voorlopig houden op max 20 gebruikers.
Momenteel bestaat elke database uit 19 tabellen en 60 query’s waarvan 40 query’s die ik het liefst zou willen nesten. Geneste query’s kunnen echter niet worden opgeslagen binnen phpMyAdmin.
Vooralsnog heb ik per gebruiker een database aangemaakt welke wordt aangeroepen o.b.v. inloggegevens.
Optie1 :
Optie 1 is laten zoals het is en dus per gebruiker een database aanmaken.
Optie 2:
Als optie twee had ik bedacht 1 database met in elke tabel de records over alle gebruikers. Bijv. tabel tblPersonen bevat persoonsgegevens van alle (3) gebruikers.
Elk record is hier echter wel voorzien van een gebruiker_Id dat per gebruiker uniek is.
Mogelijk levert dit performance problemen als ik in een script de gehele tabel tblPersonen ophaal (of een view op deze tabel) en pas in het script een filter kan zetten op gebruiker_Id.
Optie 3:
De derde optie zou ook 1 database kunnen zijn met per gebruiker een eigen tabel gekenmerkt door een prefix. Heb ik nu 1 tabel tblPersonen dan heb ik straks voor 3 gebruiker 3 x tabel tblPersonen voorafgaand aan een prefix. Dus :
user1_tblPersonen,
user2_tblPersonen
user3_tblPersonen.
Helaas geldt dit m.i. ook voor de query’s. 1 query nu is 3 query’s straks.
Naast optie 1 is ook deze optie mij geadviseerd echter door een persoon die juist optie 1 afraadde.
Optie 4:
Deze optie is nagenoeg hetzelfde als optie 3. Het verschil is dat ik de query’s niet opsla in de database als views maar in een php-script. Op deze manier kan ik de prefix in de tabelnaam nl. variabel maken. Ik verwacht met deze optie echter wel een performance probleem ontstaan. Ik heb vooralsnog geen ervaring met het uitvoeren van ‘grotere’ query’s vanuit een script.
Oplossing:
Zelf neig ik naar optie 2 omdat dit voor mijn query’s de minste impact heeft. Komt er een gebruiker bij dan blijven de hoeveelheid query’s gelijk. Ook updates van query’s hoef ik maar 1 x uit te voeren voor alle gebruikers.
Optie 1 en 3 betekent voor mijn query’s 60 x het aantal users. Vanuit veiligheidsaspecten heb ik een tijd terug juist voor optie 1 gekozen en werd als advies (dus) ook bevestigd.
Bekeken vanuit beheers oogpunt heeft optie 4 mijn voorkeur. Nu heb ik de query’s opgeslagen in 60 Word-documenten. Dat heb ik in optie 4 in 20 php-scripts i.v.m. het kunnen nesten.
Ik ben behoorlijk thuis in sql en normaliseren maar minder in het goed inrichten van databases.
Zijn er mensen die hier een zinnig advies over kunnen geven ? Ik hoop dat ik het enigszins begrijpelijk heb uitgelegd.
Dan: wie mag wat zien / wie mag welke bewerkingen op data uitvoeren? Kijkt iedereen tegen dezelfde (bron)data aan of heeft iedereen zijn eigen persoonlijke data (optie1: elk hun eigen database? dan verschillen de data in de verschillende databases toch op den duur, of wou je alles continu gaan synchroniseren op een of andere manier?).
Je vraagt in feite hoe je iets moet opzetten/inrichten zonder dat je erbij vertelt wat je nu precies probeert te bereiken (waar voorziet de applicatie in, wat stelt dit de gebruikers in staat te doen?). Dat wordt een beetje lastig :s.
Gewijzigd op 03/04/2015 12:47:21 door Thomas van den Heuvel
Er worden idd geen queries geplakt door gebruikers. Mijn webappl. is idd de interface tussen gebruiker en database. Enkel de data verschilt dus per gebruiker niet de tabellenstructuur.
Wat ik wil bereiken is een veilige, snelle en onderhoudsvriendelijke appl. waar meerder gebruikers toegang toe hebben met een ieder zijn eigen data.
Is dit voldoende toegelicht ?
-------------------
id
title
date_created
user
-------------------
id
name
password
administration_id
date_created
zo ben je er toch al?
Vergeet ook niet dat je door de opslag in een aparte tabel of aparte database het ook moeilijker zo niet onmogelijk maakt om al die data (om wat voor reden dan ook) op een later tijdstip weer bij elkaar te brengen. Je had het al over management informatie (rapportages?). Wat nu als je straks een soort van totaalrapportage wilt maken over verschillende (groepen) gebruikers? Dat wordt een heel karwei als deze informatie verspreid staat over verschillende tabellen of databases. De (ontwerp)beslissingen die je nu neemt kunnen daar een enorme impact op hebben. Vraag je dus niet alleen af hoe je informatie nu gebruikt, maar ook in de (nabije) toekomst. Je ontwerp moet in zekere mate flexibel zijn.
Een oplossing met meerdere tabellen of databases (die hetzelfde doen en hetzelfde doel hebben) lijkt mij daarom eigenlijk op voorhand al niet de goede keuze.