Qui conçoit les bases de données dans le développement Web? [fermé]

Dans le cadre du développement web, qui conçoit les bases de données? Malgré une multitude d'informations associant le développement Web back-end au traitement côté serveur, à la modélisation des données, etc., l'aspect de la conception de la base de données de l'équation semble mystérieusement absent.

Je ne parle pas de qui met en place la base de données physique, je fais référence à qui conçoit le modèle logique de la base de données, mène des interviews d'utilisateurs pour obtenir des informations sur les champs nécessaires, quelles sont ces spécifications de champ, etc. .

J'ai réalisé que la conception ( APPROPRIÉE ) d'une base de données n'est pas une mince tâche (je lis ce téléavertisseur 672) et pourrait facilement être une profession entière. Cependant, la recherche de haut en bas sur Internet a conduit à étonnamment peu de résultats pour qui devrait gérer cette tâche dans le contexte du développement Web.

Votre question concerne non seulement les applications Web, mais également toutes sortes d'applications utilisant un backend de base de données.

Dans mon expérience

• La conception de la base de données est le travail combiné des développeurs et des administrateurs de base de données.
• Les développeurs font des conceptions de bases de données approximatives, ou souvent très bonnes. Tout dépend de l'expérience des programmeurs.
• Souvent, les développeurs créent des tables dans leur base de données de développement et un modèle conceptuel en est inversé.
• Souvent, les diagrammes ER conceptuels sont discutés avec d'autres membres de l'équipe, souvent des clients. À ce stade, des erreurs conceptuelles évidentes sont détectées et, espérons-le, résolues et corrigées.
• Le travail du DBA consiste à revoir une telle conception et à la peaufiner pour détecter les violations des formes normales.
• Le DBA applique également les conventions de dénomination des tables et des colonnes
• Le DBA envisage également les goulots d'étranglement possibles et essaie de comprendre comment les données seront interrogées afin de créer des index appropriés ultérieurement.
• Le cycle de révision / vérification / correction entre développeur / concepteur d'application et DBA passe par plusieurs itérations jusqu'à ce que le modèle soit suffisamment mature pour générer un modèle physique.
• Habituellement, un outil de conception de base de données est utilisé dans toutes les bases de données, sauf les très petites, pour faciliter ce processus.

Conclusion:

• Les développeurs connaissent mieux l'entreprise et le domaine problématique que les administrateurs de base de données, ils effectuent donc la majeure partie de la conception initiale et, selon l'expérience du développeur, une telle conception peut être très proche de la conception finale.
• Le rôle du DBA est principalement d'assurer la NF, les conventions de dénomination, les considérations de performances, de corriger les erreurs évidentes et enfin de générer un modèle physique, puis un script spécifique à la base de données, et de les exécuter pour créer la base de données.
• Je dirais que c'est 80% de travail de développement et d'analyse des exigences et 20% de travail DBA.

MISE À JOUR:

Il existe 3 types de DBA:

• DBA de développement qui connaissent la modélisation des données, sont des experts SQL et peuvent écrire des procédures stockées, ils sont généralement d'anciens développeurs;
• DBA de production spécialisés dans l'installation, l'optimisation des performances, les sauvegardes et la restauration, etc.,
• et les administrateurs de bases de données polyvalents qui ont travaillé à faire toutes ces choses et en tant que tels peuvent faire le plus (ils sont très peu).

La plupart des DBA sont des DBA de production, ce qui est une bonne chose car ce sont les gars qui récupèrent les bases de données perdues à partir de baies de disques défaillantes dans les petites heures de la nuit. Mais ils ne participent pas activement au processus de conception.

Cela dépend à quoi sert la base de données.

Dans de nombreuses applications (applications Web ou non), la base de données est intimement liée à cette application car elle lui sert de magasin permanent. Ensuite, la base de données fait théoriquement partie de l'application et est donc conçue ensemble (et vous supposez qu'aucun autre programme n'accèdera ou mettra à jour de manière significative cette base de données). BTW, la persistance pourrait être obtenue par d'autres moyens qu'une base de données, par exemple des fichiers de texte brut, des fichiers binaires (notamment des fichiers indexés à la GDBM ), des référentiels git (ou d'autres VCS), des répertoires ou des arborescences de fichiers, des partitions de disque brutes, du matériel dédié (par exemple flash), systèmes de fichiers distants, checkpointingtechniques. Pour les bases de données conçues pour et avec une seule application, vous devez vous soucier des modèles de récupération et de mise à jour courants et concevoir le schéma de la base de données (et l'indexation!) En pensant à eux.

Dans certaines situations, la base de données est en soi un atout majeur et indépendant, et est conçue a priori pour être utilisée par plusieurs applications différentes (et même futures). Ensuite, il doit être conçu indépendamment (et beaucoup plus soigneusement).

En particulier, certaines applications Web ne sont que des interfaces Web vers des bases de données existantes.

Dans de nombreux cas (pensez à un wiki comme exemple), les données sont plus importantes et plus précieuses que les applications qui les utilisent. Vous pouvez vous soucier de la façon de le rendre pérenne et de pouvoir l’évoluer facilement (par exemple, en utilisant ou en définissant des formats textuels et polyvalents - de préférence standardisés et documentés - pour le sauvegarder et le restaurer).

J'ai réalisé que la conception (APPROPRIÉE) d'une base de données n'est pas une mince affaire ...

Lisez également sur NoSQL , les bases de données orientées documents , les bases de données de valeurs-clés , la gestion des connaissances , la représentation et le raisonnement des connaissances , les ontologies , les systèmes experts , l'approche des règles métier , l' ERP , le CMS . Pensez peut-être à utiliser REDIS , MongoDB , etc.