Eén database of meerdere aan elkaar koppelen

[martindes]

Ik zou graag weten wat de voor en nadelen zijn van meerdere databases die aan elkaar gekoppeld worden t.o.v. één database waar alle tabellen in zitten.

Bijvoorbeeld, wat zou het voordeel zijn wanneer je een aparte database maakt van contacten met alleen de tabel contacten om die dan in een andere database, zoals b.v. bedrijven met een tabel bedrijven, aan elkaar te koppelen.

[martindes]

Dank voor de antwoorden. Het zou ook mijn keuze zijn om het in één bestand te zetten maar ik moet nu werken met een bestaande FM oplossing die uit verschillende bestanden bestaat.

Kwestie van het goede moment uitzoeken om de huidige gebruikers ervan te overtuigen dat het beter is om het allemaal te migreren naar één bestand. 

[Peter Wagemans]

FileMaker zat oorspronkelijk op die manier in mekaar. 1 bestand was 1 tabel. Maximum. Je kon maximum 50 bestanden openen, dus je kon maximum 50 tabellen in je applicatie hebben, tenzij je zorgde dat je bestanden sloot als je in een ander gedeelte van je applicatie zat. Nogal bewerkelijk.

Vanaf FileMaker 7 kunnen we een miljoen tabellen per bestand hebben, je zou dit een verbetering kunnen noemen. Maar dat wil ook niet zeggen dat het altijd de beste oplossing is.

Voordelen als je alle tabellen in 1 bestand hebt:

• Eenvoud. Als je naar de veld definities dialog gaat, dan zie je daar ook all tabellen. Externe tabellen gebruiken in een volledig of gedeeltelijk "front end" bestand is soms nogal verwarrend. Relaties moet je maar 1 keer aanmaken, in tegenstelling met de oplossing met externe tabellen, waar je soms relaties ook in de andere tabellen moet dupliceren om alles te doen werken.
• Minder bugs. Gegevens gebaseerd op calculaties met gerelateerde gegevens over verschillende bestanden, gaan in veel gevallen niet zomaar "opgefrist" worden als je gegevens verandert. En da's maar 1 van de bugs. Waardelijsten werken ook niet 100% OK bijvoorbeeld.

Voordelen van meerdere tabellen verdeeld over meerdere bestanden:

• Modulariteit. Vooral bij grotere applicaties wil je dit. Contacten en bedrijven zou ik in 1 bestand houden, en dit bijvoorbeeld het "Relatiebeheer" bestand noemen. Daarin zou ik ook de adrestabellen, de communicatietabellen, de links tussen bedrijven, de fotos, enz. in steken, zolang het maar onder de noemer valt, is het logisch. Zo kan je als snel aan een 20-tal tabellen zitten in een wat groter relatiebeheer bestand. Dan krijg je een "Facturatie" bestand, met alle uitgaande in binnenkomende facturen, factuurlijn tabellen, betalingstabellen, eventueel buffertabellen voor een koppeling met een extern boekhoudprogramma, enz. En ga zo maar door voor stockbeheer, productie, contracten, personeeelsbeheer,...
• Productising en upgrades. Als je de zaken goed aan boord legt, dan heb je langs de ene kant je interfacebestanden, en aan de andere kant je databestanden. In een ideale wereld houdt dan een upgrade in dat je alleen de interface bestanden vervangt. Jammer genoeg is het bijlange niet altijd zo simpel. In mijn opinie is dit tot op zeker niveau bruikbaar.
• Server backups. Hier ga je je gegevens op een andere manier verdelen. Tabellen waarvan de gegevens constant veranderen, steek je niet samen met grote statische tabellen, maar houdt je in aparte bestanden. Hierdoor kan je server sneller backups maken, en pakken je backups ook minder plaats. Natuurlijk kan je deze techniek ook combineren met het puntje over modulariteit.

Ik ben er zeker van dat de lijst van voordelen vsan beide systemen nog verder kan aangevuld worden, en dat zelfs onder de experts de meningen verdeeld zijn.

In jouw geval zou ik gaan voor 1 bestand. Zeker aan de hand van je voorbeeld. Meestal begin ik met alles in 1 bestand, en splits ik naar meerdere bestanden achteraf, als dat nodig is. Dit is heel gemakkelijk te verwezenlijken,. Maar het is ook een andere topic...:-)

[Banach]

Ook een voordeel als je alle tabellen in 1 bestand hebt:

Het accountbeheer is een stuk eenvoudiger. Zo heb ik een klant die een oplossing heeft waarvan de basis uit het pre-FM7 tijdperk stamt. 74 bestanden! Even een nieuw account toevoegen kost je wel een dikke middag.

Ik zie geen voordeel in het scheiden van data en interface. Het update/upgrade argument gaat alleen op wanneer er niets aan de database structuur verandert (velden, tabellen, relaties). Verandert daar wel iets aan dan moet je toch weer via export/import de update uitvoeren. Een proces dat goed te automatiseren (scripten) is.

Peters argument van snellere backups en minder opslagruimte daarvoor was in het verleden zeker geldig. Hedentendage merkt de gebruiker nauwelijks iets van de backups onder werktijd en met de introductie van de incremental backups zal ook de opslagruimte niet echt meer een issue zijn.

Kortom, ik ben het volmondig eens met Peter: in jouw situatie alles in 1 bestand. Dat zou ook mijn keuze zijn. Eigenlijk is dat dus altijd mijn keuze.

Edited March 10, 2018 by Banach

[martindes]

Ik ga inderdaad ook voor 1 bestand. Maar ja, het is een oplossing die ik niet gemaakt heb en de gebruiker houdt voorlopig nog vast aan allemaal aparte bestanden. De tijd zal het leren.

[Marsau]

Op 10-3-2018 om 16:34 zei Banach:

Ook een voordeel als je alle tabellen in 1 bestand hebt:

Het accountbeheer is een stuk eenvoudiger. Zo heb ik een klant die een oplossing heeft waarvan de basis uit het pre-FM7 tijdperk stamt. 74 bestanden! Even een nieuw account toevoegen kost je wel een dikke middag.

Inderdaad. Wat betreft accountbeheer sec (toevoegen, verwijderen, deactiveren) valt er nog wat te scripten, maar dan heb je ook het probleem dat je wachtwoorden moet gaan opslaan ergens in je tabellen. En los van het beheer van accounts heb je in elk bestand de opgave om de privileges in te regelen. Dat blijft.

Externe authenticitatie verlicht het accountbeheer enorm, maar plaatst het ook weer buiten de controle van Filemaker. Ik begrijp nog altijd niet waarom bij Filemaker niet de mogelijkheid bestaat om authenticitatie aan één bepaald Filemaker bestand te leggen; een soort middenweg tussen 'intern' en 'extern'.