Получить определение для столбцов, хранящихся в другой таблице, не объединяя дважды - PullRequest
Новая
       17

Получить определение для столбцов, хранящихся в другой таблице, не объединяя дважды

0 голосов
/ 21 февраля 2012

Учитывая две таблицы, в которых два столбца в первой таблице с потенциально различными значениями ссылаются на один столбец во второй, есть ли способ «определить» эти столбцы, не объединяя таблицы дважды?

ДляНапример, если Таблица 1 равна 

TransactionRecord( UserCreated char(3), UserModified char(3), ... , OtherData )

, а Таблица 2 равна 

Users( UserID char(3), UserName varchar(50), ... , OtherData )

Есть ли способ получить набор результатов, равный 

Result( TransactionData, UserNameCreated, UserNameModified )

без объединенияс первого стола на второй дважды?До сих пор мне удавалось добиться этого с помощью следующего SQL. 

SELECT OtherData, uc.[UserName], uf.UserName 
FROM TransactionData
    LEFT JOIN Users uc ON TransactionData.UserCreated = uc.UserID
    LEFT JOIN Users um ON TransactionData.UserModified= um.UserID

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

Ответы [ 2 ]

1 голос
/ 22 февраля 2012

Нет простого способа обойти это, я думаю, что правильное индексирование - это единственный путь (и он должен подойти, если у вас нет десятков миллионов строк).

Например, вам нужна таблица, в которойидентификатор пользователя является кластеризованным уникальным индексом: 

CREATE UNIQUE CLUSTERED INDEX [IX_UserID] ON [dbo].[table]
(
[UserID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)

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

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

0 голосов
/ 22 февраля 2012

Пользователь в двух столбцах, в основном, не является третьей нормальной формой. Я хотел бы присоединиться к UserID и иметь битовый столбец для действия (0 = добавить, 1 = пересмотреть).

...