Utenti che richiedono un database denormalizzato

Question

Sono nelle prime fasi di sviluppo di un sistema basato su database e la maggior parte del sistema ruota attorno a una relazione di tipo ereditario.Esiste un'entità madre con circa 10 colonne e ci saranno circa 10 entità figlie che ereditano dall'entità madre.Ogni entità figlio avrà circa 10 colonne.Ho pensato che avesse senso dare all'entità genitore la propria tabella e dare a ciascuno dei figli le proprie tabelle: una struttura tabella per sottoclasse.

Oggi i miei utenti hanno chiesto di vedere la struttura del sistema che ho creato.Si sono opposti all'idea della struttura tabella per sottoclasse.Preferirebbero una grande tabella da circa 100 colonne perché sarebbe più semplice per loro eseguire le proprie query personalizzate.

Dovrei prendere in considerazione la denormalizzazione del database per il bene degli utenti?

Answer 1

Assolutamente no. È sempre possibile creare una vista più tardi per mostrare loro quello che vogliono vedere.

Answer 2

Stanno effettivamente chiedendo un rapporto.

Potresti dare loro l'accesso a una vista contenente tutti i campi richiesti...in questo modo non rovini il tuo modello di dati.

Answer 3

No. Strutturare i dati correttamente e se gli utenti hanno bisogno di una visione denormalizzato dei dati crearlo come vista nel database.

In alternativa, si consideri che forse un RDBMS non è lo strumento adeguato stoccaggio per questo progetto.

Answer 4

Sono gli utenti e non i programmatori del sistema per un motivo. Fornire un'interfaccia separata per le loro ricerche. Gli utenti esperti di questo tipo possono essere entrambi utili e un dolore da affrontare. Basta spiegare è necessario il database progettato in un certo modo in modo da poter fare il tuo lavoro, punto. Una volta che si è compiuta e fornire altri mezzi per rendere più facile l'esecuzione di query.

Answer 5

Che cosa sanno !? Si potrebbe obiettare che utenti non dovrebbe essere nemmeno dover accedere direttamente a un database in primo luogo.

In questo che lascia si apre a problemi di prestazioni di massa, solo perché un paio di utenti sono in esecuzione query ridicole.

Answer 6

Che ne dite se si è creato una visualizzazione in formato tuoi utenti volevano, pur mantenendo un tavolo correttamente normalizzata?

Answer 7

A parte un sacco di ragioni tecniche a favore o contro proposizione dei vostri utenti, è necessario essere sulla stessa pagina nel comunicare le conseguenze di vari scenarious e (soprattutto) le costi di queste conseguenze . Se gli utenti sono i tuoi clienti e che stanno pagando di fare un lavoro, spiegare che la loro terribile "proposte" idee può costare loro più soldi in tempo di sviluppo, risorse hardware supplementari, ecc

Speriamo che si può spiegare in modo tale che mostra le tue competenze e il motivo per cui la vostra idea è un valore molto migliore per gli utenti nel lungo periodo.

Answer 8

Come tutti più o meno detto, in questo modo si trova la follia, e si può sempre costruire una visione.

Se proprio non potete farli venire in giro su questo punto, mostrando loro considerano questa discussione e il numero di professionisti che ha pesato nel dire che gli utenti sono immischiarsi con le cose che non capiscono fino in fondo, e l'impatto sarà un fondamento minato.

Una grande parte del mestiere dello sviluppatore è la sensazione di ciò che non funziona fuori a lungo termine, e le regole di normalizzazione sono quasi canonica in questo senso. Ci sono situazioni in cui è necessario denormalizzare (data warehouse, ecc), ma questo non suona come uno di loro!

Sembra anche come se si può avere un marchio particolarmente preoccupante di utenza sulla tua mano - lo sviluppatore amatuer che pensa di poter fare il tuo lavoro meglio se stessi, se solo avessero il tempo. Questo può o non può aiutare, ma ho scoperto che questi tipi rispondono bene alla presentazione - un paio di volte ho trovato che se mi vesto tagliente e mostrare un po 'di forza nella mia personalità, che li aiuta a sentirsi come io sono un esperto e impedisce un sacco di problemi prima di iniziare.

Answer 9

Raccomando vivamente venire con una risposta che non coinvolge qualcuno che corre rapporti diretti contro il vostro database. Nel momento in cui accade, la vostra struttura DB è scolpito nella pietra e si può sostanzialmente considerare legacy.

Un punto di vista è un buon inizio, ma in seguito probabilmente vi vuole strutturare questo come esportazione, per disaccoppiare ulteriormente. Certo, poi si incontrano qualcuno che vuole i dati "tempo reale". Una corretta analisi di business in genere rivela che questo è inutile. requisiti in tempo reale reali non sono più gestite tramite sistemi di reporting.

Giusto per essere chiari: io personalmente preferisco la tabella per ogni approccio sottoclasse, ma non credo che in realtà è grande un problema come la segnalazione diretta off tabelle di transazione sta per essere

.

Answer 10

opterei per una vista (come altri hanno suggerito) oppure una funzione con valori di tabella in linea (i vantaggi di questo è si richiedono i parametri - come un intervallo di date o di un account cliente - che può aiutare a impedire agli utenti di interrogare, senza limiti al problema di spazio) prima. Una linea TVF è davvero una vista parametrizzata ed è molto più vicino a una vista in termini di come il motore li tratta di quello che è ad una tabella di funzione a valori multi-dichiarazione o di una funzione scalare, che può eseguire incredibilmente male.

