Buone pratiche di progettazione di database [chiusa]

Iniziamo con la mancanza di FK / PK. Esegui alcune ricerche per vedere se riesci a trovare dati orfani o dati duplicati. Una volta che puoi mostrare quanto sia pessima l'integrità dei dati, sei in una posizione migliore per proporre un piano di pulizia e l'istituzione di FKS. Se non riesci a trovare alcun record orpahned (dato quello che hai detto, lo troverei altamente improbabile), questo potrebbe non essere il miglior punto di partenza.

Successivamente, inizia con le query con il rendimento peggiore che sarei sorpreso di trovare sono basate su cose come il TVF che chiama altri TVF o viste che chiamano altre visualizzazioni.

Ora prendine una e progetta i dati nel modo in cui vorresti vederli memorizzati e mostra quanto è più facile interrogare e quanto più veloce è la query. Una volta che hai un track record per miglioramenti che funzionano, le persone saranno più propense ad ascoltarti.

Inizia con le cose peggiori da un punto di vista di prestazioni, sicurezza e integrità dei dati.

Un buon libro da leggere è: link

Ti aiuterà a progettare un sistema per migliorare il pasticcio un po 'alla volta.

Esistono validi motivi per inserire la business logic in un database, quindi è meglio aspettare di avere più informazioni. È possibile che vengano utilizzati alcuni strumenti di reporting che non possono utilizzare una logica complessa o che devono essere condivisi da app al di fuori del loro controllo.

Quali problemi sono causati dalla mancanza di normalizzazione e dall'uso di chiavi esterne?

Tutto questo alla fine viene soppesato dal dover refactoring questo database. Hai mai dovuto refactoring un database grande e complesso? Forse quei nomi non sono così male dopotutto.

C'è qualche miglioramento che potresti implementare (e testare a fondo) che mostrerebbe un valore immediato per l'azienda o il cliente, correggendo anche almeno uno dei problemi di qualità che stai vedendo? Se è così, proponi quel cambiamento - o, meglio ancora, volontario per dimostrare l'efficacia del cambiamento in un ambiente di test.

Inoltre, se hai le conoscenze e le competenze per essere un modellatore di dati o un DBA e hai interessi in questo senso, puoi parlare con il tuo manager della necessità del ruolo e del tuo interesse nel realizzarlo .

se il database soddisfa le loro esigenze di business e hai sviluppatori che possono modificarlo secondo necessità per soddisfare le mutevoli esigenze, è già buono come vorrei spingere per il nuovo ragazzo. Se è possibile identificare alcune aree che potrebbero utilizzare miglioramenti (non una lista esaustiva) e condividerle con i colleghi e cercare di convincerli a parlare con i manager, o almeno far loro sapere che intendete menzionare queste cose.

le modifiche al database sono enormi e probabilmente il posto migliore per avere una mentalità "se non è stato rotto non aggiustarlo"

Penso che dipenda da cosa intendi quando dici qualità. Ad esempio, quando un ingegnere dice Qualità, significa "fa ciò che deve fare, dura a lungo e fallisce in modo responsabile".

Gli sviluppatori di software sembrano pensare più alla falsariga di "è facile da capire e cambiare". Gli ingegneri tendono verso il "grande design in avanti" e non hanno la mentalità di rendere più semplice il cambio in seguito.

I tuoi colleghi parlano di qualità agli occhi dell'utente finale. Sono orgogliosi del fatto che gli utenti ritengano che il sistema sia solido, ben supportato, facile da usare, ecc. Se l'utente non guarda mai le tabelle del database, la denominazione delle tabelle in realtà non influisce sulla misura della qualità.