Conception de schéma de base de données pour MySQL, suggestions?

Question

Alors, avoir la chance de faire ma première "vraie" base de données, en pensant à moi-même à quoi je devrais penser ... des suggestions?

• Sélectionnez DB (en utilisant MySQL)
• moteur Sélectionnez DB en fonction des besoins (en utilisant MySQL, savoir MyISAM vs InnoDB)
• CREATE TABLE documention pour DB en utilisant
• définition de colonne (sélectionner le type de données à droite)
• Données du modèle à normaliser
• Intégrité référentielle: clé primaire (naturelle ou de substitution); Clés composites; Clé étrangère

Ce qui m'amène à ma question principale, comment puis-je savoir si la base de données est un bon ajustement?

Answer 1

Comme vous énumérez les questions générales qui doivent être répondues pour aller de l'idée au système de travail je propose qu'il est très important de les organiser en

1) conception logique (obtenir un modèle propre qui représente l'espace de problème que vous essayez de modéliser)

2) la conception physique (qui moteur SGBDR et le stockage, les types de données exactes, d'autres décisions relatives pratiques et de performance)

vous faites trop de mélange entre le deux. Lorsque vous obtenez un modèle logique propre et connaissez les relations entre les entités que vous modélisez, la modélisation physique ne sera pas difficile.

EDIT: Il y a beaucoup de livres qui traitent des étapes de la conception de données logiques, mais normalement vous tenterait de:

1. définir les cas d'utilisation et les exigences commerciales (les choses sont assez doux encore, vérifier les exigences pour les contradictions, ceci est fait en interviewant des gens qui connaissent bien les processus métier, qui peuvent dégénérer en discussion avec vous-même)
2. obtenir une liste de tous les attributs et entités utilisés dans le système et les définir (dictionnaire de données)
3. déterminer le domaine des attributs (qui, plus tard au niveau physique peut être accompli comme type de données, vérifier la contrainte ou en se référant à la table 'helper', mais ne vous inquiétez pas encore, assurez-vous de bien définir les domaines)
4. dessiner des diagrammes ER/UML définissant des relations - définir des tables en termes de clés primaires, de clés étrangères et de tous les autres attributs (cette fois, viser l'exhaustivité); cette étape peut être faite en utilisant CAM et des outils de diagrammes décents cracheront des scripts CREATE DATABASE à partir des diagrammes
5. examiner le modèle à la recherche de données dénormalisées (devrait être normalisé déjà, mais en traduisant l'espace problème en modèle logique, il est possible de faire des erreurs et découvrez que vous avez une redondance ou d'autres anomalies)

Certaines de ces étapes doivent être répétées lorsque vous envisagez différentes manières d'accomplir certaines tâches. Par exemple, inclure de nouveaux attributs pourrait vous pousser à analyser un nouveau cas d'utilisation. Ou une découverte d'exigence contradictoire pourrait conduire à la découverte d'une nouvelle entité entière.Ou découvrir une redondance pourrait vous mener à la découverte d'un processus non documenté qui existe (et justifie, ou plutôt explique, la redondance perçue en redéfinissant un attribut apparemment dupliqué). Etc ...

Answer 2

1. Modélisez vos données et normalisez-les avant de définir vos colonnes. Cela doit être votre première tâche avant même de sélectionner une base de données et des types de tables, car cela vous permettra de clarifier la tâche que vous modélisez.

2. Sélectionnez le moteur de base de données en fonction des besoins (en utilisant MySQL, connaissez MyISAM vs InnoDB) Le compromis est "performance de requête" v "transactions". Dans la plupart des cas, la performance d'innoDB est assez bonne et les avantages des transactions l'emportent sur tout inconvénient.

3. Créer une documentation de table est disponible sur le site Web de MySQL.

Comme Déraison dit: « Quand vous obtenez un modèle logique propre et connaître les relations entre les entités que vous modélisez alors la modélisation physique ne sera pas difficile ».

Le succès peut être mesuré de différentes manières. L'argent dans votre poche, bonne performance sur le matériel à bas prix. Beaucoup de commentaires heureux des utilisateurs ... Comme Stackoverflow :)

Answer 3

1. La sélection d'un SGBDR est en grande partie une question de préférence. Vous semblez déjà pencher vers MySQL. C'est bon, parce que MySQL est bon marché et populaire. Cependant, il ne vous reste plus de moteur capable de faire des transactions et de faire des recherches en texte intégral en même temps (entre MyISAM et InnoDB). Fulltext Search with InnoDB

2.(et 4)MyISAM vs InnoDB and datatypes

• MyISAM pour: la recherche en texte intégral et le niveau de la table de verrouillage
• InnoDB pour: transactions, FKs et verrouillage de niveau ligne (mais sans texte intégral recherche)
• De plus, InnoDB fonctionnera probablement mieux avec un grand nombre de rangées en raison du verrouillage au niveau de la ligne par rapport au verrouillage du niveau de table

3.CREATE TABLE? Je préfère utiliser un IDE de base de données, comme Toad for MySQL

5.(et 6)Review of DB normalization/PKs/FKs(Vous aurez besoin d'utiliser InnoDB pour FKs.)

7.Vous avez oublié les index! Facteur très important dans une base de données.

• What is an index in MySQL?

• MySQL indexes - what are the best practises?

Oui MySQL est un bon ajustement si vous avez les exigences ci-dessus.

Cependant, comme je l'ai dit, avec MySQL/MyISAM/InnoDB, vous ne disposez pas d'un moteur qui peut faire la recherche en texte intégral ET transactions/FKs. Une option simple est d'avoir une deuxième copie (dans MyISAM) des tables InnoDB qui ont besoin d'une fonction de recherche en texte intégral. Vous pouvez le faire parce que vous pouvez mélanger les 2 moteurs dans la même base de données. Ou, peut-être vous n'avez même pas besoin de recherche en texte intégral, car LIKE est suffisant pour votre application. D'autre part, avec SQL Server, vous pouvez avoir toutes les fonctionnalités, y compris le texte intégral, les transactions et les FK dans un seul moteur. Une autre option consiste à utiliser une technologie distincte pour les recherches de texte intégral indexées. Il y a un plugin pour MySQL:

• Sphinx Search Server
• Reference manual

Exemple:

• Using the Sphinx Search Engine with MySQL