> > Mulighed nummer 1 er at oprette en selvstændig database til hver
> > kunde, det er den jeg bruger i øjeblikket. Det besværliggører dog
> > opdateringer da man skal sørge for at alle databaser opdateres
> > tilsvarende med systemet.
>
> Vil ikke anderledes end når databasen ligger hos kunden?
> Du kan evt referere til en table på formen <db>.<usr>.<table>
Jeg forstår ikke lige hvad du mener her? Mit problem er, f.eks, hvis jeg
ændrer en felttype i min template database, så skal jeg ud og rette denne
ændring i mine x antal kundedatabaser.
> > Mulighed nummer 2 er at have een database
> > til alle kunder, og refererere alt kundespecifikt med et kundeid. Det
> > besværliggører dog alle queries til databasen, da man så skal huske
> > et kundeid hele tiden. Dog vil det gøre opdateringer meget lettere.
> >
> Jeg er lige klar hvordan systemer som Axapta, SAP, Baan klarer den side af
> det internt
> Men jeg ved at fx SAP har du ClientID (MANDT) sammen med resten af dataene
i
> de fleste tabeller
> MANDT = Regnskab/Firma
>
> Axapta og Baan arbejder også med skift med regnskaber/firmaer ved at ændre
> lign ClientID
> En (alm) Axapta installation har én DB til alle regnskaber
Såvidt jeg forstår ud fra din forklaring bruger de altså også løsningen med
at sende et "CustomerID" med rundt, og således have en enkelt database til
alle sites.
> > Rent performancemæssigt, hvad er så mest effektivt?
> >
> Tjahh, splitter du data op i mange databaser så kan man påstå at den er
> fragmenteret
> Med clustered indexes på din KundeID burde du komme et skridt på vejen
> Der er vel ikke tale om flere mill records?
Næh, hvis jeg skal være realistisk kommer der nu nok heller ikke lige
foreløbig bare en promille af det antal :).
> Query Analyzer og Profiler er ganske udmærkede værktøjer til at finde
> bottlenecks
Yep, det er bare dejligt med nogle andre brugeres erfaringer oveni :).
Tak for dine kommentarer.
Mvh Mark