wanneer het juiste moment om een database in Access te splitsen

Status
Niet open voor verdere reacties.
A

AdvB

Gebruiker
Lid geworden
1 jul 2021
Berichten
48
Ik ben een database aan te maken die in toekomst door meerdere mensen gebruikt gaat worden.
Het lijkt me daarom handig dat de database gesplitst wordt zodat er daadwerkelijk met meerdere mensen gewerkt kan worden.
de database bestaat uit meerdere "modules". er is module voor Technische dienst, voor verhuur en voor inkoop, alle refereren aan bijvoorbeeld tabel artikelen
1 "module"is werkend (met de bijbehorende tabellen), de rest nog niet.
Is het handig om pas als alles af is de database te splitsen of kan dat al eerder (ca. de helft van de toekomstige tabellen bestaan nog niet).
 
Je kan een database splitsen op elk gewenst moment, maar bedenk wel dat áls je dat gelijk doet, de structuur van je database wel zo'n beetje in orde moet zijn, dus alle algemene zaken, zoals tabellen en universele queries, zou ik zelf al klaar hebben voordat ik ga splitsen. De reden is simpel: als je dat nog niet in orde hebt, dan moet je daarna niet in één FE database de handel toevoegen en bijwerken, maar in alle Frontends. En dat is dus extra werk, waar je vast niet op zit te wachten. Aangezien je nog niet de helft van je tabellen hebt, zou ik zeggen: wacht nog even :).
 
Volgens mij is de gemakkelijkste methode: het database werk doe je van in het begin in de database back-end en de user interface maak je vanaf het begin in de front-end.
Zo moet je het database werk maar op één plaats doen, of 3 als je een development, een test en een productie omgeving hebt. Telkens je een nieuwe module ontwikkelt, koppel je de nodige tabellen/views aan je user interface applicatie. Hiervan heb je maar één development exemplaar dat je, bij elke nieuwe versie uitrolt in de test en/of productie.
 
NoellaG zei:
Volgens mij is de gemakkelijkste methode: het database werk doe je van in het begin in de database back-end en de user interface maak je vanaf het begin in de front-end.
Klik om te vergroten...
Dat heb ik dus echt nog nóóit de makkelijkste methode gevonden. Dus ook nooit zo gedaan. Al was het maar omdat je, als je in de backend iets moet veranderen, je continue de Frontend óók moet aanpassen. Je doet dan dus continue dubbel werk, en er zit geen enkel voordeel aan.

Ik werk dus altijd in één database, tot die getest en uitgerold kan worden. Dán pas splits ik de db (is echt een fluitje van een cent) en maak ik de afzonderlijke Frontends. En voor mij heeft dat (werken in één database) alleen maar voordelen, geen nadelen.
 
Ieder zijn methode :).
Ik gebruik dan ook altijd een SQL database als back-end, want zoals octafish al zelf heeft aangegeven:
waarom zou je in een gammele Opel Corsa blijven rijden als je ook mooie Tesla voor de deur hebt staan?
Klik om te vergroten...
 
NoellaG zei:
Ik gebruik dan ook altijd een SQL database als back-end
Klik om te vergroten...
En dan kom je eigenlijk al vanzelf in een FE-BE constructie terecht. Maar dit is een Access forum, geen SQL server forum. Derhalve baseer ik mijn oplossingen altijd op Access. Tenzij TS zelf aangeeft met een SQL Server (Microsoft, Oracle etc) te werken waarbij Access alleen als Frontend wordt gebruikt. En zeg nu zelf: hoeveel vragen komen daarover binnen? :).
 
Overstappen dus met z'n allen :). Gelukkig hebben wij daar aparte subforums voor, waar de juiste specialisten de mensen verder helpen. Kwestie van de juiste vraag in het juiste forum stellen dus. Geldt overigens ook voor Belgen ;)
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan