Problèmes de mappage relationnel objet: Suggestions requises

Question

J'ai essayé de trouver un bon modèle de conception pour mapper les données contenues dans les bases de données relationnelles avec les objets métier que j'ai créés, mais je continue de frapper un mur.

Tenir compte des tableaux suivants:

TYPE: typeid, description 
USER: userid, username, usertypeid->TYPE.typeid, imageid->IMAGE.imageid 
IMAGE: imageid, location, imagetypeid->TYPE.typeid 

Je voudrais rassembler toutes les informations concernant un utilisateur spécifique. Créer une requête pour cela n'est pas trop difficile.

SELECT u.*, ut.*, i.*, it.* FROM user u 
INNER JOIN type ut ON ut.typeid = u.usertypeid 
INNER JOIN image i ON i.imageid = u.imageid 
INNER JOIN type it ON it.typeid = i.imagetypeid 
WHERE u.userid = @userid 

Le problème est que les noms de champs entrent en collision et je suis obligé d'alias chaque champ unique qui sort de la main très rapidement.

Est-ce que quelqu'un a un modèle de conception décent pour ce genre de chose? J'ai envisagé de récupérer plusieurs résultats d'une seule procédure stockée, puis d'utiliser un ensemble de données pour parcourir chacun d'eux, mais je crains que certains problèmes de performances ne me mordent plus tard. Par exemple au lieu de la requête ci-dessus quelque chose comme:

SELECT u.*, t.* FROM user u 
INNER JOIN type t ON t.typeid = u.usertypeid 
WHERE u.userid = @userid; 
SELECT i.*, t.* FROM image i 
INNER JOIN type t ON t.typeid = i.imagetypeid 
INNER JOIN user u ON u.imageid = i.imageid 
WHERE u.userid = @userid; 

Est-ce que cela ressemble à une solution décente? Quelqu'un peut-il prévoir des problèmes avec cette approche?

Answer 1

N'utilisez jamais le caractère générique SQL * dans le code de production. Toujours épeler toutes les colonnes que vous voulez récupérer.

Ensuite, aliaser certains d'entre eux ne semble pas être une énorme quantité de travail supplémentaire.

---

Re votre commentaire demander contexte et le raisonnement:

• Parfois, vous n'avez pas vraiment besoin chaque colonne de toutes les tables et les chercher peuvent être inutilement coûteux (en particulier pour les grandes chaînes et blobs). Il n'y a pas de syntaxe SQL pour "toutes les colonnes sauf les exceptions suivantes".

• Vous ne pouvez pas alias les colonnes que vous récupérez en utilisant le caractère générique. Une fois que vous avez besoin d'alias l'une des colonnes, vous devez développer le caractère générique pour répertorier toutes les colonnes explicitement.

• Si la structure de la table change, par ex. les colonnes sont renommées, réorganisées, supprimées ou ajoutées, puis le caractère générique les récupère toutes, par position telle que définie dans les tables. Cela peut sembler une commodité, mais pas lorsque votre application dépend de la position des colonnes dans le jeu de résultats par un nom donné ou dans une position donnée. Vous pouvez obtenir des bogues mystérieux où votre application affiche les colonnes dans le mauvais ordre (si vous référencez les colonnes par position), ou les affiche comme vides (si vous référencez les colonnes par leur nom). Toutefois, si la requête SQL nomme explicitement les colonnes, vous pouvez utiliser le principe "Fail Early". Cela facilite le débogage, car il vous mène directement à la requête SQL qui doit être modifiée pour prendre en compte la modification du schéma.