Conception De Base De Données Des Meilleures Pratiques

Question

Je suis assez bien familiarisés avec SQL Server, MySQL, Oracle, etc, mais de mettre ces produits de Base de données à part, est-il une ressource qui va m'aider à la conception de bases de données relationnelles bien? S'il existe quelque chose comme des modèles ou des meilleures pratiques pour la conception de base de données?

Je l'ai vu à quelques reprises que la base de données n'est pas souvent évolutive; les gens ont des préférences personnelles, avec le maintien de colonnes, comme isChecked colonne qui est un booléen dans la nature, mais stockés en tant que Char(1) avec des valeurs comme " Y " et " N " au lieu de 0 et de 1 qui pour moi sonne mieux. Les moyens à ne pas commettre les erreurs les plus courantes tout en faisant de conception de base de données?

Des liens vers des livres ou des articles sera très appréciée.

Merci à l'avance.

Answer 1

Quelques points:

• Apprendre autant que vous pouvez sur le 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 les types de données fournis par votre fournisseur de base de données
• Comment utiliser correctement la normalisation et de la conception des tables
• Performance: quand et comment demander des indices, comment écrire efficace des requêtes etc.
• Quand et comment utiliser les différentes DB objets comme les vues, les procédures, fonctions, triggers

Answer 2

Il existe de nombreuses base de données de modèles de conception. Ils ne sont pas souvent bien formalisé, de sorte que vous peut-être simplement regarder grand nombre de conception de base de données.

Voir, par exemple, de Fowler livres sur les modèles de conception. Aussi Encoche du Livre.

Il y a des blogs, comme programmeur de base de données.

Il y a un IEEE livre, Sur le Modèle de Base de données pour la Conception et la mise en Œuvre.

La Recherche Google (lien) s'est jusqu'à 24M hits.

Answer 3

De 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.

Cela 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

Answer 4

Pour contrer Dillie-O conseils. Je voudrais vous suggérer de ne pas mettre toutes vos recherches dans un tableau. En général, c'est une tentative pour forcer OO design dans une Base de données Relationnelle. Il peut être fait et qu'il correspond à la vision du monde d'un OO développeur, mais elle conduit à paralyser dessins de base de données.

Rebondir sur Google et la recherche pour "MUCK Tables", qui vous conduisent à des discussions de Massivement Code Unifié-les Tables de Clés. Alternativement, vous pouvez rechercher "une vraie table de recherche" pour les discussions. Ou même de lire Joe Celko l'article d' Un Vrai Tableau de Recherche .

Answer 5

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.