Tuttavia, in alcuni casi, questo può influenzare il posizionamento di produzione se la vista è complesso o intensivo. Con mal scritto ad hoc query degli utenti, può anche causare blocchi di persistere più a lungo o essere aumentata ulteriormente di quanto farebbero su una query meglio costruito. E 'anche possibile per gli utenti di interpretare male un modello di dati E-R e producono numeri moltiplicati nei casi in cui ci sono molti-a-uno o molti-a-molti. L'opzione successiva potrebbe essere quella di concretizzare questi punti di vista con gli indici o fare tabelle e tenerli aggiornati, che ci si avvicina alla mia prossima opzione ...

Quindi, dato quegli inconvenienti del opzione di visualizzazione e già pensando di mitigare lo iniziando a fare copie dei dati, l'opzione successiva vorrei prendere in considerazione è quello di avere una versione separata di sola lettura (per questi utenti) dei dati che è strutturato diversamente. In genere, vorrei prima vedere uno schema a stella in stile Kimball. Non è necessario disporre di un data warehouse a tutti gli effetti nel tempo consistente. Naturalmente, questa è un'opzione, ma si può semplicemente tenere un modello di rendicontazione aggiornati con i dati. Star-schemi sono una forma speciale di denormalizzazione e sono particolarmente buoni per la segnalazione numerica, e una data stella non dovrebbero essere in grado di essere abusato dagli utenti accidentalmente. È possibile mantenere la stella fino ad oggi in vari modi, tra cui i trigger, i processi pianificati, ecc possono essere molto veloce per la segnalazione esigenze ed eseguire sullo stesso impianto di produzione - magari su un'istanza separata se non solo un database separato.

Anche se una tale soluzione può richiedere in modo efficace più di raddoppiare le tue esigenze di storage, se confrontato con altre pratiche che potrebbe essere una buona opzione se si capisce bene i dati e non dispiacerebbe avere due modelli - uno per le transazioni e uno per l'analisi (si noti che si sarà già iniziare ad avere questa separazione logica in ogni caso con l'uso di una semplice prima opzione di vista).

Alcuni architetti spesso raddoppiare i loro server e utilizzare il modello stesso con un qualche tipo di replica al fine di fornire un server di report che viene indicizzato più pesantemente o in modo diverso. Tale secondo server non influisce transazioni di produzione con obblighi di segnalazione e può essere tenuto aggiornato abbastanza facilmente. Ci sarà un solo modello, ma naturalmente, questo ha gli stessi problemi di usabilità con consentendo agli utenti l'accesso ad hoc al solo il modello di base, senza la prestazione colpisce, in quanto essi ottengono il loro parco giochi.

Ci sono un sacco di modi per la pelle questi gatti. Buona fortuna.

Answer 11

Il cliente ha sempre ragione. Tuttavia, il cliente è probabile che a fare marcia indietro quando si converte il loro requisito in dollari e centesimi . Una tabella 100 colonna richiederà tempo dev supplementari per scrivere il codice che fa quello che il database farebbe automaticamente con la corretta attuazione. Inoltre, i costi supporto sarà più alto da più codice indica più problemi e minore facilità di debugging.

Answer 12

In questo caso farò l'avvocato del diavolo e dirò che entrambe le soluzioni sembrano pessime approssimazioni dei dati reali.C'è una ragione per cui i linguaggi di programmazione orientati agli oggetti non tendono ad essere implementati con nessuno di questi modelli di dati, e non è perché le idee di Codd del 1970 sulle relazioni fossero il sistema ideale per archiviare e interrogare strutture di dati orientate agli oggetti.:-)

Ricorda che SQL è stato originariamente progettato come linguaggio dell'interfaccia utente (ecco perché assomiglia vagamente all'inglese e per niente come le altre lingue di quell'epoca:Algol, C, APL, Prolog).Le uniche ragioni che ho sentito per non esporre un database SQL agli utenti oggi sono la sicurezza (potrebbero bloccare il server!) e l'usabilità (chi vuole scrivere SQL quando puoi fare clic su clic?), ma se è il loro server e loro vogliono, allora perché non lasciarglielo fare?

Dato che "la maggior parte del sistema ruota attorno a un tipo di relazione ereditaria", prenderei seriamente in considerazione un database che mi consenta di rappresentarlo in modo nativo Postgres (se SQL è importante) o un database di oggetti nativi (con cui è fantastico lavorare, se non hai bisogno della compatibilità SQL).

Infine, ricorda che ogni decisione ingegneristica è un compromesso."Mantenendo le tue idee" (come ha proposto qualcun altro), stai implicitamente dicendo che il valore dei desideri dei tuoi utenti è zero.Non chiedere a SO una risposta corretta a questa domanda, perché non sappiamo cosa vogliono fare i tuoi utenti con i tuoi dati (o anche quali sono i tuoi dati o chi sono i tuoi utenti).Vai a spiegare loro perché desideri una soluzione con molte tabelle e poi trova con loro una soluzione che sia accettabile per entrambi.

Answer 13

Classe Table Inheritance e stanno chiedendo single Table Inheritance . Entrambi i modelli sono validi in determinate situazioni.

Si potrebbe desiderare di ottenere una copia di modelli di Martin Fowler di Enterprise Application Architecture per saperne di più sui vantaggi e gli svantaggi di ogni disegno. Quel libro è un riferimento classico per avere sul vostro scaffale, in ogni caso.