Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Независимая транзакция  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Mike_za
Дедушка
пропущено...
как вы понимаете, что какой-то закешированный срез нужно обновить?


в момент модификации базовых данных, все зависящие от них срезы маркируются устаревшими.
в момент потребности в кеше, если кеша нет либо он устарел, то он считается.
23 мар 17, 15:30    [20326348]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2307
Mike_za,

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

+
ALTER function ..
(
	@StartDate datetime
	,@EndDate datetime
	,@Variant_ID uniqueidentifier
)
returns table 
as 
return
select
	[ИРХ_РЕГ2].ID as [IRH_REG2_ID]
	,[ИРХ_РЕГ2].AID as [IRH_REG2_AID]
	,[ИРХ_РЕГ2].Catalog_ID
	,[ИРХ_РЕГ2].Owner_ID
	,[ИРХ_РЕГ2].[IRH_REG2_Vers_ID]
	,[ИРХ_РЕГ2].[IRH_REG2_Vers_AID]
	,[ИРХ_РЕГ2].StartDate
	,[ИРХ_РЕГ2].EndDate
	,[ИРХ_РЕГ2].Variant_ID
	,[ИРХ_РЕГ2].[UBP_ID]
	,[ИРХ_РЕГ2].[EMail]
	,[ИРХ_РЕГ2].[Order_Number]
	,case
	when [Гос].[Gos_ID] is not null then 'Гос'
	when [ДепМНЦП].[DepMNCP_ID] is not null then 'ДепМНЦП'
	when [ДМС].[DMS_ID] is not null then 'ДМС'
	when [ЗАТО].[ZATO_ID] is not null then 'ЗАТО'
	when [КБС].[KBS_ID] is not null then 'КБС'
	when [МНЦП].[MNCP_ID] is not null then 'МНЦП'
	when [ПВОДМС].[PVODMS_ID] is not null then 'ПВОДМС'
	when [ПосОБР].[PosOBR_ID] is not null then 'ПосОБР'
	when [Рег].[Reg_ID] is not null then 'Рег'
	when [СБМНЦП].[SBMNCP_ID] is not null then 'СБМНЦП'
	when [СБС].[SBS_ID] is not null then 'СБС'
	when [ТГВФ].[TGVF_ID] is not null then 'ТГВФ'
	when [УК].[UK_ID] is not null then 'УК'
	else '_Неизвестный'
end as [Catalog_Code]
	,coalesce([Гос].[code], [ДепМНЦП].[code], [ДМС].[code], [ЗАТО].[code], [КБС].[code], [МНЦП].[code], [ПВОДМС].[code], [ПосОБР].[code], [Рег].[code], [СБМНЦП].[code], [СБС].[code], [ТГВФ].[code], [УК].[code]) as [code]
	,coalesce([Гос].[Name], [ДепМНЦП].[Name], [ДМС].[Name], [ЗАТО].[Name], [КБС].[Name], [МНЦП].[Name], [ПВОДМС].[Name], [ПосОБР].[Name], [Рег].[Name], [СБМНЦП].[Name], [СБС].[Name], [ТГВФ].[Name], [УК].[Name]) as [Name]
	,[ИРХ_РЕГ2].[Parent_IRH_REG2_ID]
	,[ИРХ_РЕГ2].Property
