Si dovrebbe usare un database separato per dati applicativi e dati utente?

Question

Si dovrebbe usare un database separato per dati applicativi e dati utente?

#1 da (4 voti)
#2 da (3 voti)
#3 da (2 voti)

5

Ho lavorato a un progetto per un po 'e non sono sicuro quale sia l'architettura migliore. Sono interessato al consenso. La risposta a me sembra abbastanza ovvia ma qualcosa a riguardo mi sta scavando e non riesco a capire cosa.

Il TL; DR è: come gestisci un programma con dati applicativi e dati utente nello stesso DB che deve essere in grado di ricevere periodicamente aggiornamenti ai dati dell'applicazione? Un database per i dati utente e uno per applicazione, o entrambi in uno?

La versione dettagliata è .. se un'applicazione ha un database che ha bisogno di mantenere i dati delle applicazioni ei dati utente, e tutti i dati utente fanno riferimento ai dati dell'applicazione, mi sembra più naturale conservarli nello stesso database

Ma se esiste la necessità di essere in grado di aggiornare periodicamente i dati dell'applicazione all'interno di questo database, questo dovrebbe essere rimosso in due database in modo che si possa semplicemente scaricare il file del database dei dati dell'applicazione aggiornato come aggiornamento e sostituire quello vecchio? O dovrebbero rimanere come un unico database e i dati dell'applicazione saranno aggiornati tramite uno script che inserisce i nuovi dati nel database esistente? Il secondo suono è chiaramente preferibile a me ... ma per qualche ragione non mi sembra giusto, e non riesco a capire perché.

design database architecture software-updates

posta trycatch 20.03.2012 - 02:57

fonte

3 risposte

Leggi altre domande sui tag design database architecture software-updates

Strutturazione del database per funzionalità "attività" e "seguenti" multioggetto Qual è il modo migliore per imparare lo stack di MS Business Intelligence? [chiuso]

score 4 · Answer 1

Se hai mai bisogno di spostare l'applicazione, indipendentemente dal database utente, allora hai bisogno di un database separato per l'applicazione (in qualsiasi forma che lo richieda), in modo che il database possa viaggiare con l'applicazione, lasciando intatti i dati dell'utente nella sua posizione originale.

Ne consegue che, se il database dell'applicazione viene aggiornato periodicamente dal fornitore (che è tu), allora deve essere tenuto separato dal database dell'utente, in modo che tu possa distribuire le modifiche al database dell'applicazione senza influire sul database dell'utente .

Ora, se devi aggiungere campi o tabelle al database degli utenti, questa è una storia diversa. Per questo, è necessario un modulo che possa accettare come input una tabella delle modifiche dal database dell'applicazione, da applicare al database utente. Alcuni programmi lo fanno "convertendo" il database dell'utente nel nuovo formato.

La conversione dei dati può essere effettuata utilizzando SQL DDL per applicare gli aggiornamenti di campi e tabelle al database dell'utente, in modo tale da non influire negativamente sui dati dell'utente. In alcuni scenari avanzati, le trasformazioni dei dati potrebbero effettivamente aver luogo; normalizzazione o denormalizzazione, per esempio.

Se è necessario fornire agli utenti la possibilità di eseguire un trasferimento di dati, è necessario utilizzare altri meccanismi, come un conduit di comunicazione, o un file di importazione / esportazione contenente i dati da trasferire (forse in XML).

score 3 · Answer 2

Non penso che importi davvero. Esclusione di altri requisiti, a condizione che sia possibile aggiornare i dati dell'applicazione secondo necessità, indipendentemente dal fatto che siano presenti in un database separato o nello stesso database. Gli script SQL possono eliminare / ricaricare le tabelle in entrambi i casi.

score 2 · Answer 3

Guarderei l'accoppiamento. Tutti i tuoi dati appartengono insieme, cioè tutti i dati sono nello stesso contesto limitato (per utilizzare la terminologia di progettazione basata sul dominio)? Altrimenti, potresti voler dividerlo.

Per un'applicazione, la posizione fisica non è importante quanto quella logica, ma per la manutenzione / le prestazioni il fisico è piuttosto importante.

Il fatto che questo ti infastidisca su un certo livello significa che la struttura potrebbe non essere constrongvole. Analizza le relazioni tra i dati più da vicino e fai una chiamata.