Comment concevoir une table/schéma DB avec facilité?

Question

Existe-t-il une méthode simple pour décider quels champs et index sont nécessaires pour chaque table dans une application que vous concevez? Par exemple, s'il s'agit d'une application Web qui permet simplement aux utilisateurs de créer des listes (un nombre illimité de listes et les utilisateurs peuvent créer des listes de choses à faire) et à d'autres utilisateurs de modifier la liste, et si la liste est visible publiquement ou seulement à certains utilisateurs, comment les tables peuvent-elles être conçues de manière à ce qu'elles soient très précises et conçues rapidement? Qu'en est-il des index? Je l'ai fait à l'université, puis j'ai revu la question il y a quelque temps et j'ai une méthode, mais je voudrais savoir s'il existe des moyens standards et efficaces de le faire sur le terrain.

Answer 1

conception de base de données est difficile ...

Comme beaucoup de choses dans la vie, il y a une série de compromis. La première chose que vous devez décider est quel SGBD vous utiliserez, (MySQL, SQL Server, Oracle, PostgreSQL, l'une des bases de données "orientées objet", etc

Ensuite, vous devez décider de la normalisation v. Aliénés Les questions telles que "combien de logique implémenterai-je dans les déclencheurs, les procédures stockées, le code de l'application, etc." doivent être adressées

Il n'y a pas de "Quick'n'Easy" façon de concevoir quoi que ce soit, mais le plus trivial des bases de données.

« Cours, c'est juste mon expérience. YMWV.

Answer 2

il est hors de la portée de cette réponse pour expliquer entièrement la conception de base de données

Je casse généralement ma conception en trois parties (partie 1 et 2 se trouvent à l'avant, tandis que 3 est généralement à la fin du projet)
1) créer les tables basées sur des relations (parent/enfant/etc)
2) créer des champs en fonction du contenu (parent a x atributs, etc.)
3) créer des index dernière en fonction de la façon dont vous sélectionnez les données de vos tables

Answer 3

N'a pas entendu parler d'approches formelles à ce problème, mais il existe des règles empiriques. Tous les noms et objets métier deviennent des tables, normalisées bien sûr. Et je pense que les attributs parlent en quelque sorte d'eux-mêmes. J'imagine?

En ce qui concerne les index, il s'agit simplement de travailler avec les données. Toute colonne qui est jointe de mérite un index (peut-être même en cluster). C'est très ... ça dépend. Mais il y a des modèles. Mais à l'exception de l'optimisation pour les jointures, de nombreux index sont directement liés à la façon dont les données sont utilisées, et ce n'est pas quelque chose qui peut être fourni par la règle empirique. Comme si vous recherchez des utilisateurs par pk et ailleurs par last_name, last_name mérite un index.

Answer 4

Je pense que la solution est subjective. Quand je dois concevoir des tableaux, je regarde l'objet Java qui représentera ce modèle de données particulier et je partirai de là. Vous trouverez beaucoup de frameworks (Django, CakePHP, RoR) pour développer le modèle et les frameworks construiront les tables correspondantes.

Je vous suggère donc d'évaluer les fonctionnalités et les données dont vous avez besoin pour stocker et développer vos tables. Vérifiez également si le jeu d'outils que vous avez à votre disposition vous propose de générer les tables à partir de la structure de l'objet.

Answer 5

Je pencherais pour la conception normalisée simple (presque):

CREATE TABLE lists (
        listid serial, 
        name varchar, 
        ownerid int references users(userid) 
        ) 

CREATE TABLE list_items (
         listid int references lists(listid), 
         value varchar, 
         date datetime 
         ) 

CREATE TABLE permissions (
          permissionid serial, 
          description varchar, 
         ) 

CREATE TABLE list_permissions (
           listid int references lists(listid), 
           permissionid int references permissions(permissionid) 
           userid int references users(userid) 
          ) 
CREATE TABLE users (
        userid serial, 
        name varchar 
        ) 

index à créer dépend de ce que sont les requêtes réelles les plus utilisées et comment sont-ils performants. Par exemple, si vous interrogez beaucoup sur les listes et list_items (probablement), vous voudrez un index sur listid et sur le nom, si vous recherchez par nom.

Juste quelques idées. J'espère qu'ils sont utiles.

Answer 6

Je voudrais essayer de ne pas vous enfermer si vous essayez toujours de voir ce qui fonctionne.

juste de votre description, vous voulez une table pour les informations de vos utilisateurs, ainsi que:

tbl_lists: 
    ID_list (primary key) 
    UserID (foreign key to list owner) 
    ListName 

tbl_listItems: 
    ID_listItem (primary key) 
    ListID (foreign key to list) 
    ItemDescription 

tbl_permissions: 
    ID_permission (primary key) 
    ListID 
    UserID (foreign key to user you're granting permission to) 
    PermissionTypeID (what kind of permission) 

tbl_permissionTypes: 
    ID_permissionType (primary key) 
    Description ("can view", "can edit", etc.) 

Plus flexible, vous pouvez faire des choses pendant que vous êtes la conception, le mieux. Vous pouvez optimiser plus tard.

Answer 7

Si vous voulez garder les choses très simples et ne pas trop se soucier de la normalisation. Vous pouvez créer une grande table qui stocke l'objet principal sur lequel votre webapp est basée, ex: lists, et d'autres petites tables supportent le lien vers la grande table, ex: tbl_listType, tbl_permission, tbl_list_items).

Ensuite, lorsque vous écrivez des requêtes, vous incluez presque certainement la table principale et vous pouvez lier dans d'autres tables de support pour plus de détails granulaires.