Chi progetta database nello sviluppo web? [chiuso]

Nel contesto dello sviluppo web, chi progetta database? Nonostante tutta una serie di informazioni che associano lo sviluppatore web back-end all'elaborazione lato server, alla modellazione dei dati e simili, l'aspetto dell'equazione di progettazione del database sembra misteriosamente assente.

Non sto parlando di chi configura il database fisico, mi riferisco a chi progetta il modello logico del database, conduce interviste di user story per ottenere informazioni su quali campi sono necessari, quali sono quelle specifiche di campo e così via. .

Mi sono reso conto che la progettazione ( PROPER ) di un database non è un compito da poco (sto leggendo questo cercapersone 672) e potrebbe facilmente essere un'intera professione. Tuttavia, la ricerca su e giù su Internet ha portato a risultati sorprendentemente scarsi per chi dovrebbe gestire questo compito nel contesto del web dev.

La tua domanda non è pertinente solo alle webapp, ma a 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 realizzano progetti di database approssimativi o spesso molto validi. Tutto dipende dall'esperienza dei programmatori.
• Spesso gli sviluppatori creano tabelle nel loro database di sviluppo e da esso viene invertito un modello concettuale.
• Spesso i diagrammi ER concettuali vengono discussi con altri membri del team, spesso clienti. In questa fase vengono rilevati errori concettuali evidenti, che si spera vengano individuati e corretti.
• Il lavoro del DBA è quello di rivedere un tale progetto e perfezionarlo per rilevare violazioni delle forme normali.
• Anche il DBA applica le convenzioni di denominazione di tabelle e colonne
• Inoltre, il DBA prevede possibili colli di bottiglia delle prestazioni e cerca di capire come verranno interrogati i dati al fine di creare indici appropriati in un secondo momento.
• Il ciclo di revisione / controllo / correzione tra sviluppatore / progettista di app e DBA passa attraverso diverse iterazioni fino a quando il modello non è abbastanza maturo per generare un modello fisico.
• Di solito uno strumento di progettazione di database viene utilizzato in tutti i database, tranne in quelli molto piccoli, per aiutare questo processo.

Linea di fondo:

• Gli sviluppatori conoscono il business e il dominio dei problemi meglio dei DBA, quindi fanno gran parte della progettazione iniziale e, a seconda dell'esperienza dello sviluppatore, tale progettazione può essere molto vicina alla progettazione 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 ed eseguirli per creare il database.
• Direi che è l'80% di lavoro di analisi dei requisiti e degli sviluppatori e il 20% di lavoro DBA.

AGGIORNARE:

Esistono 3 tipi di DBA:

• DBA di sviluppo che conoscono la modellizzazione dei dati, sono esperti di SQL e possono scrivere procedure memorizzate, di solito sono ex sviluppatori;
• DBA di produzione specializzati in installazione, ottimizzazione delle prestazioni, backup e ripristino, ecc.,
• e DBA tuttofare che hanno lavorato facendo tutte quelle cose e come tali possono fare di più (sono pochissimi).

La maggior parte dei DBA sono DBA di produzione, il che è un bene perché sono i ragazzi che recuperano database persi da array di dischi falliti 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 meno), il database è intimamente legato a tale 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 acceda o aggiorni in modo significativo quel database). A proposito, la persistenza potrebbe essere ottenuta con mezzi diversi da un database, ad esempio file di testo semplici, file binari (in particolare file indicizzati alla GDBM ), repository git (o altri VCS), directory o alberi di file, partizioni di dischi grezzi, hardware dedicato (ad es. flash), file system remoti, checkpointtecniche. Per i database progettati per e con una sola applicazione, è necessario preoccuparsi dei modelli di recupero e aggiornamento comuni e progettare lo schema del database (e l'indicizzazione!) Tenendo conto di questi.

In alcune situazioni il database è di per sé una risorsa importante e indipendente ed è progettato a priori per essere utilizzato da diverse applicazioni (e anche 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 alcune wiki come un esempio), i dati sono più importanti e più preziosi delle applicazioni che li usano. Potresti preoccuparti di come renderlo a prova di futuro ed essere in grado di evolverlo facilmente (ad esempio utilizzando o definendo formati testuali e versatili, preferibilmente standardizzati e documentati) per il backup e il ripristino).

Mi sono reso conto che la progettazione (PROPER) di un database non è un compito da poco ...

Leggi anche NoSQL , database orientati ai documenti , database di valori-chiave , gestione della conoscenza , rappresentazione e ragionamento delle conoscenze , ontologie , sistemi esperti , approccio alle regole di business , ERP , CMS . Forse prendere in considerazione l'utilizzo di REDIS , MongoDB , ecc.