Вычисляемые столбцы в SQL Server, ссылающиеся на другую таблицу - PullRequest
0 голосов
/ 06 сентября 2011

Чтобы помочь объяснить мой вопрос, я объясню немного проблемы.У нас есть база данных клиентов, включая историю их адресов (т. Е. Каждое обновление адреса вставляет новую строку в таблицу адресов, и у нас есть представления, которые извлекают самую последнюю информацию для создания отчетов на экране и в печатных отчетах).

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

Мы достигли снижения производительности, запустивоставьте соединение для просмотра в наших возвращенных результатах поиска, поэтому здесь возникает вопрос.

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

Я полностью лаю неправильное дерево, рассматривая способы полученияПринимая во внимание эту медлительность, стоит ли мне заняться каким-либо образом настройкой базы данных, чтобы оптимизировать поиск?

Заранее спасибо, Уэсли

edit: запрос выглядит так:

Select 
    Clients.ClientID,
    Clients.LastName,
    Clients.FirstName,
    Clients.PreferredName,
    PrimaryDeliveryCity as City,
    PrimaryDeliveryPostalCode as PostalCode,
    DateOfBirth,
    ClientNumber
FROM 
    Clients LEFT JOIN v_LatestClientAddressHistoryRecord 
    ON Clients.ClientID = v_LatestClientAddressHistoryRecord.ClientID
WHERE
    ClientNumber like @ClientNumber + '%'

Действительно, в запросе есть%, но не в объединенной таблице.

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

Правка # 2:

SELECT ClientAddressHistoryRecords.*
FROM
dbo.ClientAddressHistoryRecords INNER JOIN dbo.v_LatestClientAddressHistoryRecordID 
ON dbo.ClientAddressHistoryRecords.ClientID = dbo.v_LatestClientAddressHistoryRecordID.ClientID 
AND
dbo.ClientAddressHistoryRecords.ClientAddressHistoryRecordID = dbo.v_LatestClientAddressHistoryRecordID.MaxClientAddressHistoryRecordID

и представление v_LatestClientAddressHistoryRecordID

SELECT     MAX(ClientConsentHistoryRecordID) AS MaxClientConsentHistoryRecordID, ClientID
FROM         dbo.ClientConsentHistoryRecords
GROUP BY ClientID

Ответы [ 2 ]

1 голос
/ 07 сентября 2011

Другим подходом будет INSTEAD OF TRIGGER, который вставляет все вставки / обновления в таблицу истории (каждая в виде своей собственной строки) и объединяет все вставки / обновления в активную таблицу (единственной строкой для клиента является наиболеетекущий ряд).Теперь вы указываете свои активные запросы на активную таблицу, и, если вам нужна история, вы пишете этот запрос, чтобы извлечь его из архивной таблицы.Да, у вас есть две копии активных строк, но если предположить, что проблема в скорости связана с большим процентом старых адресов, это может быть хорошо.

1 голос
/ 06 сентября 2011

Вычисляемые столбцы или триггеры могут решить эту проблему.Вы не лаете неправильное дерево с этими идеями.

Однако, одна вещь, чтобы рассмотреть, может ли это быть обработано через плановое обслуживание ("рабочие места").

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

Преимущество для job, превышающего computed columns или triggers, будет 1), что работа, выполняемая базой данныхбудет меньше, и 2) работа может быть выполнена в более удобное время.Учтите, что с вычисленными столбцами и триггерами работа выполняется одновременно с операцией CRUD.Запланированное техническое обслуживание, с другой стороны, может быть запланировано на непиковое время (например, 2 часа ночи или что-то другое, что вам нужно для вашей работы).

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