advies database meerdere gebruikers

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Bas van de Ven

Bas van de Ven

03/04/2015 12:25:49
Quote Anchor link
N.a.v. afwijkende adviezen mijn webapplicatie anders in te richten overweeg ik 4 opties om een database opnieuw in te richten.
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.
 
PHP hulp

PHP hulp

12/12/2024 15:17:25
 
Thomas van den Heuvel

Thomas van den Heuvel

03/04/2015 12:46:08
Quote Anchor link
De inrichting lijkt mij afhangen van het gebruik; hoe gaan deze gebruikers straks om met deze database(s)? Ik neem aan dat zij niet queries gaan plakken in phpMyAdmin maar dat je applicatie een soort van interface heeft die tussen de gebruiker en de database zit (= je webapplicatie)?

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
 
Bas van de Ven

Bas van de Ven

03/04/2015 13:00:13
Quote Anchor link
Ter aanvulling. Het is een administratieve appl. met wat management info. Iedere gebruiker heeft zijn eigen administratie welke niet wordt gedeeld met andere gebruikers.

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 ?
 
- wes  -

- wes -

03/04/2015 13:07:50
Quote Anchor link
administration
-------------------
id
title
date_created



user
-------------------
id
name
email
password
administration_id
date_created



zo ben je er toch al?
 
Thomas van den Heuvel

Thomas van den Heuvel

03/04/2015 13:34:17
Quote Anchor link
Als je alle data een kenmerk geeft van wie die data is, en je applicatie vervolgens alleen de informatie toont die van jou is (login + controle op het kenmerk), dan is er geen reden om deze data in een aparte tabel of database op te slaan.

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.
 
Bas van de Ven

Bas van de Ven

04/04/2015 16:13:31
Quote Anchor link
Bedankt voor input. Inmiddels ben ik optie 2 aan het uitwerken. Alles in 1 database en unieke tabellen.
 



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.