Almeno una vista del database per tabella del database: questa progettazione è buona o cattiva e perché?

Question

Almeno una vista del database per tabella del database: questa progettazione è buona o cattiva e perché?

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

4

Stiamo costruendo un'applicazione basata su Windows Mobile per interfacciare con l'applicazione Web esistente di un cliente. Stiamo leggendo e scrivendo i dati nel database SQL Server 2008 del cliente.

Il cliente desidera che tutte le letture avvengano tramite le viste SQL e che tutte le scritture avvengano tramite stored procedure.

Ma dando un'occhiata al loro schema di database, hanno una vista di ogni singola tabella. E hanno una vista di ogni singola query che verrebbe utilizzata per leggere i dati, invece di usare le viste esistenti sulle loro tabelle. Hanno 348 tabelle e 655 visualizzazioni finora.

Vogliono che modelliamo la nostra applicazione mobile in modo simile, ovvero creiamo visualizzazioni aggiuntive per tutte le query che utilizziamo per recuperare i dati.

So che questo è un progetto scadente, ma non sono in grado di elencare al cliente perché la loro strategia basata sulla vista è un progetto scadente.

Qual è il consenso nella comunità su quando utilizzare le visualizzazioni? In che modo avere così tante visualizzazioni influisce sulle prestazioni del server SQL?

database database-design sql-server

posta One-One 18.04.2012 - 06:00

fonte

4 risposte

Leggi altre domande sui tag database database-design sql-server

Strategie di produttività per uno sviluppatore che utilizza molti PC [chiuso] Opzioni di licenza per un progetto morto

score 7 · Answer 1

In realtà è un design piuttosto buono. L'utilizzo delle viste conferisce i seguenti vantaggi: -

Isola la tua applicazione da qualsiasi modifica nelle tabelle fisiche sottostanti.
Una vista può essere considerata come specifica formale dell'interfaccia tra client e server.
La vista consente un controllo di accesso a grana fine ai dati sottostanti. OSSIA è possibile dare diversi livelli di accesso a client mobili, basati su lan e web. I clienti devono solo avere accesso ai dati specifici di cui hanno bisogno piuttosto che all'intero database.
Le viste sono costrutti logici. Non c'è penalità di prestazioni nell'utilizzo di una vista.
In molte banche dati le visualizzazioni miglioreranno le prestazioni, poiché i tassi di successo della cache delle query sono generalmente migliori con le visualizzazioni rispetto alle query codificate a mano.

score 3 · Answer 2

Molte risposte hanno molti buoni motivi per utilizzare le visualizzazioni e fanno notare che non ci sono costi aggiuntivi per avere più visualizzazioni.

Ciò che potrebbe essere il driver per questo mandato è semplicemente che non vogliono darti la possibilità di rompere qualsiasi view / sp esistente e potenzialmente influenzare altre applicazioni, e anche, il loro esistente le visualizzazioni / sp non possono essere sospettate per alcuni bug della tua app che potrebbero far girare la testa più tardi.

È un'altra forma di stratificazione e modularizzazione. Tutto per la tua app passa attraverso il "tuo" view / sp layer. Installa o disinstalla la tua app e la tua serie di viste / sp è installata / disinstallata ecc.

score 2 · Answer 3

Sebbene l'accesso ai dati attraverso un livello di vista sia una buona idea, una visione separata per ogni query implicherà inevitabilmente la ripetizione di te stesso. Inevitabilmente, ci saranno regole aziendali che saranno comuni su molte visualizzazioni (ad esempio, qualsiasi filtro necessario per l'entità di apparire su una schermata dovrà quasi certamente essere ripetuto su tutte le schermate successive). Quando cambiano le regole aziendali, dovrai passare e modificare ogni vista che implementa quelle regole aziendali. Se, invece, puoi incorporare tali regole aziendali in un'unica visualizzazione, è molto più probabile che dovrai modificare il codice in un unico posto quando la logica cambia.

score 1 · Answer 4

  > The customer wants all reads to happen through SQL views, 
  > and all writes to happen through stored procedures.

Sono d'accordo che questo è più difficile da gestire dal punto di vista manutenzione

Ogni cambiamento nel web-gui significa che ci deve essere una modifica corrispondente nel database.
Questo rende la distribuzione e l'implementazione più complicate.

Ma dal punto di vista sicurezza questo è un buon progetto:

Le visualizzazioni del database consentono le permissioni a grana fine (ad esempio, quale ruolo utente può vedere quali colonne, dati relativi).
Le stored procedure proteggono il sistema da sql-injections.

Dal punto di vista delle prestazioni questo non dovrebbe essere più un problema, perché i moderni database (incluso mssql2008) consentono gli inex oltre le visualizzazioni dei database.