Esiste un modello di progettazione che descrive viste separate solo join e viste di solo formato

Incorporando abbastanza fantasia, sono abbastanza sicuro che le persone troveranno alcune somiglianze in modelli ben noti. Tuttavia, proprio perché il tuo approccio è in coincidenza con alcuni dettagli del modello GoF, non andrei così lontano e chiamerei la tua separazione di punti di vista un "Adattatore" o "Facciata" nel senso di GoF. Quelli sono schemi specifici per la programmazione orientata agli oggetti e quando inizi a utilizzare questi termini per le viste SQL, ti aspettano incomprensioni quando parli con altre persone.

Tuttavia, ciò che descrivi mi sembra solo un esempio del ben noto principio di progettazione del software "separazione delle preoccupazioni" - niente di più, niente di meno.

Provenendo da una base di dati del database, non posso dire di aver mai sentito espressamente che un DBA o uno sviluppatore di database effettivamente usa il termine "pattern" prima di descrivere la progettazione dello schema. I "modelli di progettazione" sono davvero più un concetto di programmazione e c'è una buona domanda su SO che esplora questo.

Per essere onesti, puoi certamente avere schemi di progettazione sul tuo database, ma potrei sostenere che questo ti possa mettere nei guai tanto quanto aiutarti. I modelli di progettazione sono strumenti per i programmatori di applicazioni che aiutano a risolvere problemi unici e vari. I database relazionali e Set Theory d'altra parte sono più strutturati e centralizzati sull'integrità dei dati. Le migliori pratiche di progettazione sono generalmente accettate (es. Normalization ) quindi i modelli intelligenti come < a href="https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model"> EAV sono generalmente disapprovati da DBA duri.

Venendo alla tua domanda intorno a punti di vista, ciò che è preferibile dipenderà da ciò che stai cercando di fare. Fondamentalmente hai due tipi di elaborazione:

• OLTP - OnLine Transactional Processing
• OLAP - OnLine Analytical Processing

Per OLTP , a meno che tu non stia utilizzando le viste come parte del tuo modello di sicurezza (per limitare l'accesso al ruolo di un utente), dovresti vedere sempre solo la varietà # 1 sopra (l'idea è che se i tuoi dati sono opportunamente normalizzati, i modelli di dati più utili richiederanno più join in quanto le entità sono state separate per eliminare le dipendenze transitive).

Per OLAP , tuttavia, le tue visualizzazioni dovrebbero far parte del tuo modello Data Warehouse / Data Mart . Esistono molte tecniche diverse su come eseguire questa operazione con la terminologia e le best practice consigliate che cambiano a seconda degli strumenti di Business Intelligence che si utilizzano. Il lungo e il breve tuttavia è che si stanno trasformando i dati (di solito attraverso viste dinamiche o materializzate) per creare un modello di dati che rende più facile per gli utenti finali estrarre informazioni. Il modo migliore per farlo ruoterà principalmente attorno al tipo di dati che stai utilizzando. Ma di nuovo i tuoi dati originali dovrebbero essere altamente normalizzati, quindi mi aspetterei molto più della varietà # 1 rispetto al # 2.

TL; DR : le migliori pratiche del database sono generalmente più accettate rispetto a una serie di schemi di progettazione disponibili per il DBA. Detto questo, probabilmente varrebbe la pena dedicare un po 'di tempo a leggere le pratiche generalmente accettate relative a Normalization , Data Warehousing , Data Marts , ETL e OLTP / OLAP .

Il primo caso crea un certo insieme di dati, il cui modello si differenzia dal database originale. Questo è probabilmente fatto allo scopo di leggere i dati in modo semplice da parte di terze parti che utilizza un modello simile o identico a quello della vista. Mi sembra un Adattatore per me.

Ciò che hai descritto nel secondo caso mi ricorda gran parte del Pattern di facciata

Fondamentalmente, semplifica l'interfaccia sottostante in qualcosa che è più facilmente leggibile dall'esterno. Nel tuo caso, hai un set di tabelle nel database che contengono i dati che vuoi presentare in un certo modo, facile da leggere, filtrare e interpretare. A tal fine, crei una vista che avvolge tutti quei dati, sparsi su più tabelle in un'unica vista, semplice, facile da leggere e da usare.