Может в каких то региональных филиалах?
Да и… не думаю что в других организациях в таких же условиях люди сильно иначе работают: если сват/брат подходит на должность, то почему бы его не взять?
Составление расписаний всегда весёлая задача )
…
я бы добавил ещё «данные вводятся вручную» (соответственно не всегда консистентные) и «забирать данные надо из трёх дублирующих систем», проверяя валидность другими системами.
1. А где то это делается быстро и нативно без предрасчёта?
2. Никто же не заставляет нормализировать в край. Да и да — если два поля не сводятся к одному то SQL не будет к этому стремиться. Или я неправильно понял задачу?
3. В чём проблема? )
Проблема в том, что половина из описанных способов повторно обращается к данным, из-за чего работает очень не очень (особенно если таблицы не такие простые и маленькие).
И весь смысл, обычно, сводится к тому, что бы как можно меньше обращаться к таблицам, как можно больше использовать данные из индексов и как можно ближе писать запросы к тому, что система сможет понять и правильно интерпретировать. =)
select tg.*,
coalesce(sum(tg.val) over (partition by tg.grp order by tg.dt
rows between unbounded preceding and current row),
0) as total
from test_groups tg
order by tg.grp, tg.dt;
rows between unbounded preceding and current row
Не обязателен — оконная функция суммы с order by будет показывать нарастающий итог по текущее значение по умолчанию.
10. Обновление через локальную переменную (SQL Server)
За это респект. Редкое знание но самое быстрое из перечисленных решений, в случае если нужно не просто накопительную сумму искать, а, к примеру, переходы через нули или более сложные условные накопительные изменения.
Но есть нюанс — UPDATE таблицы может происходить (строго говоря) в любом порядке, из-за чего накопительный итог не будет иметь смысла.
Поэтому рекомендуется заливать данные во временную таблицу (SELECT * INTO #TMP FROM ....), а потом построить по ней кластерный индекс по необходимой сортировке (CREATE CLUSTERED INDEX IX_SOME_INDEX ON #TMP1 (Sort_field).
В этом случае последовательность нарастающего итога гарантированно пойдёт по сортировке кластерного индекса.
Есть подозрение, что проблема не в сливах.
Просто информационная атак и нагнетание обстановки для… для разного.
В политических целях от конкурентов, во внутребанковских подковёрных играх (надо же будет на кого то всё это свалить) итп-итп.
Вот и я не знаю о чём вы спорите.
Я лишь объединил некоторые понятия по общим признакам.
Одни начали докапываться что признаки могут со временем меняться.
Вы — посчитали это руководством к действию.
т.е. если это легализуют, то из этого государство сможет извлечь выгоду и это сейчас запрещено законом.
То есть, если будет принят закон, по которому, скажем, для снижения нагрузки на общественный транспорт, вам следует явиться для повешения, то у вас будет только один вопрос: «Брать ли с собой верёвку?»
Пожалуйста, не надо выдавать свои фантазии за мои слова )
А проститутка продаётся не за деньги?
Или кого то предаёт?
Она так же продаёт своё время и навыки.
За деньги.
Вы сами сказали, что за бесплатно будет работать только дурак.
Значит работают за деньги, что и есть — продавать себя. Свой труд/знания/умения/товары и что там ещё. За деньги.
Да и… не думаю что в других организациях в таких же условиях люди сильно иначе работают: если сват/брат подходит на должность, то почему бы его не взять?
…
я бы добавил ещё «данные вводятся вручную» (соответственно не всегда консистентные) и «забирать данные надо из трёх дублирующих систем», проверяя валидность другими системами.
2. Никто же не заставляет нормализировать в край. Да и да — если два поля не сводятся к одному то SQL не будет к этому стремиться. Или я неправильно понял задачу?
3. В чём проблема? )
И весь смысл, обычно, сводится к тому, что бы как можно меньше обращаться к таблицам, как можно больше использовать данные из индексов и как можно ближе писать запросы к тому, что система сможет понять и правильно интерпретировать. =)
rows between unbounded preceding and current row
Не обязателен — оконная функция суммы с order by будет показывать нарастающий итог по текущее значение по умолчанию.
За это респект. Редкое знание но самое быстрое из перечисленных решений, в случае если нужно не просто накопительную сумму искать, а, к примеру, переходы через нули или более сложные условные накопительные изменения.
Но есть нюанс — UPDATE таблицы может происходить (строго говоря) в любом порядке, из-за чего накопительный итог не будет иметь смысла.
Поэтому рекомендуется заливать данные во временную таблицу (SELECT * INTO #TMP FROM ....), а потом построить по ней кластерный индекс по необходимой сортировке (CREATE CLUSTERED INDEX IX_SOME_INDEX ON #TMP1 (Sort_field).
В этом случае последовательность нарастающего итога гарантированно пойдёт по сортировке кластерного индекса.
Просто информационная атак и нагнетание обстановки для… для разного.
В политических целях от конкурентов, во внутребанковских подковёрных играх (надо же будет на кого то всё это свалить) итп-итп.
А данные утекали у всех и всегда )
Я лишь объединил некоторые понятия по общим признакам.
Одни начали докапываться что признаки могут со временем меняться.
Вы — посчитали это руководством к действию.
Я — вообще не понял такого бурления )
— У меня небыло теории
— Она не рассыпалась
А доведение до абсурда — никогда ни к чему хорошему не приводило.
Вообще, у меня создаётся впечатление, что люди не понимают разницы в значениях слова «можно». )
Более того — в разные времена даже убийство было вполне легально.
Или вы считаете, что эти явления не объеденены данными характеристиками?
Пожалуйста, не надо выдавать свои фантазии за мои слова )
Или кого то предаёт?
Она так же продаёт своё время и навыки.
За деньги.
Вы сами сказали, что за бесплатно будет работать только дурак.
Значит работают за деньги, что и есть — продавать себя. Свой труд/знания/умения/товары и что там ещё. За деньги.
Очевидно, что зарплата в 300к — это плохой подход к защите своих данных )