from
	(
	select
		E.ID
		,E.AID
		,E.Catalog_ID
		,E.Owner_ID
		,V.ID as [IRH_REG2_Vers_ID]
		,V.AID as [IRH_REG2_Vers_AID]
		,V.StartDate
		,V.EndDate
		,V.Variant_ID
		,E.[UBP_ID]
		,V.[EMail]
		,V.[Order_Number]
		,V.[Parent_IRH_REG2_ID]
		,V.Property
	from
		spr.[IRH_REG2] as E
		inner join spr.[IRH_REG2_Vers] as V on
			V.[IRH_REG2_ID] = E.ID
----------------------------------------------------
----------------------------------------------------
        where V.Variant_ID = @Variant_ID
----------------------------------------------------
----------------------------------------------------
	) as [ИРХ_РЕГ2]
	left join spr.[ifn_KBS](@StartDate, @EndDate, @Variant_ID) as [КБС] on
		[КБС].[KBS_ID] = [ИРХ_РЕГ2].ID
	left join spr.[ifn_Reg](@StartDate, @EndDate, @Variant_ID) as [Рег] on
		[Рег].[Reg_ID] = [ИРХ_РЕГ2].ID
	left join spr.[ifn_TGVF](@StartDate, @EndDate, @Variant_ID) as [ТГВФ] on
		[ТГВФ].[TGVF_ID] = [ИРХ_РЕГ2].ID
	left join spr.[ifn_Gos](@StartDate, @EndDate, @Variant_ID) as [Гос] on
		[Гос].[Gos_ID] = [ИРХ_РЕГ2].ID
	left join spr.[ifn_ZATO](@StartDate, @EndDate, @Variant_ID) as [ЗАТО] on
		[ЗАТО].[ZATO_ID] = [ИРХ_РЕГ2].ID
	left join spr.[ifn_SBMNCP](@StartDate, @EndDate, @Variant_ID) as [СБМНЦП] on
		[СБМНЦП].[SBMNCP_ID] = [ИРХ_РЕГ2].ID
	left join spr.[ifn_UK](@StartDate, @EndDate, @Variant_ID) as [УК] on
		[УК].[UK_ID] = [ИРХ_РЕГ2].ID
	left join spr.[ifn_PosOBR](@StartDate, @EndDate, @Variant_ID) as [ПосОБР] on
		[ПосОБР].[PosOBR_ID] = [ИРХ_РЕГ2].ID
	left join spr.[ifn_PVODMS](@StartDate, @EndDate, @Variant_ID) as [ПВОДМС] on
		[ПВОДМС].[PVODMS_ID] = [ИРХ_РЕГ2].ID
	left join spr.[ifn_DMS](@StartDate, @EndDate, @Variant_ID) as [ДМС] on
		[ДМС].[DMS_ID] = [ИРХ_РЕГ2].ID
	left join spr.[ifn_MNCP](@StartDate, @EndDate, @Variant_ID) as [МНЦП] on
		[МНЦП].[MNCP_ID] = [ИРХ_РЕГ2].ID
	left join spr.[ifn_SBS](@StartDate, @EndDate, @Variant_ID) as [СБС] on
		[СБС].[SBS_ID] = [ИРХ_РЕГ2].ID
	left join spr.[ifn_DepMNCP](@StartDate, @EndDate, @Variant_ID) as [ДепМНЦП] on
		[ДепМНЦП].[DepMNCP_ID] = [ИРХ_РЕГ2].ID
where
	
	[ИРХ_РЕГ2].StartDate = (
											select
												max(_VERS.StartDate) as StartDate 
											from
												spr.[IRH_REG2_Vers] as _VERS
											where
												_VERS.[IRH_REG2_ID] = [ИРХ_РЕГ2].ID
												and _VERS.Variant_ID = @Variant_ID
												and (
														_VERS.StartDate < @EndDate
														or @EndDate is null
													)
										)
	and ([ИРХ_РЕГ2].EndDate > isnull(@StartDate, '19000101') or [ИРХ_РЕГ2].EndDate is null)
	and coalesce([КБС].[KBS_ID],[Рег].[Reg_ID],[ТГВФ].[TGVF_ID],[Гос].[Gos_ID],[ЗАТО].[ZATO_ID],[СБМНЦП].[SBMNCP_ID],[УК].[UK_ID],[ПосОБР].[PosOBR_ID],[ПВОДМС].[PVODMS_ID],[ДМС].[DMS_ID],[МНЦП].[MNCP_ID],[СБС].[SBS_ID],[ДепМНЦП].[DepMNCP_ID]) is not null 
23 мар 17, 15:34    [20326369]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8826
Mike_za,

или обновлять короткими транзакциями или лезть в таблицы, как это уже советовали.
Ваш кэш со срезами относится к категории витрин, соответственно, срезы должны создаваться по расписанию или во время наименьшей нагрузки, а не по каждому чиху.
23 мар 17, 16:46    [20326793]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
s_ustinov
Mike_za,

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


там всячески это уже пытались переставлять, сейчас вопрос не оптимизации ифнки
23 мар 17, 16:59    [20326841]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2307
Mike_za,
Кстати, все ваши ID - это int / bigint?
23 мар 17, 17:00    [20326842]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2307
Mike_za,
меня сильно смущает, что джоин 15 таблиц, как я понимаю, всегда возвращающий только 1 запись, требует кеширования...
У вас или проблемы с индексами, или другие проблемы со структурой базы...
23 мар 17, 17:04    [20326858]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2307
s_ustinov
Mike_za,
Кстати, все ваши ID - это int / bigint?

Вопрос снимается - посмотрел внимательнее на картинку.

Вот именно за такие ID, по которым у вас джойны выполняются -
Дедушка
1. архитектору системы "по шарам"

