Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 4 вперед Ctrl→ все |
alexeyvg Member Откуда: Moscow Сообщений: 31778 |
Кроме решения вывода в отчёте отсутствующих дат, она в реальных системах нужна, например, для хранения информации о рабочих и праздничных дней, ускорения (инедксации) поисков типа "все понедельники", а так же для хранения в статике всяких сложных расчётов, типа количества рабочих часов, и пр. |
||
23 май 16, 21:28 [19209542] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
nekiyl, Последнее приложение впечатляет |
23 май 16, 21:40 [19209571] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
А так нельзя было ? DECLARE @StartDate DATE = '20010101' DECLARE @EndDate DATE = '20790101' ;WITH E1(N) AS ( SELECT * FROM ( VALUES (0),(1),(2),(3),(4), (5),(6),(7),(8),(9) ) t(N) ), E2(N) AS (SELECT a.N * 10 + b.N FROM E1 a, E1 b), E4(N) AS (SELECT a.N * 100 + b.n FROM E2 a, E2 b), E8(N) AS (SELECT a.N * 10000 + b.N FROM E4 a, E4 b) SELECT DATEADD(DAY, N, @StartDate) FROM ( SELECT TOP(DATEDIFF(DAY, @StartDate, @EndDate) + 1) N FROM E8 ) t ORDER BY N |
||
24 май 16, 12:08 [19211437] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9633 |
|
|||
24 май 16, 13:02 [19211881] Ответить | Цитировать Сообщить модератору |
iljy Member Откуда: Сообщений: 8711 |
a_voronin, можно. Но есть нюанс. При использовании такого генератора оптимизатор считает возвращаемую им последовательность неупорядоченной. Как следствие, top вам может вернуть все, что угодно (теоретически, но думаю, на практике тоже можно этого добиться). А если вы добавите туда ORDER BY, то он сначала вынужден будет сгенерить всю последовательность, отсортировать ее, и только потом выбрать. Ну и более практическое следствие (на датах это не проявится, он почему-то не умеет оптимизировать сортировку по DATEADD, но вообще на числах - легко): если вы захотите получить уже усеченную выдачу генератора отсортированной, то в плане появится явная операция сортировки. Проверьте для запроса типа SELECT ROW_NUMBER() OVER (ORDER BY 1/0) + 100 FROM ( SELECT TOP(DATEDIFF(DAY, @StartDate, @EndDate) + 1) N FROM E8 ) t order by 1 |
24 май 16, 13:07 [19211912] Ответить | Цитировать Сообщить модератору |
iljy Member Откуда: Сообщений: 8711 |
a_voronin, ну и да, как уже показал invm, вычисление выражения с умножениями занимает сильно больше времени, чем просто генерация последовательности целых чисел. И если уж заговорили про скорость, то самый быстрый вариант это все еще таблица с целыми числами. |
24 май 16, 13:14 [19211954] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9633 |
|
||
24 май 16, 13:57 [19212280] Ответить | Цитировать Сообщить модератору |
iljy Member Откуда: Сообщений: 8711 |
invm, не, ну теоретически можно попробовать подобрать порядок соединений и т.п., но баловство это, конечно. |
24 май 16, 15:09 [19212930] Ответить | Цитировать Сообщить модератору |
LSV Member [заблокирован] Откуда: Киев Сообщений: 30817 |
по сабжу: только готовая таблица с датами, усиленная дополнительными полями: номер года, месяца, недели, праздники и т.д. + это лаконично и удобно, особенно в сложных запросах; + это можно использовать многократно; + это можно дополнить любыми нужными параметрами/полями; + это быстро, т.к. маленькая живая таблица + индексы; + это одинаково заработает на всех СУБД, т.е. это портабельно. Искренне не понимаю, зачем предлагают разного рода генерацию списка внутри запросов. Идиотизм, ИМХО. Жалко таблички с неск. полями ? :) |
25 май 16, 09:13 [19215855] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31778 |
В рутинных инженерных расчётах, наверное, эти разработчики Pi тоже не вставляют в код как константу, а неделями соревнуются в оптимизации алгоритмов расчётов, для обычного вычисления площади сечения арматурного прутка? Какие перемножения множеств? Какие spt_values?? Какие рекурсии??? Нужен календарь, используйте календарь, никаких других вариантов! Все эти извращения нужны только для одного - заполнить таблицу-календарь после её создания. И такая задача не стоит обсуждения, в силу её разовости и примитивности. |
||
25 май 16, 10:11 [19216185] Ответить | Цитировать Сообщить модератору |
iap Member Откуда: Москва Сообщений: 47047 |
(если не требуются специфические переносы выходных, праздники и т.п.) |
||
25 май 16, 10:32 [19216331] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31778 |
Для всяких управленческо-финансовых систем календарь нужен на 99%, в остальных по обстоятельствам. А таблица с числами нужна практически везде. Можно, конечно, использовать и spt_values, но это менее эффективно и менее надёжно.
Если бизнес требования можно реализовать кодом или моделью данных (таблицами), выбирайте второе. Оно будет быстрее, проще, надёжнее, лучше для сопровождения, лучше для повторного использования, понятнее для новых сотрудников и для начальников. Хоть даже 4000 таблиц, а не 400, не проблема. Календарь на 100 лет будет содержать 36500 строк и занимать, скажем, пусть даже мегабайт, ничего страшного. Вы же не пишите: "в БД и так 100500 строк кода, куда ещё новый вставлять?" Почему такое предубеждение к таблицам? И такая любовь к коду? :-) |
||||||
25 май 16, 10:47 [19216439] Ответить | Цитировать Сообщить модератору |
Jovanny Member Откуда: Сообщений: 1196 |
Ух ты! А где такой принцип прописан? |
||
25 май 16, 12:14 [19217099] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
в здаровой логике |
||||
25 май 16, 12:15 [19217104] Ответить | Цитировать Сообщить модератору |
Jovanny Member Откуда: Сообщений: 1196 |
А кто у нас носители этой самой логики? |
||||
25 май 16, 12:17 [19217120] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31778 |
И в этом же посте приводится обоснование. |
||||
25 май 16, 12:21 [19217143] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
да вообщем-то все кто понимают, что если по бизнесс-процессу необходимо генерировать какие-то части календаря, то здравый смысл хранить его ввиде таблицы, и не стесняясь расширяя его понятиями календарный - рабочий и т.п. |
||||
25 май 16, 12:21 [19217144] Ответить | Цитировать Сообщить модератору |
Jovanny Member Откуда: Сообщений: 1196 |
TaPaK, В общем, кто с Вами согласен, тот здравомыслящий, кто нет - тот дебил. Как-то так? Ну ладно, это лирика. Случай из практики. Было у нас приложение, использующее таблицу-календарь для различных отчётов. И как-то кто-то по недомыслию или злому умыслу удалил там несколько строк. И генерировали мы несколько месяцев удивительные отчёты, повествующие о том, как всё у нас хорошо. Пока не обнаружили, что дни, когда у нас всё плохо, удалены из таблицы-календаря. Отчёты-то генерировались за большие периоды, никто не анализировал каждый день. |
25 май 16, 12:31 [19217237] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
был у нас случай серверная сгорела и так и жили какое-то время пока не заметили |
||
25 май 16, 12:34 [19217268] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9633 |
Просто не нужно этим "кто-то" давать разрешений больше, чем необходимо. Т.е. проблема ваша - административная. А вообще, во избежание подобного рода проблем, таблицы типа календаря и т.п. выносят в отдельную read-only БД, а в основной БД пользуются синонимами. |
||
25 май 16, 12:38 [19217299] Ответить | Цитировать Сообщить модератору |
iap Member Откуда: Москва Сообщений: 47047 |
А права на таблицу-календарь отнять у всех, кроме администратора на всё, кроме SELECTа. |
||||
25 май 16, 12:44 [19217347] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9633 |
Но таблицы в отдельной read-only БД имеют ряд преимуществ: - не нужно в каждой БД иметь свои копии таких таблиц. - экономим на блокировках, т.к. БД read-only. |
||
25 май 16, 12:52 [19217428] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31778 |
Удалить можно всё, что угодно, любые важные данные, и будет всё криво в отдельные дни, или даже во все дни. Кстати, системные и справочные данные должны проверяться и заливаться при деплое версии, соответствовать проекту, их изменения должны прослеживаться в истории в сорс-контрле, и быть привязаны к базнес-задачам, проверены тестерами и т.д., а не корячиться разрабами на боевой базе ручками без контроля и проверок. В идеале. Тогда таких багов будет меньше. А по существу, вот у меня прописаны в обоснованиях 6 пунктов, у вас по ним нет возражений? Понятно, что "принципы" - они и есть "принципы", т.е. в каждом конкретном случае может быть не все 6 плюсов, а меньше. И даже иногда выгоднее написать код, а не делать таблицы. Тем не менее в большинстве случаев это верно. Множества, средства контроля их целостности и механизмы построения планов запросов хорошо отлажены в РСУБД, разумно это использовать по максимуму. |
||
25 май 16, 12:57 [19217482] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31778 |
Может, лучше вынести такие справочники в рид-онли файлгруппу? |
||||
25 май 16, 12:59 [19217499] Ответить | Цитировать Сообщить модератору |
Jovanny Member Откуда: Сообщений: 1196 |
Т.е., вместо использования in-line табличной функции, генерирующей диапазон дат, надо так много телодвижений?
Насчёт справочников возражений нет, но для простой последовательности создавать таблицу - это так в духе SQL Server 2000. |
||||
25 май 16, 13:06 [19217549] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 4 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |