Est-ce le travail des programmeurs de concevoir la base de données?

Je suis programmeur depuis six ans. Tout au long de ma carrière, j'ai travaillé sur de nombreuses applications web.

La plupart du temps, lorsqu'une base de données était nécessaire, elle nous était donnée (aux programmeurs) ou nous avions une base de données héritée sur laquelle travailler. Sinon, nous avons dû créer et concevoir la base de données nous-mêmes, ce qui n'était pas si difficile.

Mais sommes-nous, en tant que programmeurs, censés créer la base de données entière à partir de zéro lorsque nous devons créer une nouvelle application où les données sont si importantes et ont des exigences compliquées avec un modèle de données complexe?

N'est-il pas dans le meilleur intérêt de l'application et de l'entreprise de le faire réaliser par un expert?

Je n'essaie pas de fuir la conception de la base de données, mais c'est quelque chose qui est si important de bien faire les choses.

Tout d'abord, c'est votre travail si le chef de projet vous le dit. Les petites entreprises n'ont souvent pas d'experts DB à plein temps. Il n'y a pas (et ne devrait pas y avoir) de distinction claire entre les développeurs et les experts DB de toute façon - tout bon développeur aura une connaissance considérable des bases de données, et tout bon DBA saura coder, au moins dans le langage de la base de données pour les procédures stockées .

Bien que la conception de la base de données soit une partie assez centrale d'une application, il n'est pas plus important de «bien faire» que les autres parties centrales dont dépendra beaucoup d'autres codes.

Et tout comme le code, l'idée que vous demandez à un super-expert de s'asseoir et de réfléchir longuement pendant une semaine, puis d'écrire le design parfait qui n'aura jamais besoin de changer est une illusion. La conception de la base de données peut changer et changera au fur et à mesure du développement de l'application.

Il est donc réellement avantageux de faire concevoir la base de données par un programmeur (qui comprend bien les bases de données), car alors vous avez quelqu'un qui connaît les deux côtés. C'est certainement mieux que de le faire par quelqu'un qui ne comprend que les bases de données et n'a rien à voir avec le reste du travail de développement.

Il est courant que les programmeurs créent la base de données. Très commun. Malheureusement, de nombreux programmeurs n'ont pas d'expérience avec la base de données. Ils ne comprennent pas comment effectuer des rapports sur les mégadonnées, les concepts de data marts, les schémas en étoile, etc. Certains ne comprennent même pas les bases de la normalisation.

Si un homme a les compétences pour tout faire à un niveau expert, cela fait un très bon produit. Une armée d'un seul homme peut faire ce qu'une équipe de 10 hommes peut faire en une fraction du temps avec 1000 fois la qualité. Pas une exagération.

Il est dans l'intérêt du programmeur de le faire (moins de personnes), en supposant que le programmeur sait ce qu'il fait. Bien sûr, il y a aussi des milliers d'échecs à signaler.

C'est une question intéressante - il y a un argument fort selon lequel la plupart des développeurs décents devraient comprendre comment structurer correctement une base de données relationnelle, c'est-à-dire qu'ils devraient être capables de produire un schéma normalisé et - sur la base de l'expérience et des modèles communs - de rendre raisonnable les décisions sur la façon dont les données doivent être structurées stockées (pour moi, cela va de soi, mais je sais que tout le monde ne les voit pas de cette façon).

De plus, si vous examinez Entity Framework Code-first, cela suggère que la même pensée qui va à la construction d'un modèle de données de bas niveau produira un schéma raisonnable - ou du moins un indice.

Donc non, je ne pense pas particulièrement que vous ayez besoin d'un expert en bases de données pour concevoir un schéma de base de données - du moins pas pour les bases de données de petite et moyenne taille (sur lesquelles j'ai travaillé).

Le problème est que la conception d'un bon schéma (ou au moins adéquat) n'est pas toute l'histoire - surtout pas si la base de données doit évoluer. Il me semble que la "valeur ajoutée" apportée par un administrateur de base de données réside dans l'obtention de choses autres que le schéma de base correct - les index, la configuration du stockage, la maintenance de la base de données (garder la taille des fichiers sous contrôle, reconstruire les index, etc.), être plus intelligent avec les utilisateurs et les rôles et ainsi de suite et ainsi de suite.

Un bon programmeur devrait apporter un portefeuille diversifié de compétences - devrait être plus qu'un codeur [insérer la langue de choix] et j'inclurais la compréhension des bases de données dans ce portefeuille.

Je pense que la capacité de concevoir une base de données relationnelle raisonnable est essentiellement une nécessité pour les programmeurs non débutants.

Cela dit, en particulier pour les applications de grande taille, il est essentiel de faire en sorte que la base de données soit «correcte» la première fois (schéma, indexation, etc.). Si l'entreprise a accès à un DBA qualifié, cette tâche devrait tomber dans son assiette; en général, ils seront plus qualifiés. Un examen / discussion potentiel devrait être fait avec le développeur principal qui accèdera et travaillera avec la base de données côté client afin qu'il n'y ait pas de surprise. S'il n'y a pas de DBA, le programmeur conçoit la base de données.

Je vois deux questions ici:

• Les développeurs de bases de données devraient-ils modéliser la logique métier?
• Dois-je savoir comment conserver les données dans la base de données?

Logique d'entreprise

• La logique métier ne réside pas dans une base de données. C'est un modèle conceptuel qui doit être indépendant des autres couches de votre système.

• Vous pouvez toujours remplacer une base de données par une autre, ou vous pouvez même décider d'utiliser une solution NoSQL pour résoudre les problèmes de performances potentiels.

• Les développeurs de bases de données peuvent être impliqués pendant le processus de modélisation, mais normalement cela est fait par des personnes ayant une compréhension complète d'un domaine problématique. Dans notre organisation, cela est fait par les développeurs côté serveur.

• Beaucoup pensent que la base de données est le fondement de votre application. Faites une mauvaise fondation et le système tombera. Je suis en désaccord avec cela. Je vois la base de données comme un support de stockage qui peut toujours être remplacé.

Données persistantes

• Vous devez savoir comment conserver les données sur différents supports de stockage, y compris les solutions SQL et NoSQL.

• Le niveau d'expertise requis variera selon la taille du système sur lequel vous travaillez.

• Les petites entreprises s'attendent à ce que vous ayez ces connaissances, alors que les grandes entreprises embauchent normalement des experts pour répondre aux exigences liées aux performances, à l'évolutivité et à la sécurité.

Pour résumer:

• Le modèle de domaine est le fondement de votre système, pas la base de données.

• Si vous travaillez pour une petite entreprise sur un projet relativement petit, vous devez probablement concevoir la base de données vous-même.

• Si vous travaillez pour une grande entreprise sur un système d'entreprise, il est probablement plus judicieux de confier le travail aux experts du domaine.