Sono sicuro che molti di voi hanno / hanno a che fare con un brutto database. Sai, quel database che non è affatto normalizzato, quel database in cui devi fare una grande query dolorosa per ottenere i dati più banali, quel database che è in produzione e non puoi cambiare un po '... sai , "quello".
La mia domanda è: come la gestisci?
Risposte:
La prima cosa che faccio è creare un diagramma entità-relazione (ERD). A volte puoi semplicemente descrivere i metadati con strumenti da riga di comando ma per risparmiare tempo ci sono alcuni strumenti che possono generare automaticamente un diagramma.
In secondo luogo, esamina ogni tabella e colonna per assicurarti di apprendere il significato di ciò che memorizza.
Terzo, esamina ogni relazione e assicurati di capire come le tabelle si relazionano tra loro.
In quarto luogo, leggi tutte le visualizzazioni o i trigger per comprendere l'applicazione personalizzata dell'integrità dei dati o le operazioni a cascata.
In quinto luogo, leggi tutte le procedure memorizzate. Leggi anche i privilegi di accesso SQL, se presenti.
In sesto luogo, leggere le parti del codice dell'applicazione che utilizzano il database. Ecco dove vengono applicate alcune regole aziendali aggiuntive e regole di integrità dei dati.
aggiornamento: ho appena letto un interessante articolo " 9 cose da fare quando si eredita un database " con una buona lista di controllo.
Sommario:
Questo non è sempre possibile, ma una cosa che ha funzionato per me in determinate situazioni è quella di sostituire alcune delle tabelle con le viste. È quindi possibile riordinare le tabelle sottostanti e in alcuni casi eventualmente eliminare le viste. Come ho detto, funziona solo in alcuni casi.
Il dizionario dei dati è tuo amico. Inoltre, prova a decodificare il database con lo strumento di decodificazione su Visio e crea il tuo set di diagrammi. Poiché il reverse engineering è interattivo - costruisci i diagrammi - è molto più coinvolgente che leggere un dizionario di dati. L'attività del processo è un vantaggio e trovo abbastanza rilassante farlo.
La maggior parte del lavoro che svolgo riguarda il data warehousing, in cui curiosare con gli schemi dei database del sistema di origine è un'attività fondamentale. Ho fatto questo genere di cose in diverse occasioni e ho scoperto che funziona davvero bene.
Visio pro non è così costoso e il motore di modellazione di Visio ti consente di condividere un modello tra più diagrammi. Come bonus, puoi aggiungere le chiavi esterne mancanti nei diagrammi e ottenere un utile set di documentazione per il sistema alla fine.
Oltre alle idee di Bill Karwin, suggerisco di parlare con gli utenti - a volte gli utenti sanno un po 'a cosa serve il loro database, specialmente se fanno qualsiasi segnalazione da esso.
Ho a che fare con uno molto brutto per il software di un fornitore, che oltre a dare suggerimenti, non posso fare molto per cambiarlo. Cerco sempre di cambiare le cose, ma poiché è al di fuori del mio controllo, sono bloccato con la spazzatura.
Una delle cose che ho iniziato rapidamente a utilizzare, poiché il database non ha assolutamente relazioni, è una query di nome generale per lo schema:
--Find Column named like 'blah' in a specific table
SELECT O.NAME, O.ID, C.NAME, O.XTYPE
FROM SYSOBJECTS O LEFT JOIN SYSCOLUMNS C ON O.ID=C.ID
WHERE C.NAME LIKE '%SearchFor%' AND O.XTYPE IN ('U','V') AND O.Name like '%TableName%'
ORDER by O.Nameo
--Find all Columns in DB with name like 'blah'
SELECT O.NAME, O.ID, C.NAME, O.XTYPE
FROM SYSOBJECTS O LEFT JOIN SYSCOLUMNS C ON O.ID=C.ID
WHERE C.NAME LIKE '%SearchFor%' AND O.XTYPE IN ('U','V')
ORDER by O.NameDal momento che alcune delle tabelle hanno troppe colonne con un nome mediocre e troppe colonne per cercare ciò che potrei essere in grado di usare per formare relazioni tra le tabelle.
So che questo non aiuta molto nella riprogettazione della domanda, ma è molto utile per comprendere e decifrare lo schema errato.
SchemaCrawler è il mio strumento di individuazione del database che ha un paio di funzionalità che facilitano l'esplorazione di un brutto database. SchemaCrawler ha una funzionalità simile a "grep", che consente di cercare tabelle e colonne usando espressioni regolari. Ad esempio, potresti cercare tabelle e colonne con "ACCOUNT" come parte del loro nome e probabilmente verrebbero correlati in qualche modo.
SchemaCrawler influenza anche le relazioni con le chiavi esterne, anche dove non ci sono chiavi esterne. Lo fa trovando "associazioni deboli" usando convenzioni di denominazione comuni, come le tabelle sono i nomi sono solitamente plurali, ma i nomi delle colonne non lo sono e i nomi delle colonne possono avere un prefisso _ID. È possibile trovare tabelle correlate utilizzando queste relazioni dedotte.
Dipende da quanto è brutto e da quanto controllo hai sul design e su cosa interagisce con esso. Nel corso del mio attuale lavoro ho dovuto interagire con una serie di brutti database, ed ecco come li ho gestiti:
Dati dei dipendenti
C'è il database che contiene i dati dei dipendenti. È un database di fornitori, quindi non ho alcun controllo su di esso. (Un?) Per fortuna, non ho accesso diretto ad esso. Ricevo una discarica DTS ogni mattina.
La cosa migliore che sono stato in grado di gestire è scrivere uno script che scrubba l'input dal dump mattutino (sì, quella scelta delle parole era intenzionale) e la migra in un formato più utile e lavora dai dati cancellati.
Anche se potessi cambiarlo, probabilmente non lo farei - solo perché ci sono molti altri programmi che si basano sul fatto che sia impostato così com'è, e non posso forzare un cambiamento in essi.
Dati di addestramento online
Questo era un disastro del mio stesso design. L'ho costruito appena uscito dal college senza un mentore per aiutarmi ... Da allora l'ho risolto un po 'alla volta. Dal momento che controllo l'unico programma che accede ai dati, mentre aggiorno parti del sito "aggiornerò" la configurazione del database. Scriverò uno script di trasformazione e lo testerò vigorosamente su una copia in modo da poter garantire che tutte le modifiche che devono essere apportate vengano apportate.
È stato un processo lungo, ma sta procedendo bene.
Dati di addestramento in classe
Il mio progetto pilota ha integrato i dati di 3 diversi database, tutti progettati in modo leggermente diverso dal mio predecessore ... che era un educatore infermiere che ha seguito una o due lezioni di programmazione.
È stato un altro processo lento. Dal momento che ho il pieno controllo dei programmi che accedono ai dati, lo sto cambiando a poco a poco come i dati di addestramento online.
Col senno di poi, questo sarebbe stato un candidato privilegiato per iniziare pulito ... la vista posteriore è sempre 20/20.
Alla fine...
Non so quanto sia stato utile, e posso elaborarne di più (a un certo punto, yada yada legale della società e tutto il resto). La risposta finale è "Dipende".
Quindi dopo aver letto tutte le tue risposte, ti do le mie:
Prima cerco la "Tabella principale", quindi, con carta e penna, inizio a mappare le relazioni con altre tabelle, dopodiché, se c'è un codice app da guardare, inizio a fare degli schizzi grezzi sul modo in cui i dati scorrono.
Dopo aver fatto una bella foto su come funziona il db, comincio a cercare i luoghi in cui cambiare le cose. Questo è tutto.
Non so perché, ma preferisco la carta rispetto a qualsiasi software di modellazione di database.
A causa dell'utilizzo da parte di un'applicazione esterna non è possibile modificare "l'interfaccia" del database. Non so che tipo di database stai usando (oracle, mysql, mssql), ma vedo questo come uno dei modi:
Viste, le procedure memorizzate nasconderanno le modifiche (modifiche) ai database interni.
Oltre a scoprire la struttura del database, ho scoperto che è anche importante esaminare la qualità dei dati . Una volta compreso il significato di ogni colonna, puoi cercare tutti i luoghi in cui sono presenti molti valori mancanti. Man mano che acquisisci familiarità con i dati, puoi anche esaminare dove ci sono incoerenze tra i valori in colonne diverse.
Dipende da come devi interagire. Per gli scenari di utilizzo in cui il batching è accettabile, ho trovato spesso abbastanza conveniente (in termini di tempo di sviluppo e quindi costi per il cliente) raggruppare i dati in una struttura più amichevole e contrastare.
Se riesci a segmentare il problema in problemi che possono avvolgere il tuo cervello, puoi attaccarli uno alla volta. A volte, solo sapere che c'è un tavolo che non è tutto incasinato può darti una testa di mare su cui lavorare. In questo modo, estendi il tuo "punto pulito" per includere più parti del database in blocchi.
Se hai Visio (parte di Microsoft Office) puoi provare la funzione di reverse engineering . Non è carino, ma almeno ti darà un inizio (a una frazione del costo di strumenti "reali" come Rational Rose).
Schema Spy è uno strumento davvero interessante per generare un ERD.
Bill ha dato una risposta eccellente. Aggiungerei che accederei all'interfaccia utente come utente di prova e proverei a capire esattamente cosa fanno gli utenti con i dati. Ti aiuterà a capire il perché di alcuni processi o progetti memorizzati. Comprendere il significato e l'utilizzo dei dati è fondamentale per comprendere un database.
Se il database è su una funzione aziendale o su un argomento di cui in genere non hai familiarità (ad esempio, pianifica il volo e in precedenza hai lavorato solo su applicazioni finanziarie), chiedi agli utenti del materiale di lettura sull'argomento o vai in biblioteca te stesso o cerca in Internet sull'argomento. Chiedi agli utenti se ci sono problemi legali o normativi di cui devi essere consapevole. Ancora una volta alcuni di questi argomenti potrebbero spiegare quali sembrano essere strane scelte di design.
Se si tratta di un database del fornitore (e ne ho visti di veramente brutti) tutto ciò che puoi fare è lamentarti con il fornitore.
Per le applicazioni che sono costruite internamente, di solito basta un po 'di educazione per gli sviluppatori e puoi iniziare a cambiare lo schema in modo che le prestazioni migliorino. Ci vuole tempo e di solito è un processo lento.
Nella mia esperienza, la creazione di un nuovo database non è in realtà un'opzione, poiché lo spostamento di centinaia di GB o TB di dati non è poi così fattibile.
Lasciando da solo anche di solito non è un'opzione. Man mano che la quantità di dati nel database aumenta, le prestazioni peggioreranno sempre più (garantite dal momento in cui vedo i problemi, di solito sono piuttosto dannose). Alla fine gli utenti non saranno in grado di utilizzare l'applicazione perché le prestazioni sono così pessime.
Ah ... il brutto database, più grande è l'impresa, più database legacy troveremo.
Non funziona sempre, ma se non ci impegniamo, non farà che peggiorare. Cerco di ridisegnare i database insieme alle applicazioni, potrebbe aggiungere più lavoro per me con la migrazione dei dati, ma le prestazioni sono un trucco magico che estraggo sempre dal mio cappello.
Buona fortuna con la tua brutta amica;)
Verifica se l'opzione di una sessione di trasferimento delle conoscenze è disponibile per te e, in tal caso, sfruttale al massimo.
Inoltre, molti DBMS sono dotati di strumenti che consentono di disegnare / stampare lo schema del database con alcune informazioni utili (ad esempio chiavi esterne).
Inoltre, (rubato da NXC) è possibile decodificare il database tramite strumenti come Visio.
Mi piace avviare un profiler di query e guardare cosa succede su un sistema di produzione. Mi dà un'idea di quali tabelle sono "calde" e il tipo di query che ci sono contro di loro.
Inserire una copia di backup su un server sandbox e quindi iniziare a scrivere ed eseguire query di prova. Trovo sempre un sistema complesso più facile da capire se riesco a metterci le mani sopra e non preoccuparmi di romperlo.
Inoltre, mi piace avere The Daily WTF aperto in una finestra del browser. Prendere il controllo di qualcun altro di solito comporta molti momenti "Non posso credere che abbiano fatto {WTF}" e aiuta ad avere un posto dove andare dove le persone capiscono il tuo dolore.