Нет у вас в справочниках ничего такого, что требовало бы кешировать данные в других табличках (при прямых руках).
В крайнем случае индексированное представление сделать.
23 мар 17, 17:12    [20326886]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
s_ustinov
Mike_za,
меня сильно смущает, что джоин 15 таблиц, как я понимаю, всегда возвращающий только 1 запись, требует кеширования...
У вас или проблемы с индексами, или другие проблемы со структурой базы...

это я написал для примера. когда реально читаются данные похожих срезов присоединяется к документам от пары до 20, и возвращают они конечно не по одной записи.
но даже такой простой запрос к одному срезу компилируется 0.3 сек.
как я писал выше проблема с рекомпиляциями, а не с самим чтением.
23 мар 17, 21:55    [20327600]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
s_ustinov
s_ustinov
Mike_za,
Кстати, все ваши ID - это int / bigint?

Вопрос снимается - посмотрел внимательнее на картинку.

Вот именно за такие ID, по которым у вас джойны выполняются -
Дедушка
1. архитектору системы "по шарам"

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

ну расскажите мне, чем конкретно гуид вместо инта, ощутимо ухудшил нашу систему?
вы заметили это функции???? в зависимочти от входа он генерят разные множества? как это в принципе можно сделать на вью?
23 мар 17, 21:58    [20327614]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
еще раз, магическая фраза про индексы, подходит не всегда.
у меня нет проблем со скоростью чтения даже из кучи таких срезов. сами справочники в массе своей небольшие, и проиндексированы.
23 мар 17, 22:02    [20327621]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2307
Mike_za
еще раз, магическая фраза про индексы, подходит не всегда.
у меня нет проблем со скоростью чтения даже из кучи таких срезов. сами справочники в массе своей небольшие, и проиндексированы

ЗАЧЕМ вам кешировать справочники (и иметь на этом массу проблем)?

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

Но так и не привели обоснование - а почему кеширование является "единственным вменяемым методом"? Одну запись из небольшого проиндексированного справочника база выдаст ОЧЕНЬ быстро, даже если надо заджойнить десяток таблиц.
Единственное, что приходит в голову - или у архитектора системы, или у разработчика БД, или у двух сразу (или два в одном))) - проблемы с квалификацией. И в таких случаях принято заниматься рефакторингом.

Можно, разумеется, и дальше налепить пару костылей - например, есть почти "волшебный способ изнутри сохранения дернуть обновлен кеша так, что бы кеш сразу закомитился и был доступен всем остальным соединениям" - вызвать с помощью Service Broker обновление кеша. Это больше всего похоже на ваше описание "волшебного способа". Но...
23 мар 17, 22:36    [20327700]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2307
Mike_za
ну расскажите мне, чем конкретно гуид вместо инта, ощутимо ухудшил нашу систему?
вы заметили это функции???? в зависимочти от входа он генерят разные множества? как это в принципе можно сделать на вью?


Гуид вместо инта ОЧЕНЬ ощутимо ухудшает любую систему, не только вашу. Просто потому, что вменяемый специалист просто не задумываясь использует в качестве ИД инт. А если там не инт...

Про функции - заметил.
Есть хороший анекдот:
"Идёт девушка - видит - парень косит траву в противогазе: - Ты что, с ума сошёл - зачем противогаз надел? - Я комсомолец - не могу без трудностей... - Кончай х@йней страдать, пошли лучше потрахаемся. - Хорошо - но только в гамаке и стоя..."

А вот это:
Mike_za
вы заметили это функции???? в зависимочти от входа он генерят разные множества? как это в принципе можно сделать на вью?

вообще песня. И опять же возвращает к вопросу квалификации...

Просто ради разнообразия попробуйте способ, который используют обычные люди, а не любители БДСМ - получите вашу итоговую табличку справочника простым запросом без функций и прочих излишеств. Возможно, вы удивитесь - но ТАК тоже можно.

Если ну очень сложно самому - выложите структуру таблиц для этого справочника. Я помогу.
23 мар 17, 23:10    [20327772]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Вы ответы читаете?
Забирать из срезов нужно не одну запись а много.
Проблема не в скорости выборки, а в затратах на рекомпиляции.
24 мар 17, 00:21    [20327846]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
s_ustinov
Mike_za
ну расскажите мне, чем конкретно гуид вместо инта, ощутимо ухудшил нашу систему?
вы заметили это функции???? в зависимочти от входа он генерят разные множества? как это в принципе можно сделать на вью?


Гуид вместо инта ОЧЕНЬ ощутимо ухудшает любую систему, не только вашу. Просто потому, что вменяемый специалист просто не задумываясь использует в качестве ИД инт. А если там не инт...

Про функции - заметил.
Есть хороший анекдот:
"Идёт девушка - видит - парень косит траву в противогазе: - Ты что, с ума сошёл - зачем противогаз надел? - Я комсомолец - не могу без трудностей... - Кончай х@йней страдать, пошли лучше потрахаемся. - Хорошо - но только в гамаке и стоя..."

А вот это:
Mike_za
вы заметили это функции???? в зависимочти от входа он генерят разные множества? как это в принципе можно сделать на вью?

вообще песня. И опять же возвращает к вопросу квалификации...

Просто ради разнообразия попробуйте способ, который используют обычные люди, а не любители БДСМ - получите вашу итоговую табличку справочника простым запросом без функций и прочих излишеств. Возможно, вы удивитесь - но ТАК тоже можно.

Если ну очень сложно самому - выложите структуру таблиц для этого справочника. Я помогу.


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

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

Как это сделать на вью вы так же сказать не можете. Периодов отчетности не 1 или 2. Они есть годововые, квартальные, месячная... Отчетных форм дохренища, чправочников еще больше. Это вче сводится контролируется и тп... Если вы предложите EAV, то я вам сразу скажу, что это не взлетит
24 мар 17, 00:36    [20327855]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Владислав Колосов
Mike_za,

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

Да, всячески пытаемся сдвинуться в сторону заморозки справочников...
24 мар 17, 00:46    [20327870]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31981
Mike_za
я упираюсь в компиляции из-за внешних времянок, и пакости типа ##ываваыа_GUID...
меня тут ничего кроме упрощения планов не спасет
спасёт отказ от внешних времянок, это ведь уже выяснили.
В OLTP использование внешних времянок просаживает производительность в сотню раз, и это ещё оптимистично.
А у вас система OLTP, по крайней мере, вы её в такую превратили.
24 мар 17, 01:44    [20327905]     Ответить | Цитировать Сообщить модератору
 Re: Независимая транзакция  [new]
s_ustinov
Member

Откуда: Munchen, DE
Сообщений: 2307
Mike_za
Ваших аргументовь про гуиды я так и не услышал.
про "вменяемый специалист и интуитивно" простите, но это детский лепет. Те, кто эту систему тогда делал, посчитали что оно того стоит.
Могу вам помочь и привести аргументы за вас: Гуиды больше весят, в момент вставки и кластерный ключ размазывает по диску. Навеное вы еще при блокировании диапазонов можно огрести проблем... Как это вче влияет на конкретно данные запросы вы пока ничего не сказали.

Тип данных uniqueidentifier имеет несколько недостатков.
  • Значения являются длинными и непонятными. Поэтому пользователям сложно вводить их без ошибок и еще сложнее запоминать.
  • Значения являются случайными, в них нельзя поместить никакие последовательности, которые сделали бы значения более осмысленными для пользователей.
  • Не существует способа определить, в какой последовательности были созданы значения типа uniqueidentifier. Они не приспособлены для использования существующими приложениями, полагающимися на последовательное возрастание ключей в последовательности.
  • Занимая 16 байт, тип данных uniqueidentifier является относительно большим по сравнению с другими типами данных (например с 4-байтовыми целыми). Индексы, построенные на ключах типа uniqueidentifier, могут работать медленнее по сравнению с индексами, где используются ключи типа int.

    Если глобальная уникальность не требуется или нужен ключ с последовательно возрастающими значениями, рекомендуется использовать свойство IDENTITY.


    Аргумент один - с инт всё работает быстрее. И почти в каждом проекте это в какой-то момент становится важным.
  • 24 мар 17, 02:18    [20327918]     Ответить | Цитировать Сообщить модератору
     Re: Независимая транзакция  [new]
    s_ustinov
    Member

    Откуда: Munchen, DE
    Сообщений: 2307
    Mike_za
    Такая модель справочников растет из той чехорды, что творят в минфине последние 15 лет. Когда регионы вынуждены предоставлять отчетности на разных интервал в разных кодах справочников.
    Мне думается, что вы ничего сложнее чем получить код сущности из справочника на конкретную дату не встречали. Тут же предметка требует не на дату, а последнее в интервале.

    Как это сделать на вью вы так же сказать не можете. Периодов отчетности не 1 или 2. Они есть годововые, квартальные, месячная... Отчетных форм дохренища, чправочников еще больше. Это вче сводится контролируется и тп... Если вы предложите EAV, то я вам сразу скажу, что это не взлетит

    Мне даже интересно стало.
    Приведите маленький кусок тестовых данных и пару примеров, что должно получиться в итоге. А потом обсудим, могу я сказать, как это сделать во вьюшке, или нет.
    Потому как не видя данных, как это сделать на вью вам никто сказать не сможет.
    24 мар 17, 02:26    [20327919]     Ответить | Цитировать Сообщить модератору
     Re: Независимая транзакция  [new]
    Mike_za
    Member

    Откуда: Москва
    Сообщений: 1176
    alexeyvg
    Mike_za
    я упираюсь в компиляции из-за внешних времянок, и пакости типа ##ываваыа_GUID...
    меня тут ничего кроме упрощения планов не спасет
    спасёт отказ от внешних времянок, это ведь уже выяснили.
    В OLTP использование внешних времянок просаживает производительность в сотню раз, и это ещё оптимистично.
    А у вас система OLTP, по крайней мере, вы её в такую превратили.

    Да, конечно обсуждали и выяснили))) все верно.
    ну вот тут как раз наши архитекторы - создатели по самую шею засели... Год выпиливаем.
    24 мар 17, 10:26    [20328490]     Ответить | Цитировать Сообщить модератору
     Re: Независимая транзакция  [new]
    Mike_za
    Member

    Откуда: Москва
    Сообщений: 1176
    s_ustinov,

    Про гуиды, вы бы всеж сами потестили... В конкретно описанных запросах разницы вы не заметите.
    Про вьюху. Напомню, что вы говорили про индексированную. Индексированная на то и индексированная, что все множество уже сохранено. Как это в принципе возможно, если оно бесконечно?
    24 мар 17, 10:30    [20328512]     Ответить | Цитировать Сообщить модератору
     Re: Независимая транзакция  [new]
    Mike_za
    Member

    Откуда: Москва
    Сообщений: 1176
    s_ustinov,

    Опять таки, касаемо гуидов, в данной системе есть проблемы, но это не суррогатные ключи справочников, тут их вполне можно оправдать. Они мигрируют между скрверами вверх и вних.
    24 мар 17, 10:32    [20328520]     Ответить | Цитировать Сообщить модератору
     Re: Независимая транзакция  [new]
    Mike_za
    Member

    Откуда: Москва
    Сообщений: 1176
    s_ustinov,

    Опять таки, касаемо гуидов, в данной системе есть проблемы, но это не суррогатные ключи справочников, тут их вполне можно оправдать. Они мигрируют между скрверами вверх и вних.
    24 мар 17, 10:34    [20328525]     Ответить | Цитировать Сообщить модератору
     Re: Независимая транзакция  [new]
    забыл пароль....
    Guest
    s_ustinov
    Гуид вместо инта ОЧЕНЬ ощутимо ухудшает любую систему, не только вашу

    очень-очень-очень?
    или все таки НЕ очень? ))
    лепро в студию

    у ГУИД конечно есть недостатки, но все что вы про них написали - пока что выглядит только подобно этому агрументу:
    s_ustinov
    Значения являются длинными и непонятными. Поэтому пользователям сложно вводить их без ошибок и еще сложнее запоминать.

    )))
    24 мар 17, 11:12    [20328709]     Ответить | Цитировать Сообщить модератору
     Re: Независимая транзакция  [new]
    s_ustinov
    Member

    Откуда: Munchen, DE
    Сообщений: 2307
    забыл пароль....
    s_ustinov
    Гуид вместо инта ОЧЕНЬ ощутимо ухудшает любую систему, не только вашу

    очень-очень-очень?
    или все таки НЕ очень? ))
    лепро в студию

    Не сам по себе гуид
    А разработчик БД, который без очень веских причин использует в качестве первичного ключа гуид. Вот этот разработчик ОЧЕНЬ ухудшает работу системы. Для доказательства достаточно посмотреть на проблемы ТС.
    24 мар 17, 12:29    [20329111]     Ответить | Цитировать Сообщить модератору
     Re: Независимая транзакция  [new]
    s_ustinov
    Member

    Откуда: Munchen, DE
    Сообщений: 2307
    Mike_za
    Опять таки, касаемо гуидов, в данной системе есть проблемы, но это не суррогатные ключи справочников, тут их вполне можно оправдать. Они мигрируют между скрверами вверх и вних.

    Если очень нужен гуид - оставляем его как отдельное поле в "центральной" табличке справочника, а в качестве первичного / кластерного ключа используем идентити (инт).
    Само по себе это незначительно ускорит запросы, но ведь ускорит. И последовательная нумерация много где может пригодиться - хотя бы для поиска ошибок в логике.
    24 мар 17, 12:33    [20329132]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
    Все форумы / Microsoft SQL Server Ответить