Conception De Base De Données Des Meilleures Pratiques

Quelques points:

• Apprendre autant que vous pouvez au sujet de domaine du problème. Vous ne pouvez pas créer un bon modèle de données sans savoir ce que vous êtes en train de concevoir pour
• Avoir de bonnes connaissances sur types de données fourni par votre fournisseur de base de données
• Comment utiliser correctement normalisation et de la conception des tables de
• De la Performance: quand et comment appliquer index, comment écrire efficace requêtes etc.
• Quand et comment utiliser les différentes DB objets comme les vues, les procédures, fonctions, triggers

Mon point de vue sur ce qui est quelque peu contradictoire.
Je vous conseille, de ne pas le stress de la conception de la base de données trop.

Parfois, cela peut être difficile. Avec interne d'applications MÉTIER, le point de vue dominant de l'entreprise est souvent une fois que les DONNÉES sont le principal actif, où le logiciel est un peu insignifiant.

Mon conseil serait: ne l'achetez pas.

En réalité, l'actif est la capacité de la société à INTERAGIR avec les données. Pour l'afficher, de le manipuler, et à prendre des décisions fondées sur elle.

Cela signifie que, même s'ils accordent une grande valeur sur les données, ce qu'ils sont réellement valoriser est le logiciel que vous avez écrit.

Cela me permettrait de concentrer la plupart de vos efforts sur la construction d'une expérience de l'utilisateur, plutôt que sur la "conception de la base de données idéale". La base de données est vraiment un outil qui vous permet d'offrir à l'utilisateur une expérience.

La caractéristique clé de données relationnelles, modèles de données et le chemin d'accès de l'indépendance. Vous pouvez ajouter des colonnes, changement de clés, d'introduire ou de supprimer des index, etc, tout en ayant un impact nul (ou proche de zéro) sur les applications qui l'utilisent.

Ce qui rend la structure de base de données extrêmement souple.

En essayant de concevoir la base de données "d'être flexible pour l'avenir", ou à "optimiser la performance" est essentiellement un gaspillage d'efforts.

L'évolution de la structure de la base de données ont un impact relativement faible sur votre système.

Aussi, vous avez vraiment ne pouvez pas prédire comment la base de données à l'échelle jusqu'à ce que vous exécutez dans les scénarios où vous en avez besoin à l'échelle. Votre meilleur pari est d'attendre jusqu'à ce que vous frappez les problèmes de performances. et puis les traiter spécifiquement.

Apporter des modifications à l'expérience de l'utilisateur de votre application, cependant, est généralement plus cher.
UI travail exige beaucoup de temps, et prend généralement un certain temps pour obtenir le droit.

Donc, je vous recommande:

1. Seulement de produire une merde DB design
2. Réagir à la performance réelle des scénarios de vous rencontrer
3. Concentrer vos efforts sur l'expérience utilisateur, et non pas sur la base de données

Je n'ai pas trouvé ce que je cherchais dans cette question, mais cette une a un tas de recommandations pour la conception des modèles en DB design

Comme avec n'importe quoi, ici, la réponse est "Ça Dépend".

Les bases de données peuvent être utilisés pour faire des choses différentes, et certaines de ces choses vont exiger des directions opposées dans la conception et le développement.

Une base de données OLTP système sera conçu de manière complètement différente de celle utilisée comme une déclaration ou une solution d'entreposage. La première est souvent normalisée, et un entrepôt est souvent dé-normalisé. Cela permet au système d'obtenir les performances souhaitées pour son comportement.

Même à l'intérieur d'un segment de cela, en fonction de si l'utilisation sera à lecture intensive, ou écrivez-lourds, les différentes décisions de conception qui pourraient être appropriées.

Le meilleur pari est d'étudier les meilleures pratiques pour un beaucoup plus petit segment de développement de base de données qui correspond au type d'application que vous êtes en train de construire.

La base de données relationnelle est un outil extrêmement puissant d'abstraction; c'est un recueil de faits et d'un prédicat de calcul. Non seulement cela, SQL applique une requête de commande de séparation par avoir une clause pour l'examen des lignes et un autre pour changer les lignes.

Quand vous pensez à une base de données comme une vérité raisonnement moteur, il est logique d'avoir un set-up qui ne permettent pas de contradictions de flux de données que vous êtes à la modélisation. Par conséquent, pour utiliser une base de données relationnelle de manière efficace, vous devez obtenir votre conception de la base de droit. Contrairement à la conception orientée objet des programmes, il y a un consensus sur la manière d'une base de données relationnelle devrait être conçu. La bonne approche de conception de base de données est normaliser aussi loin qu'il est sensible. La plupart des gens normaliser à la troisième forme normale, mais vous pouvez en fait aller jusqu'à la cinquième forme normale.

Si possible, vous voulez effacer les valeurs de colonne null à partir de votre base de données. Si vous êtes d'accord avec mon point de vue de la base de données comme une vérité raisonnement moteur, puis les valeurs null sont un réel problème. Lorsque vous avez des valeurs null dans une base de données de la loi du tiers exclu ne pas maintenez-la enfoncée. Ce qui fait de "la preuve par contradiction" de toute propriété de la base de données de plus difficile qu'il serait sans les valeurs null. Les valeurs null compliquer inutilement la sémantique de la base de données.

Parfois, il sera nécessaire de briser les règles de normalisation pour des raisons de performances. Cependant, ne le faites pas avant d'avoir données sur ce qui est des requêtes, en particulier, sont lents. Souvent, vous pouvez simplement accélérer la requête avec soin en modifiant les indices plutôt que denormalising.

Enfin, un mot sur les procédures stockées plutôt que de diriger les requêtes. Dans des conditions décentes de base de données, vous pouvez définir les autorisations de sécurité sur des procédures stockées indépendamment des tables sous-jacentes. Cela, en soi, est une raison suffisante pour envisager d'utiliser des procédures stockées de manière intensive. Avec des procédures stockées, vous construire un resserrement des mesures de sécurité modèle que ce qui est possible avec direct accès SQL.

si vous n'avez pas de document énumérations dans la colonne description du schéma pour que je puisse comprendre ce que le " 5 " est dans ce:

Select name from peeps where accountStatusId = 5

ensuite ce faire

Utiliser un tableau pour recenser un champ. par exemple:

Select name 
from peeps p 
join accountStatus s 
on p.accountStatusID = s.asid 
where s.accountStatus = 'ActiveDude'

je dirais que tant que la base de données est normalisé et si vous faites une VLDB alors la partition correctement, alors vous devriez être bien. les autres meilleures pratiques comprennent l'utilisation de CRUD pour les procédures stockées et de s'assurer que toutes les tables en cascade correctement. plus tout le reste est subjectif. À l'aide de "A/N" est de la vieille école programmation de base de données à partir de quand les bits n'a pas encore été mise en place. Il peut également être utilisé à des fins d'évolutivité comme "Y/N/Peut-être" mais si c'était le cas bast pratiques dirais à normaliser et apporter une table de recherche.