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

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

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

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;

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

1 Ответ

3 голосов
/ 08 января 2009

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

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


Re ваш комментарий с просьбой обоснования и аргументации:

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...