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

Откуда: Magnitogorsk
Сообщений: 146
Каждый год не по себе от этой проблемы.
Казалось бы, чего проще не давать переводить время назад и все, ан нет не все так просто...

Простой CONSTRAINT типа
 Время постановки ковша/хоппера/вагона < Время провески этих объектов 
порождает массу кошмаров для спящего админа в ночь на 31октября, тем что его вызовут на один из объектов где злосчастная проверка с играла с ним недобрую шутку.
По не воле задумаешься, а как же выкрутиться, чтобы не было таких неприятностей. И каждый год приходишь к одной мысли, а не как!
Не надо переводить и все, это единственное правильное решение DBA,
но нельзя, как того требует начальство, тут же емое производство, далее излагать не хочу, получиться демагогия. Вместо этого вдумаемся в смысл,
реально ли сделать так, чтобы в проверках анализировался переход. При чем
вперед нас мало интересует, так как такие переходы обычно не рождают проблем. Итак, начнем,
допустим мы в CONSTRAINT будем анализировать злосчастное 31октября, ага вы уже догадались, трабла возникает когда необходимо проанализировать был ли уже переход назад на час или нет, так как через час опять мы попадем на те же грабли. Значит нужен флажок. Хм, а в CONSTRAINT его естественно нигде не сохранишь, значит все подобные проверки по времени вынести в триггер? Уууу, это не есть гуд, очень простой код в такую неприятную вещь выливаются, плюс падение производительности в массовых изменениях набора записей. Надеюсь спорить никто не будет, что CONSTRAINT гораздо легче чем триггер. Ну хорошо, допустим согласились все такие проверки перенести в триггера, неплохо, в тригере сохраняем, что в этом году уже был переход и избегаем повторной ситуации через час. Но. Если кто помнит, в прошлом году правительство активно решало вопрос о НЕ переводе по времени и вообще отменить переходы. Ага, значит нужно еще и флажок для всех баз хранить в определенной табличке. Который разрешает перевод или запрещает его, причем на всех серверах одним движением руки.
Допустим Вы разрешили все эти траблы. А теперь задумаемся, а как вы будите, потом анализировать такие данные? В смысле документооборота.
Выходит и претензий к Microsoft на счет сложности проверок не выставишь. Так как потом такие данные и анализировать по нормальному не реально, там тоже придется писать, что-то типа если было 31окт. и время такое-то, а нужно еще и проанализировать в какой момент тогда был, до перехода или после...
Так что же делать? Вижу только два решения
1. Не делать перехода на зимнее время. Но мне придется, из чего вытекает пункт
2. Ждать, вызова от юзеров.
Может кто-то знает ТРЕТЬЕ решенье?
29 окт 04, 13:38    [1071248]     Ответить | Цитировать Сообщить модератору
 Re: Переход на зимнее время  [new]
YellowMan
Member

Откуда: острова
Сообщений: 1047
Я бы посоветовал все время в базе всегда хранить в UTC и переводить его туда-сюда функциями.
Решается проблема с зимнем/летнем временем и часовыми поясами.
29 окт 04, 14:35    [1071539]     Ответить | Цитировать Сообщить модератору
 Re: Переход на зимнее время  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Единственное, что могу посоветовать, так это заменить триггер на UDF в CONSTRAINT.
29 окт 04, 14:36    [1071540]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить