Вместо использования коррелированного подзапроса в предложении UPDATE
, вы можете получить нужные значения через соединение. Во-первых, создайте производную таблицу, которая выглядит практически идентично вашему коррелированному подзапросу, и получите все уникальные значения, необходимые для идентификации строк из #Items
, которые вы хотите связать со строками в #Tree
. Поскольку нет никаких указаний на уникальные ограничения в упомянутых таблицах, мне пришлось что-то догадываться об этом.
Настройка выборочных данных
-- Setting up sample data
if object_id('tempdb.dbo.#Items') is not null drop table #Items
create table #Items
(
Item char(1),
Rev char(2),
RDate date,
ECO char(4),
New bit
)
insert into #Items (Item, Rev, RDate, ECO, New)
values
('A', '0A', '2019-01-01', 'E123', 1),
('A', '01', '2018-01-01', 'E456', 0),
('B', '0A', '2018-12-31', 'E765', 0),
('C', '01', '2019-01-01', 'E456', 0)
if object_id('tempdb.dbo.#Tree') is not null drop table #Tree
create table #Tree
(
Parent char(1),
ParentRev char(2),
Child char(1),
ChildRev char(2),
VDate date,
ECO char(4)
)
insert into #Tree (Parent, ParentRev, Child, ChildRev, VDate)
values
('Y', '0B', 'C', NULL, '2019-01-01'),
('Y', '0C', 'D', NULL, '2019-01-13'),
('Z', '01', 'A', NULL, '2018-06-25'),
('Z', '02', 'A', NULL, '2019-01-11'),
('Z', '0A', 'B', NULL, '2019-01-01')
Теперь, когда у вас есть производная таблица, отображающая строки в #tree
в строки с желаемыми датами из #items
, присоединитесь это еще раз к таблице #items
, чтобы получить ECO
, Rev
и все остальное, что вы хотите.
-- Actual Update Statement
update a
set ChildRev = c.Rev,
Eco = c.Eco
from #Tree a
-- Consruct a derived table basically mapping the rows in #tree to the rows with the desired dates you want.
inner join
(
select t.Child, t.ParentRev, MaxRDate = max(i.RDate)
from #Tree t
inner join #Items i
on t.Child = i.Item
and i.RDate <= t.VDate
group by t.Child, t.ParentRev
) b
on a.Child = b.Child
and a.ParentRev = b.ParentRev
-- Finally, join the "intermidate mapping table" to #Items to get the values (eco, rev, etc.) you actually want
inner join #Items c
on b.Child = c.Item
and b.MaxRDate = c.RDate
select top 1000 *
from #Tree
Вообще говоря, это, вероятно, будет работать лучше, чем коррелированный подзапрос, хотя в зависимости от того, какие индексы существуют, ваш пробег может отличаться. Кроме того, если вы действительно просматриваете 4,5 миллиона таких записей, рассмотрите возможность разбить их на партии или найти способ предварительно отфильтровать то, что необходимо обновить, заблаговременно.
Что касается запуска этого процесса, когда появляется новая строка, у вас есть два варианта.
new
, она должна запускать этот процесс одновременно (или что-то подобное, чтобы делать оба в одной транзакции). Items
, запустив этот процесс по мере необходимости. Хотя TBH я бы порекомендовал первый, так как гораздо проще содержать всю необходимую логику в одном месте и не иметь лишних накладных расходов на наличие триггера, что также несколько запутывает процесс синхронизации данных. [1116 ] Другая альтернатива
Еще один подход, который я только что разработал, состоит в том, чтобы сделать все в одном запросе. Используйте CTE (или производную таблицу; как хотите) с row_number
RID. Затем обновите это, где RID = 1
;with src as
(
select
t.Parent,
t.ParentRev,
t.Child,
t.ChildRev,
t.VDate,
t.ECO,
Item = i.Item,
ItemRev = i.Rev,
ItemRDate = i.RDate,
ItemECO = i.ECO,
ItemNew = i.NEW,
RID = row_number() over (partition by t.Parent, t.ParentRev, t.Child order by i.RDate desc)
from #Tree t
inner join #Items i
on t.Child = i.Item
and i.RDate <= t.VDate
)
update src
set ECO = ItemECO,
ChildREv = ItemRev
where RID = 1
ТАК использует ASP.NET MVC. Действительно необходимо читать в деталях, как перезапись URL MVC работает, но суть ее - то, что часть 'вопросов' в URL является названием Класса контроллера (который примерно соответствует 'showdetails' в URL), и число является идентификационным параметром для действия по умолчанию с тем Контроллером (то же как параметр 'идентификатор' в URL).
Перед появлением Системы. Сеть. При маршрутизации обычная практика должна была использовать UrlRewriter.NET. Работавший достаточно хорошо, но мог укусить Вас при конфигурировании IIS. Я не уверен, существуют ли какие-либо простые способы использовать новые классы Маршрутизации в ASP.NET (т.е. отбросьте его в и пойдите по сравнению с рефакторингом кода).
Так как MVC не является опцией, можно попытаться перенаправить 404 с. Это будет работать в ASP.NET 1.1 и выше: Перенаправьте 404 с и 405 с к Вашему собственному обработчику с помощью или конфигурации IIS или web.config, проанализируйте запрос в обработчике и перенаправлении к соответствующему ресурсу.
<configuration>
<system.web>
<customErrors mode="On" defaultRedirect="error.html">
<error statusCode="404" redirect="newHandler.aspx"/>
</customErrors>
</system.web>
</configuration>
объясните значение значений такой как "358 630" в URL
Это - (по-видимому), идентификатор для вопроса в базе данных. В модели MVC
myurl.com/questions/358630
походит
myurl.com/questions.aspx?id=358630
Заголовок вопроса на конце URL на самом деле игнорируется приложением. Это обычно "прикрепляется на" для оптимизации поисковой системы и человеческих целей удобочитаемости. На самом деле можно изменить заголовок этого вопроса в URL и заметить, что страница все еще загружается очень хорошо.
Новая Система. Сеть. Маршрутизация dll является частью ASP.NET 3,5 SP1 и является мусорным ведром, развертываемым на ASP.NET 3.5, таким образом, Вы могли использовать функции этого на классическом сайте ASP.NET WebForms.
Вы, вероятно, захотите принять во внимание комментарии Phil Haack в его сообщении при использовании MVC на IIS 6, поскольку необходимо будет, вероятно, включать .aspx расширение в направленные URL
http://www.mysite.com/controler.aspx/action/id
Вы могли бы также хотеть проверить Вопросы Теговая SEO.
Проигнорированное имя вопроса в конце URL часто называют "Кратким заголовком" и используют в целях SEO включать название страницы в URL.