Wow - hai un progetto ambizioso davanti a te. Determinare ciò che è un buon progetto di database può essere impossibile, tranne che per principi e linee guida ampiamente compresi.
Ecco alcune idee che mi vengono in mente:
Io lavoro per una società che fa di gestione di database per alcune grandi imprese di vendita al dettaglio. Disponiamo di database personalizzati progettati per ciascuna di queste società, in base a come intendono utilizzare i dati (per la posta diretta, le campagne di posta elettronica, ecc.) E il tipo di parametri di analisi e selezione che preferiscono utilizzare. Ad esempio, un'azienda che vende attrezzature musicali nei negozi e online vuole distinguere tra clienti walk-in e online, classifica i clienti in base al tipo di articoli acquistati (batteria, chitarre, microfoni, tastiere, strumenti di registrazione, amplificatori, ecc.) e tenere traccia di quanto hanno speso e di ciò che hanno acquistato, negli ultimi 6 mesi o nell'ultimo anno. Usano queste informazioni per decidere chi riceverà i cataloghi per posta. Questi mailing sono molto costosi; forse uno o due dollari per cliente, quindi la compagnia vuole spedire i cataloghi solo a quelli che sono più propensi ad acquistare qualcosa. Possono avere 15 milioni di clienti nel loro database, ma solo 3 milioni comprano la batteria, e solo 750.000 hanno acquistato qualcosa nell'ultimo anno.
Se dovessi analizzare il database che abbiamo creato, troverai molte tabelle "di lavoro", che sono utilizzate per specifici scopi di selezione, e che potrebbero non essere effettivamente progettate correttamente, secondo i principi di progettazione del database. Mentre le tabelle "principali" sono progettate in modo efficiente e hanno relazioni e indici corretti, queste tabelle "di lavoro" farebbero sembrare che l'intero database sia mal progettato, quando in realtà le tabelle di lavoro possono essere utilizzate solo poche volte o addirittura solo una volta, e non siamo ancora entrati per eliminarli o lasciarli cadere.Le tabelle di lavoro superano di gran lunga le tabelle principali in questo particolare database.
Si deve anche tenere conto del volume dei dati gestiti. Una base clienti di 10 milioni può avere una numerazione dei dati delle transazioni da 10 a 20 milioni di transazioni a settimana. O al giorno. A volte, per gestibilità, questi dati devono essere suddivisi in partizioni in tabelle per intervallo di date, quindi una visualizzazione verrà utilizzata per selezionare i dati dalla tabella secondaria appropriata. Questo è efficiente per questo volume enorme, ma può sembrare ripetitivo per un analizzatore automatico.
L'analizzatore dovrebbe essere configurabile dall'utente prima dell'inizio dell'analisi. Alcuni articoli devono essere saltati, mentre altri possono essere assolutamente critici.
Inoltre, come si analizzano le stored procedure e le funzioni definite dall'utente, ecc.? Ho visto un codice davvero brutto che funziona in modo abbastanza efficiente. E, alcuni dei codici più brutti e inefficienti sono stati scritti solo per un uso singolo.
OK, non ho idee per il momento. Buona fortuna con il vostro progetto.
Per motivi di interesse, che altro si può fare che cercare moduli normali? Ci sono molte ottimizzazioni, che dipendono dall'uso, quindi suppongo che senza alcune domande non si possa veramente capire se qualcosa è ottimale o no, giusto? –
Quello che troverei più interessante è la domanda se troverai effettivamente molti schemi "da intermedio a cattivo" con progetti open source ragionevolmente ben noti e sviluppati attivamente, o se gli schemi errati migliorerebbero rapidamente nel mondo open-source. – stakx
non saranno migliorati rapidamente perché dovresti riscrivere tonnellate di codice, il che significa che è complicata la migrazione di un'istanza esistente. E una volta che la malattia si è diffusa, stai scrivendo hack sempre;) – sled