Проблемы объектно-реляционного сопоставления: необходимы предложения

Я пытался придумать хороший шаблон проектирования для сопоставления данных, содержащихся в реляционных базах данных, с бизнес-объектами, которые я создал, но я продолжаю упираться в стену.

Рассмотрим следующие таблицы:

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

Я хочу собрать всю информацию о конкретном пользователе. Создать запрос для этого не так уж сложно.

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

Проблема в том, что имена полей конфликтуют, и тогда я вынужден использовать псевдоним для каждого отдельного поля, что очень быстро выходит из-под контроля.

Есть ли у кого-нибудь достойный шаблон дизайна для такого рода вещей?

Я думал о получении нескольких результатов из одной хранимой процедуры, а затем об использовании набора данных для итерации каждой из них, но меня беспокоит, что некоторые проблемы с производительностью могут укусить меня позже. Например, вместо приведенного выше запроса что-то вроде:

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;

Это кажется достойным решением? Может ли кто-нибудь предвидеть проблемы с этим подходом?


orm
person Spencer Ruport    schedule 08.01.2009    source источник
comment
последнее решение кажется плохим, просто. Вам не кажется, что сглаживание - лучший способ. Кстати, вы действительно используете какой-либо фреймворк ORM?   -  person Adeel Ansari    schedule 08.01.2009
comment
Не используется ли фреймворк ORM? Для какого языка это?   -  person Chris Kimpton    schedule 08.01.2009


Ответы (1)


Никогда не используйте подстановочный знак SQL * в производственном коде. Всегда указывайте все столбцы, которые хотите получить.

Тогда создание псевдонимов для некоторых из них не кажется такой огромной дополнительной работой.


Повторите свой комментарий с просьбой предоставить предысторию и аргументацию:

  • Иногда вам действительно не нужны каждый столбец из всех таблиц, и их выборка может быть излишне затратной (особенно для больших строк и blob-объектов). Синтаксис SQL отсутствует для всех столбцов, за исключением следующих исключений.

  • Вы не можете использовать псевдонимы столбцов, которые вы получаете, используя подстановочный знак. Как только вам понадобится псевдоним любого из столбцов, вам нужно развернуть подстановочный знак, чтобы явно перечислить все столбцы.

  • Если структура таблицы изменится, например столбцы переименовываются, переупорядочиваются, удаляются или добавляются, затем подстановочный знак извлекает их все по положению, определенному в таблицах. Это может показаться удобством, но не тогда, когда ваше приложение зависит от столбцов, находящихся в наборе результатов по заданному имени или в заданной позиции. Вы можете получить загадочные ошибки, когда ваше приложение отображает столбцы в неправильном порядке (если ссылаются на столбцы по положению) или показывает их как пустые (если ссылаются на столбцы по имени).

    Однако, если в SQL-запросе столбцы именуются явно, вы можете использовать принцип Fail Early. Это помогает при отладке, поскольку ведет непосредственно к SQL-запросу, который необходимо отредактировать, чтобы учесть изменение схемы.

person Bill Karwin    schedule 08.01.2009
comment
Не могли бы вы дать некоторую предысторию и рассуждения? Спасибо! - person Spencer Ruport; 08.01.2009