Pro / Contro per una struttura dati che copre più database?

Naviga le tue risposte
3

Sto per estendere un sistema che contiene due sistemi separati. O domini, se vediamo il sistema come un livello di dominio.

Oggi

Un dominio è usato internamente. L'altro è pubblico, il che significa che è più esposto a qualsiasi cosa possa accadere "là fuori". Servizi di qualche tipo (alcune opzioni si applicano) eseguono operazioni tra i due sistemi separati. Il sistema pubblico e quello interno hanno separato le memorie di database e non sono correlate tra loro. Chiamiamo il client dei domini e memorizziamo.

Domani

Sono in una nuova applicazione che avrà molte più informazioni specifiche dell'utente nel dominio del cliente. Il design può essere paragonabile a un "database privato" che ha un link all'account facebook come chiave. Questo è paragonabile a un database che conteneva azioni dell'utente, ma non aveva dati specifici dell'utente (come indirizzo, data di nascita, email e così via), solo una chiave per il server di Facebook. Dall'altro lato, il database STORE (rispetto a Facebook-server in questo caso) non sa nulla delle azioni dell'utente.

Obiettivo

Circa l'85-90% delle query sarà all'interno del proprio dominio (client se client, store se store). Tuttavia, ci sono alcune situazioni in cui il cliente ha bisogno di ottenere dati dal database STORE e lo STORE deve creare / gestire gli utenti nel database CLIENT.

Domande fuori dalla mia testa

  • È un buon modo per andare?
  • pro / contro? Orfani? Prestazioni del database? Codifica .NET problematica?
  • I principi della scelta per i confini dei dati?

.. e altre cose che potresti conoscere o pensare

Un esempio di struttura

.. dbStore.Users

  • userid (PK)
  • nome
  • dateOfBirth
  • emailAddress - > Portafoglio (un'altra tabella)

.. dbStore.Wallet

  • walletid (PK)
  • userid
  • createddate - > BankAccount (un'altra tabella, non digitata)

.. dbClient.users

  • storeUserId (unique, non-inc) < - corrisponde a dbStore.User, no restraint
  • ACCESSLEVEL
  • lastLoggedIn
  • serviceXxEnabled
  • udpAccessKey

.. dbClient.action

  • actionid (PK)
  • isSomething
  • someDate
  • anythingElse

.. dbClient.installation

  • installationid (PK)
  • userid

Non raccogliamo informazioni sui conti bancari, ma solo per dare un'immagine della struttura dei dati e della sua importanza per mantenerla in sistemi separati. Spero che questo Q sia abbastanza comprensibile.

    
posta Independent 18.08.2011 - 10:08
fonte

2 risposte

2

Pensiamo a questo dalla prospettiva di dividere potenzialmente un database in due, al fine di evidenziare le differenze.

I principali svantaggi di una divisione sono:

  • Impossibilità di utilizzare il DRI su colonne comuni. Difficilmente un rompicapo, ma devi iniziare a progettare le tue applicazioni sulla possibilità che un ID non esista dove ti aspetti, e devi lavorare su buone soluzioni di sincronizzazione.

  • Impossibilità di eseguire join efficaci. Questo è in realtà solo parzialmente vero; in alcuni casi, se entrambi i database risiedono sullo stesso server, è possibile eseguire query tra database diversi, tuttavia, anche in questi casi, il codice può essere abbastanza complicato da scrivere, poiché non è più possibile fare affidamento su stringhe di connessione esterne e così via .

  • Le transazioni distribuite sono molto più costose delle transazioni su singolo database / connessione singola. In un ambiente Microsoft dovrai richiamare il DTC e aggiungere circa 10 volte di overhead.

  • Se utilizzi un framework Dependency Injection, ci sono buone probabilità che sia stato scritto finora per supporre che ci sarà sempre solo un IDbConnection , ISessionFactory , ecc. L'uso di due database potrebbe richiedere molto di refactoring. Non è un problema a lungo termine, ma comporta un costo iniziale.

  • Un po 'più stress cognitivo per gli sviluppatori in quanto ora devono ricordare in quale database si trova ogni tabella e / o fare riferimento ad alcuni documenti per questo.

  • I backup / ripristini possono essere più complicati, poiché è probabile che sia necessario ripristinare i entrambi database se uno fallisce, in modo da mantenerli sincronizzati. Ciò significa anche che il piano di backup dovrà anche essere progettato per ridurre al minimo la possibilità di incongruenze (a meno che l'applicazione non sia molto tollerante ai guasti in questo senso).

Questo è il male. Ci sono anche alcuni vantaggi :

  • Puoi spostare un database su un server diverso per ridurre il conflitto tra processore e memoria.

  • Puoi spostare un database su una diversa unità o SAN per ridurre il conflitto di I / O.

  • Eliminazione potenziale del problema "single point of failure". Ogni sistema dovrebbe, almeno in teoria, essere in grado di funzionare ragionevolmente bene se l'altro fallisce.

  • Più facile per concentrare gli sforzi del team e avere cicli di sviluppo / test / rilascio indipendenti per ogni sistema, se stai lavorando a un team più grande.

  • sicurezza potenzialmente migliorata; se un database viene compromesso, i dati privati nell'altro database possono rimanere privati. (Molte delle architetture di sicurezza sono suddivise in più parti esattamente per questo motivo.)

Sarei negligente se non menzionassi anche alcune delle soluzioni alternative, o compromessi se lo farai:

  • Schemi diversi nello stesso database. Questo ti dà la separazione logica delle preoccupazioni senza forzare la separazione fisica. Di fatto, gli schemi possono essere utilizzati per eseguire più istanze della stessa applicazione all'interno dello stesso database ed è possibile condividere tabelle comuni (ad esempio tabelle di configurazione) tra di loro.

  • Filegroup e file. Molti sviluppatori SQL sembrano dimenticare che questi esistono; se uno dei tuoi problemi principali è lo storage fisico , è possibile fisicamente segregare le tabelle per ciascun sistema, pur conservandole nello stesso database logico.

  • Pub / sub è un'alternativa al problema di prestazioni specifiche di grandi transazioni lunghe e distribuite, anche se richiederà un ulteriore sviluppo e supporto per mantenere, sia in anticipo che nel tempo.

In generale, cerco di conservare il maggior numero possibile di dati transazionali in un singolo database a causa dei vantaggi prestazionali localizzati che offre; ci sono molti modi per scalare e ridimensionare pur avendo un unico database logico. Ma alla fine è una decisione architettonica che dipende dai tuoi schemi di accesso e dai requisiti aziendali.

    
risposta data 25.10.2011 - 01:17
fonte
0

Se rimarrà 2 sistemi, le modifiche all'implementazione di una di esse non dovrebbero influire sull'altra. Ciò richiede una chiara separazione e per farlo vorrei:

  1. Consenti solo l'accesso a ciascun database dal sistema che lo possiede.
  2. Accedi all'altro sistema tramite interfacce chiaramente definite.
risposta data 25.08.2011 - 23:27
fonte

Leggi altre domande sui tag

Rischi nel fornire il certificato di distribuzione / chiave privata / profilo di provisioning al libero professionista Quale licenza è applicabile per un'app basata su CodeIgniter?