Chi progetta i database nello sviluppo web? [chiuso]

La tua domanda non è pertinente solo per le applicazioni web, ma per tutti i tipi di app che utilizzano un back-end del database.

Nella mia esperienza

• Il design del database è il lavoro combinato di sviluppatori e DBA.
• Gli sviluppatori creano progetti di database grezzi o spesso molto validi. Tutto dipende dall'esperienza dei programmatori.
• Spesso gli sviluppatori creano tabelle nel loro database di sviluppo e un modello concettuale viene decodificato da esso.
• Spesso i diagrammi ER concettuali vengono discussi con altri membri del team, spesso con i clienti. In questa fase vengono rilevati ovvi errori concettuali e, si spera, risolti e risolti.
• Il lavoro del DBA consiste nel rivedere un tale progetto e perfezionarlo per rilevare violazioni di forme normali.
• Anche il DBA applica le convenzioni di denominazione di tabelle e colonne
• Anche il DBA prevede possibili colli di bottiglia nelle prestazioni e cerca di capire come verranno interrogati i dati al fine di creare indici appropriati più tardi.
• Il ciclo di revisione / controllo / fissaggio tra sviluppatore / progettista di app e DBA passa attraverso diverse iterazioni fino a quando il modello non è sufficientemente maturo per generare un modello fisico.
• Solitamente uno strumento di progettazione di database viene utilizzato in tutti i database, tranne quelli molto piccoli, per aiutare questo processo.

Bottom-line:

• Gli sviluppatori conoscono meglio il dominio aziendale e dei problemi rispetto agli amministratori di database, quindi svolgono gran parte del progetto iniziale e, a seconda dell'esperienza dello sviluppatore, un tale design può essere molto vicino al progetto finale.
• Il ruolo del DBA è principalmente quello di garantire NF, convenzioni di denominazione, considerazioni sulle prestazioni, correggere errori evidenti e infine generare un modello fisico, quindi uno script specifico del database e eseguirli per creare il database.
• Direi che l'80% degli sviluppatori e il lavoro di analisi dei requisiti e il 20% di DBA funzionano.

UPDATE:

Esistono 3 tipi di DBA:

• DBA di sviluppo che conoscono la modellazione dei dati, sono esperti SQL e possono scrivere stored procedure, di solito sono ex sviluppatori;
• DBA di produzione specializzati nell'installazione, nel tunning delle prestazioni, nei backup e nel ripristino, ecc.
• e DBA di tutti i traffici che hanno lavorato facendo tutte quelle cose e come tale possono fare di più (sono pochissimi).

La maggior parte degli amministratori di database sono DBA di produzione, il che è bello perché sono i ragazzi che recuperano i database persi dagli array di dischi guasti nelle prime ore della notte. Ma non partecipano attivamente al processo di progettazione.

Dipende da cosa viene utilizzato il database.

In molte applicazioni (app web o no), il database è intimamente legato a quell'applicazione perché funge da archivio permanente per esso. Quindi il database è concettualmente parte dell'applicazione, quindi è progettato insieme (e si presume che nessun altro programma significativamente possa accedere o aggiornare quel database). BTW, la persistenza potrebbe essere ottenuta con altri mezzi oltre a un database, ad es. semplici file di testo, file binari (in particolare file indicizzati alla GDBM ), git (o altri VCS) repository, directory o file tree, partizioni del disco raw, hardware dedicato (es. flash), file system remoti, checkpointing . Per i database progettati per e con una sola applicazione, dovresti preoccuparti del recupero e dell'ampliamento comuni; aggiorna i modelli e progetta lo schema del database (e l'indicizzazione!) con loro in mente.

In alcune situazioni il database è di per sé una risorsa importante e indipendente, ed è progettato a priori per essere utilizzato da diverse diverse applicazioni (e anche da quelle future). Quindi dovrebbe essere progettato in modo indipendente (e molto più attentamente).

In particolare alcune app Web sono solo interfacce Web per database esistenti.

In molti casi (si pensi ad alcuni wiki come esempio), i dati sono più importanti e più preziosi delle applicazioni che li usano. Potresti preoccuparti di come renderlo futuro ed essere in grado di evolvere facilmente (ad esempio utilizzando o definendo formati testuali e versatili, preferibilmente standardizzati e documentati per il backup e il ripristino).

I've realized that the (PROPER) design of a database is no small task...

Leggi anche su NoSQL , database orientati ai documenti , database di valori-chiave , gestione della conoscenza , rappresentazione della conoscenza e ragionamento , ontologie , sistemi esperti , approccio delle regole aziendali , ERP , CMS . Forse considera l'utilizzo di REDIS , MongoDB , ecc.