Base de données relationnelle, photos, votes et avertissements

Question

Je suis en train de concevoir une base de données relationnelle, mais je n'ai pas trop d'expérience, donc je voudrais vous demander une suggestion sur les tableaux relationnels avec des photos.

Je pensais que d'utiliser un table pour stocker photos, et une ou plusieurs tables pour les données utilisateur et des liens soumis, de sorte que les photos peuvent être liés à des sujets différents, par exemple houses ou trees, dans ce cas, je pourrais avoir cette structure:

table_houses 
- house_id 
- house_name 
- house_architect_name, house_..., etc. 

table_trees 
- tree_id 
- tree_name 
- tree_plant_type, tree_..., etc. 

table_photos 
- photo_id 
- photo_filename 
- photo_date 
- photo_user_id 

table_rel_houses 
- rel_id 
- rel_house_id 
- rel_photo_id 
- rel_user_id 
- rel_vote_id 
- rel_warn_id 

table_rel_trees 
- rel_id 
- rel_tree_id 
- rel_photo_id 
- rel_user_id 
- rel_vote_id 
- rel_warn_id 

table_warns, table_votes, etc. 

dans ce cas, les tables relationnelles doit avoir la même structure, parce que le travail de la même manière, mais le point à un autre sujet (maison ou le type d'arbre).

La structure des données peut-elle être correcte ou dois-je scomposer beaucoup plus la table relationnelle dans un table_rel_votes et table_rel_warns?

J'ai besoin de pages classiques avec une plus grande photo et les vignettes pour naviguer les autres, je dois considérer que la structure pourrait stocker plusieurs millions de lignes de photos.

Answer 1

Vous pouvez envisager la modélisation de votre base de données comme suit:

table_photos 
- photo_id 
- photo_filename 
- photo_date 
- photo_user_id 
- vote_id 
- warn_id 
- type 
- detail_id 

table_houses 
- id 
- name 
- style 

table_trees 
- id 
- name 
- species 

Dans ce cas, vous pouvez définir votre sujet photo dans le domaine type, tels que 1 = Arbre, 2 = Maison, etc. Vous sera toujours en mesure d'avoir plusieurs photos pour le même sujet sans duplication de données, mais vous éviterez d'avoir à construire les tables table_rel_xxx avec le schéma de colonnes répété. Je préfère éviter cela quand c'est possible.

Dans ce cas, vous seriez en mesure de construire des requêtes telles que:

SELECT 
    table_trees.name 
FROM 
    table_photos 
INNER JOIN 
    table_trees ON 
    (table_trees.id = table_photos.detail_id AND table_photos.type = 1); 

Ou bien simplement interroger toutes les photos sans « liaison tardive » avec le type spécifique:

SELECT 
    photo_filename 
FROM 
    table_photos; 

Vous peut être intéressé à vérifier les articles suivants liés à ce modèle de base de données:

• Stack Overflow - Polymorphism in SQL database tables?
• Data, Design, and SQL Server - Disjoint subtyping in SQL

Ce sont des techniques qui tentent de mettre en œuvre associations polymorphes dans une base de données relationnelle, même si il n'y a pas de soutien pour cela dans SQL à un niveau de langue. Un inconvénient de cette méthode est qu'elle rend les contraintes de clés étrangères assez difficiles à définir. Vous aurez besoin d'une contrainte de clé étrangère pour avoir une garantie que si table_photos fait référence à une ligne dans table_trees, cette ligne existe réellement. Une solution pour le problème des clés étrangères est décrit, avec un très bon exemple, dans l'article CEM suivant:

• Distributed Keys and Disjoint Subtypes