Sviluppo di nuove applicazioni - Utilizza il database esistente o creane uno nuovo?

Question

Sviluppo di nuove applicazioni - Utilizza il database esistente o creane uno nuovo?

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

4

Un client ha un'enorme applicazione Windows in esecuzione su un database. Questo cliente vuole che tu sviluppi una versione "Express" di questa applicazione, includendo solo, diciamo, il 20% delle sue funzionalità. Questa versione Express deve essere un'applicazione Web, aperta sul WWW. Hai 2 scelte:

Utilizza lo stesso database per sviluppare l'applicazione web
Crea un nuovo database per l'applicazione Web, includendo solo le tabelle e gli oggetti necessari e utilizza un meccanismo di sincronizzazione per mantenere aggiornati i database.

Il cliente preferisce la seconda opzione, perché:

Sicurezza: se dispongono di un database separato per l'app Web, non "esporranno" l'enorme database di App di Windows su Internet.

Prestazioni: l'applicazione Windows ha un enorme processo che viene eseguito di notte e "blocca" il database per un paio di minuti. Pertanto, la creazione di un DB separato garantirebbe prestazioni migliori per l'applicazione Web.

Preferisco la prima opzione, perché:

Integrità: se disponiamo di database diversi, non saremo in grado di creare chiavi esterne tra loro.

Evita sincronizzazione: se disponiamo di database diversi, dovremmo creare un meccanismo di sincronizzazione, che è molto incline agli errori.

Manutenzione: la manutenzione sarà più semplice se disponiamo di un solo database. Nessuna modifica dovrà essere replicata.

Puoi aiutarmi a decidere quale strada seguire e perché?

database sql-server synchronization applications

posta Octavio 28.05.2012 - 22:45

fonte

5 risposte

Leggi altre domande sui tag database sql-server synchronization applications

C'è qualche logica dietro la mancanza di chiusura di SQL per le operazioni standard in lingue imperative? Firme IDE e identificazione del software IDE

score 5 · Answer 1

Sono incline ad essere d'accordo con te per i motivi che hai indicato. Inoltre, se si utilizza lo stesso database, si ottiene anche un vantaggio aziendale molto pratico: è possibile "aggiornare" facilmente un cliente alla versione completa senza una complicata esportazione / importazione dei dati.

Una cosa che potresti raccomandare è provarla prima con l'approccio basato su un solo database. Se questo diventa un problema, è molto più semplice separare i dati "espressi" in un nuovo database piuttosto che se si iniziasse con due database, ma in seguito si è deciso di unirli.

score 2 · Answer 2

Sono d'accordo anche con l'opzione 1 db, per ulteriori motivi.

Report

È possibile registrare le azioni eseguite tramite client Web rispetto al client dell'app e creare report su di esso. Le metriche di utilizzo come questa possono essere molto utili.

Performance

Se l'app e i DB Web non sono sincronizzati per un periodo di tempo lungo, il tempo di sincronizzazione può essere un problema per gli utenti, a seconda della strategia di sincronizzazione.

Costo

Sarà semplice-vecchio meno non scrivere un secondo DB.

Time To Market

Se hanno già un livello di servizio, allora sei d'oro, usa quello. In caso contrario, è possibile crearne uno per racchiudere le librerie / funzionalità già esistenti e disporre di codebase comprovati, testati e di qualità di produzione che supportano i servizi e non è necessario modificarli per colpire un nuovo DB o schema.

score 1 · Answer 3

"Il cliente preferisce la seconda opzione .." Quindi non è più un problema tecnico. Il cliente ha parlato, ha il diritto di dirti cosa fare (e accetta la responsabilità per quella scelta). Se non fai ciò che chiede il cliente, devi accettare responsabilmente la scelta, e non fare ciò che il tuo cliente ha chiesto non è una buona pratica commerciale.

score 1 · Answer 4

Se ti ho capito bene, l'obiettivo è disporre di un pool di dati coerenti sia per l'applicazione client che per l'applicazione web. La soluzione più semplice è ovviamente un DB e, come hai scritto, un approccio a due DB richiede un meccanismo di sincronizzazione. Ma pensiamo un attimo all'approccio basato su due database per vedere cosa non hai menzionato nel tuo elenco:

invece di creare un DB con uno schema diverso, è possibile creare un secondo DB con lo stesso schema, una copia di tutti i dati e utilizzare il meccanismo di replica incorporato del server MS SQL. In questo modo, la sincronizzazione diventa molto più semplice e meno soggetta a errori.
integrità / chiavi esterne: se usi la replica, questo non sarà un problema: tutti i dati a cui fare riferimento sono disponibili in entrambi i database
disponibilità e velocità della rete: questa è la cosa fondamentale quando si pensa a un db contro due. Due database possono essere ospitati in siti diversi, con reti diverse collegate. Quando un server è inattivo (o bloccato a causa di alcuni processi batch), l'altro può ancora funzionare.

Quindi consiglio di pensare principalmente all'ultima cosa: hai bisogno di una maggiore disponibilità fornita da una soluzione a due database? O quei due database saranno sempre tenuti sullo stesso sito, forse sullo stesso server? Quindi la soluzione "un database" è probabilmente la soluzione migliore.

score 0 · Answer 5

Sono pienamente d'accordo con @SnOrfus che la "Creazione di un nuovo database per l'applicazione web" è la soluzione più costosa.

Se questo non è un argomento per il cliente, come suggerito da @mattnz potresti avere una soluzione provvisoria con refactoring parti della soluzione in una libreria comune che contiene codice che è necessario per entrambi. In questo modo puoi almeno ridurre l'incubo del maintanace.