Meilleures pratiques en matière de conception de base de données
Je connais assez bien SQL Server, MySQL, Oracle, etc., mais, mis à part ces produits de base de données, existe-t-il une ressource qui m'aidera à bien concevoir des bases de données relationnelles? Existe-t-il des modèles ou des meilleures pratiques pour la conception de bases de données?
J'ai vu à quelques reprises que la base de données n'est souvent pas évolutive; les gens ont des préférences personnelles en conservant des colonnes telles que la colonne isChecked, qui est de nature booléenne mais stockée sous la forme Char (1) avec des valeurs telles que 'Y' et 'N' au lieu de 0 et 1, ce qui me semble meilleur. Des moyens de ne pas commettre d'erreurs courantes lors de la conception de bases de données?
Les liens vers des livres ou des articles seront très appréciés.
Merci d'avance.
Quelques points:
- Apprenez le plus possible sur le domaine problématique . Vous ne pouvez pas créer un bon modèle de données sans savoir ce que vous concevez
- Avoir de bonnes connaissances sur les types de données fournies par votre fournisseur de base de données
- Comment utiliser correctement la normalisation et les tables de calcul
- Performances: quand et comment appliquer index , comment écrire des requêtes efficacesetc.
- Quand et comment utiliser différents objets de base de données tels que vues, procédures, fonctions, déclencheurs
Il existe de nombreux modèles de conception de base de données. Elles ne sont pas souvent bien formalisées, vous devrez donc peut-être simplement regarder beaucoup de bases de données.
Voir, par exemple, les livres de Fowler sur les modèles de conception. Aussi Nock's Book .
Il existe des blogs, comme programmeur de base de données .
Il existe un livre IEEE intitulé On Pattern Pattern-Based Database Design and Implementation .
La recherche Google ( link ) a généré 24 millions de résultats.
Mon point de vue sur le sujet est quelque peu contrariant ... Je conseillerais de ne pas trop insister sur la conception de la base de données.
Parfois, cela peut être difficile. Avec les applications métier internes, la vision prédominante de l’activité est souvent le moment où la base de données est l’actif principal, alors que le logiciel est quelque peu extensible.
Mon conseil serait: ne l'achetez pas.
En réalité, l'actif est la capacité de l'entreprise à interagir avec les données. Pour le visualiser, le manipuler et prendre des décisions en fonction de celui-ci.
Cela signifie que même s'ils accordent une grande valeur aux données, ce qu'ils valorisent en réalité, ce sont les logiciels que vous écrivez.
Cela signifie que je concentrerais l'essentiel de vos efforts sur la création d'une expérience utilisateur efficace, plutôt que sur "la conception de la base de données parfaite". La base de données n'est en réalité qu'un outil qui vous permet de fournir une expérience utilisateur.
La caractéristique principale des modèles de données relationnels est l’indépendance des données et du chemin d’accès. Vous pouvez ajouter des colonnes, modifier des clés, introduire ou supprimer des index, etc. sans avoir d'impact (ou presque) sur les applications qui l'utilisent.
Cela rend la structure de la base de données extrêmement flexible.
Essayer de concevoir la base de données pour "être flexible pour le futur" ou pour "optimiser les performances" est essentiellement un effort inutile.
Changer la structure de la base de données aura un impact relativement faible sur votre système.
En outre, vous ne pouvez vraiment pas prédire comment la base de données évoluera jusqu'à ce que vous rencontriez les scénarios où vous devez le faire. Votre meilleur pari est d'attendre que vous rencontriez des problèmes de performances. et ensuite les aborder spécifiquement.
Toutefois, apporter des modifications à l'expérience utilisateur de votre application coûte généralement plus cher. Le travail d’assurance-chômage prend beaucoup de temps et prend généralement un certain temps pour réussir.
Donc, je vous recommanderais:
- Il suffit de produire une conception de base de DB merdique
- Réagissez aux scénarios de performance que vous rencontrez
- Concentrez vos efforts sur l'expérience utilisateur et non sur la base de données
Pour contrer le conseil de Dillie-O. Je suggère que vous ne mettez pas toutes vos recherches dans une seule table. En général, il s'agit d'une tentative visant à forcer la conception OO dans une base de données relationnelle. Cela peut être fait et correspond à la vision du monde d'un développeur OO, mais cela conduit à des conceptions de base de données invalidantes.
Faites un saut sur Google et recherchez "MUCK Tables" qui vous mènera à des discussions sur les tables à code codé massivement unifiées. Alternativement, vous pouvez rechercher "une vraie table de consultation" pour les discussions. Ou même lire l'article de Joe Celko One True Lookup Table .
Je n'ai pas trouvé ce que je cherchais dans cette question, mais celui-ci contient de nombreuses recommandations pour les modèles de conception dans DB Design
Ne pas stocker les valeurs calculées
Exemple, vous avez le tableau "Carrés" avec la colonne "largeur". Pas besoin de faire une colonne "zone", car cela peut être calculé via la largeur ^ 2
Comme pour n'importe quoi, la réponse est "ça dépend".
Les bases de données peuvent être utilisées pour différentes tâches, et certaines d'entre elles nécessiteront des orientations opposées dans la conception et le développement.
Un système de base de données OLTP sera conçu de manière totalement différente de celui utilisé comme solution de génération de rapports ou de stockage. Le premier est souvent normalisé et un entrepôt est souvent dé-normalisé. Cela aide le système à obtenir les performances souhaitées pour le comportement auquel il est destiné.
Même dans un segment de cette situation, différentes décisions de conception peuvent être appropriées, selon que l'utilisation sera lourde en lecture ou en écriture.
Le mieux est de rechercher les meilleures pratiques pour un segment de développement de base de données beaucoup plus petit qui correspond au type d'application que vous essayez de créer.
Le meilleur livre que j'ai jamais lu en matière de conception de base de données est "Conception de base de données pour de simples mortels" de Michael J Hernandez. Le nom sonne comme un livre pour débutants, mais les gens de tous les niveaux pourraient en tirer des connaissances. Elle est également indépendante de la plate-forme, car elle traite des données elles-mêmes et de la manière de les organiser correctement - et non de la technologie utilisée.
Il a également écrit un livre sur l’écriture de requêtes intitulé "Requêtes SQL pour les simples mortels" que j’ai entendu dire (je n’ai pas lu celui-ci moi-même) est assez bon.
La base de données relationnelle est une abstraction extrêmement puissante. c'est une collection de faits et un calcul de prédicats. En outre, SQL applique la séparation des requêtes de commande en ayant une clause pour examiner les lignes et une autre pour les modifier.
Lorsque vous considérez une base de données comme un moteur de raisonnement vérité, il est logique de disposer d'une configuration ne permettant pas aux contradictions de découler des données que vous modélisez. Par conséquent, pour utiliser efficacement une base de données relationnelle, vous devez concevoir correctement votre base de données. Contrairement à la conception de programmes orientés objet, il existe un consensus sur la conception d’une base de données relationnelle. L’approche appropriée à la conception de la base de données est normaliser dans la mesure du raisonnable. La plupart des gens normalisent jusqu'à la troisième forme normale, mais vous pouvez en fait aller jusqu'à la cinquième forme normale.
Si possible, vous souhaitez supprimer les valeurs de colonne nulles de votre base de données. Si vous êtes d’accord avec ma vision de la base de données en tant que moteur de raisonnement vérité, alors les valeurs nulles constituent un réel problème. Lorsque vous avez des valeurs NULL dans une base de données, la loi du tiers exclu ne ne s'applique pas . Cela rend "la preuve par contradiction" d'une propriété donnée de la base de données plus difficile qu'elle ne le serait sans les valeurs nulles. Les valeurs nuls compliquent inutilement la sémantique de la base de données.
Parfois, il sera nécessaire de casser les règles de la normalisation pour des raisons de performances. Cependant, ne le faites pas avant d'avoir des données sur les requêtes en particulier, qui sont lentes. Souvent, vous pouvez simplement accélérer la requête en modifiant soigneusement les index plutôt que de les dénormaliser.
Enfin, un mot sur les procédures stockées plutôt que les requêtes directes. Sur une base de données appropriée, vous pouvez définir des autorisations de sécurité sur les procédures stockées indépendamment des tables sous-jacentes. C’est en soi une raison suffisante pour envisager d’utiliser de manière extensive les procédures stockées. Avec les procédures stockées, vous créez un modèle de sécurité plus strict qu’il n’est possible avec un accès SQL direct.
Probablement la meilleure pratique la plus connue est la normalisation de la base de données. Cet ensemble de techniques vous permet de concevoir votre base de données de manière à supprimer les éléments redondants et à regrouper les champs de manière logique.
si vous ne documentez pas les énumérations dans la colonne de description du schéma afin que je puisse comprendre ce que représente le "5":
Select name from peeps where accountStatusId = 5
alors fais ceci
Utilisez une table pour énumérer un champ. par exemple:
Select name
from peeps p
join accountStatus s
on p.accountStatusID = s.asid
where s.accountStatus = 'ActiveDude'
Le livre de Michael J. Hernandez Conception d'une base de données pour de simples mortels est bien écrit et facile à lire. Il devrait répondre à toutes vos questions.
Hernandez a également co-écrit Requêtes SQL pour Mere Mortals avec John L. Viescas.
Les livres coûtent environ 60 $ l'unité. J'essaie de trouver le CD pour Queries for Mere Mortals parce que j'ai perdu le mien. Si quelqu'un en a une copie, faites le moi savoir.
je dirais que tant que la base de données est normalisée et si vous créez un VLDB, puis partitionnez-la correctement, tout devrait bien se passer. D'autres pratiques recommandées incluent l'utilisation de CRUD pour les procédures stockées et la vérification de la cascade correcte de toutes les tables. presque tout le reste est subjectif. Utiliser "Y/N" est la programmation de la base de données de l’ancienne école à partir de quand bit n’a pas encore été introduite. Il peut également être utilisé à des fins d'évolutivité telles que "O/N/Peut-être", mais si c'était le cas, les pratiques en matière de revenus voudraient normaliser cela et créer un tableau de recherche.