|
|
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Собственно хотелось бы найти типовое решение следующей задачи: Фактически в большинстве поручений и планах указываются не конкретные даты, а их "условные заменители". Например, "за 3 дня до окончания месяца", "в течение 5 рабочих дней с начала квартала" и т.п. Также такие задачи могут иметь определённую повторяемость ("ежемесячно", "ежегодно в первый квартал" и т.д). В таких случаях было бы логичнее хранить в базе данных условия формирования или расчёта таких дат. Т.е. будут примерно такие поля как: ТипИнтервалаДат (день, месяц...), Количество (знак минус - обратный отсчёт), ПризнакРабочихДней (чтобы заджойнить на таблицу с рабочим календарём), ПризнакОтсчёта(предыдущий или последующий месяц) и т.д. Как решается такая задача в лучших практиках? Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 11:11 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Денис Б. Т.е. будут примерно такие поля как: ТипИнтервалаДат (день, месяц...), Количество (знак минус - обратный отсчёт), ПризнакРабочихДней (чтобы заджойнить на таблицу с рабочим календарём), ПризнакОтсчёта(предыдущий или последующий месяц) и т.д. "ПризнакРабочихДней" - это плохая идея. Лучше хранить ссылку на конкретный календарь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 11:49 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Денис Б.Собственно хотелось бы найти типовое решение следующей задачи: Фактически в большинстве поручений и планах указываются не конкретные даты, а их "условные заменители". Например, "за 3 дня до окончания месяца", "в течение 5 рабочих дней с начала квартала" и т.п. Также такие задачи могут иметь определённую повторяемость ("ежемесячно", "ежегодно в первый квартал" и т.д). В таких случаях было бы логичнее хранить в базе данных условия формирования или расчёта таких дат. Т.е. будут примерно такие поля как: ТипИнтервалаДат (день, месяц...), Количество (знак минус - обратный отсчёт), ПризнакРабочихДней (чтобы заджойнить на таблицу с рабочим календарём), ПризнакОтсчёта(предыдущий или последующий месяц) и т.д. Как решается такая задача в лучших практиках? Модератор: Тема перенесена из форума "Microsoft SQL Server". Для семя уяснил. Там где есть "рабочие дни", там обязательно нужен выходных и праздничных дней как минимум на год (текущий год). Т.е. в БД должна быть таблица, полями которой являются даты выходных и праздничных дней. С календарными проще,там можно ограничиться формулой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 11:52 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин"ПризнакРабочихДней" - это плохая идея. Лучше хранить ссылку на конкретный календарь. Для универсального решения не может быть конкретики. Простая функция будет искать дату в какой-то условной таблице с выходными/рабочими днями, которая отстоит от указанной на заданное количество дней. Таблица с выходными может быть разной: Кто-то хранит только выходные и укороченные дни, кто-то все дни с дополнительным битовым полем "Выходной", кто-то наоборот хранит только рабочие дни... ПризнакРабочихДней - это чисто указатель, что поле вычисляемое из таблицы с табель-календарём. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 12:49 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Идея такая: берём некоторое количество(number) временных интервалов(datepart ) от некоторого временного интервала(date). Аналогично с функцией DATEADD (datepart , number , date ), где date также предварительно вычисляется от заданной даты (текущий месяц, предыдущий день, следующий год и т.п.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 12:56 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Денис БПризнакРабочихДней - это чисто указатель, что поле вычисляемое из таблицы с табель-календарём. ...который предполагает, что существует 2, ровно 2 календаря - т.н. "полный" и т.н. "табель календарь". Если появляется нечто третье - систему надо переписывать. сделать вместо признака ссылку на произвольный календарь (т.е. набор дней, по которым будет производиться смещение) - не стоит практически ничего и решает данную проблему навсегда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 13:06 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
По сути нужен некий шаблон для автоматического расчёта сроков исполнения поручений. Например, издаётся приказ, регламентирующий годовую отчётность. Т.е. в нём имеются мероприятия, которые различные подразделения компании должны выполнять с заданной периодичностью. Каждый месяц(или даже день) некий контрольный орган должен необходимым исполнителям выдать предписание(или некую контрольную карточку) для отчёта(или сбора подписей о выполнении). Для того, чтобы было проще заполнять графы со сроками и требуется их автоматически рассчитать (что заранее на весь год, например, не представлялось возможным, так как на тот момент не был утверждён табель-календарь или в подразделениях может измениться штатное расписание или ещё много чего, что может произойти). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 13:26 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинДенис БПризнакРабочихДней - это чисто указатель, что поле вычисляемое из таблицы с табель-календарём. ...который предполагает, что существует 2, ровно 2 календаря - т.н. "полный" и т.н. "табель календарь". Если появляется нечто третье - систему надо переписывать. сделать вместо признака ссылку на произвольный календарь (т.е. набор дней, по которым будет производиться смещение) - не стоит практически ничего и решает данную проблему навсегда. Если на текущий день я не знаю, какой будет табель-календарь через 2 года, о какой ссылке может быть речь? У нас Правительство и внутренний приказ каждый год утверждает новый табель-календарь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 13:38 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Денис Б., Поскольку тема в ветке о проектировании БД, то предположу что интересует как именно (в виде каких таблиц) это хранится в БД. Собственно создаете таблицу с вашими периодичностями (id, name) (..., "за 3 дня до окончания месяца", "в течение 5 рабочих дней с начала квартала" и т.п.). В таблице с приказом делаете поле с ИД этой таблицы. Если необходимо то в отчетах аналогично. Дальше уже дело за приложением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 13:40 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Злой БобрПоскольку тема в ветке о проектировании БД, то предположу что интересует как именно (в виде каких таблиц) это хранится в БД. Собственно создаете таблицу с вашими периодичностями (id, name) (..., "за 3 дня до окончания месяца", "в течение 5 рабочих дней с начала квартала" и т.п.). В таблице с приказом делаете поле с ИД этой таблицы. Если необходимо то в отчетах аналогично. Дальше уже дело за приложением. В таком случае пользователь будет удручён перспективой выбирать из +100500 вариантов и будет часто ошибаться. Плюс проблему по расчёту конкретной даты нужно будет всё равно решать, т.е. таблицы (id, name) явно недостаточно, так как где-то нужно держать конкретную формулу для расчёта даты по конкретному id, или же где-то каким-то образом парсить строку name. Есть ещё фразы, связывающие сроки исполнения с другой задачей из того-же шаблона документа. Я предполагаю, что необходимо хранить ИД родительского(или инициализируещего) мероприятия. По которому также можно отдельной функцией отсчитать временной интервал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 14:02 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Денис Б.Кот Матроскинпропущено... ...который предполагает, что существует 2, ровно 2 календаря - т.н. "полный" и т.н. "табель календарь". Если появляется нечто третье - систему надо переписывать. сделать вместо признака ссылку на произвольный календарь (т.е. набор дней, по которым будет производиться смещение) - не стоит практически ничего и решает данную проблему навсегда. Если на текущий день я не знаю, какой будет табель-календарь через 2 года, о какой ссылке может быть речь? О совершенно обычной ссылке на обьект "календарь" под названием "табель". Заполненность этого табеля к существованию/возможности ссылки на него не имеет никакого отношения. Вы там выше пишете про таблицу с выходными днями - представьте, что в этой таблице помимо поля "дата" есть поле "ID календаря", и лежат выходные дни для России (один ID), Украины (другой ID) и США (третий ID). Вот этот ID я и предлагаю указывать в ссылке. Очень может быть, что эта таблица заполнена только на год вперед, потому что Правительство и внутренний приказ каждый год утверждает новый табель-календарь. И чему это мешает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 14:14 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
[quot Кот Матроскин]Денис Б.представьте, что в этой таблице помимо поля "дата" есть поле "ID календаря", и лежат выходные дни для России (один ID), Украины (другой ID) и США (третий ID). Вот этот ID я и предлагаю указывать в ссылке. При таком раскладе действительно можно и нужно хранить "ID календаря". (пошутю)p.s. Некоторые свидомитые страны наверное так и делают, и хранят ID календаря Крыма (на всякий случай). (пошутю2) Жалко, что ограничения SQL-сервера не позволяют хранить ещё "ID календарной системы", а то бы ещё календарь Майя или друидов можно было учесть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 14:36 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
> календарь Майя или друидов можно было учесть Уважаемый дон никогда не сталкивался с мусульманским календарём? И с понятием "финансовый год"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 15:03 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Денис Б.Как решается такая задача в лучших практиках? Про лучшие практики не скажу, скажу про свою. Сходу очевидно, что речь идёт о наличии некоего (потенциально расширяемого) списка функций. Более того, по опыту, клиенты любят такие вещи кастомизировать (скажем, добавлять какой-нибудь "в следующий рабочий понедельник после...") По бизнес-логике от этой структуры данных требуется по сути единственная операция: "вычислить значение в таких-то условиях". Поэтому структура по сути должна хранить: выбранную функцию и параметры к ней. При этом желательно, чтобы кастомизация не требовала изменений "ядерного" кода, то есть, грубо говоря, я мог бы сделать Код: plsql 1. и эта функция подхватилась бы системой и стала доступна для выбора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 15:23 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Денис Б.В таком случае пользователь будет удручён перспективой выбирать из +100500 вариантов и будет часто ошибаться. От человеческого фактора защиты нет. Денис Б. Плюс проблему по расчёту конкретной даты нужно будет всё равно решать, т.е. таблицы (id, name) явно недостаточно, так как где-то нужно держать конкретную формулу для расчёта даты по конкретному id, или же где-то каким-то образом парсить строку name. Злой Бобр Дальше уже дело за приложением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2015, 16:31 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
По календарям, я считаю, можно закончить с того, чем и начиналось: Хранится только признак того, что возможен "сдвиг" даты и его расчётом должна заниматься некая функция. Она сама должна знать какой и где взять календарь и что из-него извлечь. Про всякие ИДкалендарей можно смело забыть. И даже если предполагать, что может быть несколько календарей рабочих дней для разных стран, то это не верно, так как организация может быть куплена или перейти под юрисдикцию другого государства. Да что там говорить о разных странах... у нас в субъектах также есть национальные праздники. А ещё... в коллективном договоре организации может быть прописан выходной день в день рождения, для молодых родителей - 1 сентября и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 07:27 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
softwarerСходу очевидно, что речь идёт о наличии некоего (потенциально расширяемого) списка функций. Более того, по опыту, клиенты любят такие вещи кастомизировать (скажем, добавлять какой-нибудь "в следующий рабочий понедельник после...") По бизнес-логике от этой структуры данных требуется по сути единственная операция: "вычислить значение в таких-то условиях". Поэтому структура по сути должна хранить: выбранную функцию и параметры к ней. При этом желательно, чтобы кастомизация не требовала изменений "ядерного" кода, то есть, грубо говоря, я мог бы сделать Код: plsql 1. и эта функция подхватилась бы системой и стала доступна для выбора. Мне хочется сделать универсальное решение. Каждый раз писать новую функцию это проблематично. Как вариант, можно сделать такой пользовательский интерфейс, где юзер сможет создавать свои условия по установке дат. Но тогда в любом случае нужна будет архитектура базы данных, способная учесть универсальный механизм по установке сроков и их зависимостей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 07:35 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Подобные системы задания дат есть в развитых финансовых системах - именно так формулируется в договорах на совершение сделок. Задаются правило переноса дней в случае попадания на выходной, праздники по календараям каких стран должны учитываться и т.п. Реализовать это добросовестно - нужно много таблиц и средств управления/настройкой этого хозяйства. Как промежуточный вариант - по более простым условиям генерируются плановые даты, которые при необходимости чуть корректируются и используются в дальнейшем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 08:59 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
П-ЛПодобные системы задания дат есть в развитых финансовых системах - именно так формулируется в договорах на совершение сделок. Задаются правило переноса дней в случае попадания на выходной, праздники по календараям каких стран должны учитываться и т.п. Реализовать это добросовестно - нужно много таблиц и средств управления/настройкой этого хозяйства. Как промежуточный вариант - по более простым условиям генерируются плановые даты, которые при необходимости чуть корректируются и используются в дальнейшем. Ход мыслей понятен. Я сначала примерно так и хотел сделать: 1 ) каждый день (точнее ночь) формируется список задач, которые с учётом пересчёта сроков выпадают на ближайшую перспективу 2) юзер соглашается или меняет срок. Проблемы следующие: заданий может быть много (здесь никуда не уйти); как точно определить, что о задаче нужно напомнить; но самая главная проблема остаётся: как уйти от "лингвистического" задания дат, т.е. "последний день месяца", "каждая вторая суббота" и т.п. Я всё-же рассчитываю на некое универсальное решение по заданию и хранению в базе сроков с разными "лингвистическими" условиями или параметрами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 09:24 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Денис Б.Про всякие ИДкалендарей можно смело забыть. И даже если предполагать, что может быть несколько календарей рабочих дней для разных стран, то это не верно, так как организация может быть куплена или перейти под юрисдикцию другого государства "Потому что бурбулятор" Какая связь между наличием в системе нескольких календарей и возможной продажей организации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 09:57 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин"Потому что бурбулятор" Какая связь между наличием в системе нескольких календарей и возможной продажей организации? Во первых: не бурбулятор, а гладиоус. Во вторых: связи нет. При продаже организации возможна необходимость в смене табель-календаря. В постановке вопроса говорится о том, что нужен признак, отвечающий, что зависимость сроков находится в зависимости от рабочего времени, а не от календарного времяисчисления. А рабочее время кроме табеля-календаря может зависеть ещё от многих факторов. Например, приказом по организации отдел отправлен на прохождение диспансеризации или на субботник, т.е. его рабочее время с табель-календарём не сходится (если конечно не сочинять для каждого такого случая новый табель-календарь, но это уже фанатизм). Поэтому - только функция, получающая на вход дату и проверяющая по разным таблицам необходимость сдвига срока. Кот Матроскинсуществует 2, ровно 2 календаря - т.н. "полный" и т.н. "табель календарь". Если появляется нечто третье - систему надо переписывать. Если в системе хранится "полный" календарь, то разработчиков системы надо самих переписывать, если конечно они не являются противниками Григореанского календаря (может я пропустил, когда его отменят? и выйдет релиз соответствующих серверов баз данных?) и имеют собственные представления о времяисчислении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 11:51 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Денис Б., авторглавная проблема остаётся: как уйти от "лингвистического" задания дат, т.е. "последний день месяца", "каждая вторая суббота" и т.п. Кто же не дает ? Проанализируйте и формализуйте все варианты условий задания дат. Придумайте форму хранения формализованных (закодированных) представлений, переведенных с лингвистического задания, и процедуру, которая будет генерить по этому внутреннему представлению реальные потоки дат. Это достаточно частная задачка, даже не особо сложная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 12:05 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
> именно так формулируется в договорах на совершение сделок Это не единственное применение. > нужно много таблиц и средств управления/настройкой этого хозяйства Да ладно, откуда там много таблиц? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 12:08 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Денис Б.Кот Матроскин"Потому что бурбулятор" Какая связь между наличием в системе нескольких календарей и возможной продажей организации? Во первых: не бурбулятор, а гладиоус. Во вторых: связи нет. При продаже организации возможна необходимость в смене табель-календаря. В постановке вопроса говорится о том, что нужен признак, отвечающий, что зависимость сроков находится в зависимости от рабочего времени, а не от календарного времяисчисления. А рабочее время кроме табеля-календаря может зависеть ещё от многих факторов. Именно поэтому ПризнакРабочихДней - это не рабочее решение. Лучше поздно, чем никогда Денис Б.Например, приказом по организации отдел отправлен на прохождение диспансеризации или на субботник, т.е. его рабочее время с табель-календарём не сходится (если конечно не сочинять для каждого такого случая новый табель-календарь, но это уже фанатизм). Для какого "каждого такого случая"? Если нужно отсчитывать не по "рабочим дням страны", а по "рабочим дням организации" (хотя мне сложно представить такой кейс) - заводится 1(один) дополнительный календарь "Рабочий календарь нашей организации", оттуда вычеркиваются все дни диспансеризаций и вставляются дни субботников, и в соответствующих документах делается ссылка на него, а не на "рабочий календарь страны" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 12:11 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
...а по "рабочим дням организации" (хотя мне сложно представить такой кейс)А что тут представлять ? Организация может работать даже в режиме 365/24. по сабжу: Нужно иметь процедуру превращения правила в дату. После изменения "правила" или "даты документа" запускать процедуру для актуализации даты. Тут не существует идеального решения. Нужно учитывать специфику предметной области. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 12:28 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
постоянный мембер...а по "рабочим дням организации" (хотя мне сложно представить такой кейс)А что тут представлять ? Организация может работать даже в режиме 365/24. А может работать в режиме 0/0 - но я говорил не про это. Мне сложно представить документ, ссылающийся именно на рабочие дни организации (т.е. по описанию, включая субботники и исключая диспансеризации). В случае чего в суде представители организации будут довольно глупо смотреться с заявлениями вроде "Ну да, мы обязаны были сделать расчет в течение 5 рабочих дней - но мы же один день не работали, а ходили на диспансеризацию!" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 12:43 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинМне сложно представить документ, ссылающийся именно на рабочие дни организации Я бы предположил, что это должен быть документ, относящийся к внутренней деятельности этой организации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 17:12 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
softwarerКот МатроскинМне сложно представить документ, ссылающийся именно на рабочие дни организации Я бы предположил, что это должен быть документ, относящийся к внутренней деятельности этой организации. Да даже такой документ может легко оказаться в суде (хотя бы в рамках трудового спора) - и что тогда? В каждом документе делать сноску "рабочих дней... согласно утвержденному в организации списку рабочих дней"? Не проще не лохматить бабушку а просто при утверждении документа пересчитывать эти "внутренние рабочие дни" во что-то общепринятое? Причем я не утверждаю, что это категорически невозможно - "есть многое на свете, друг Горацио" и далее по тексту. Более того - как раз этот пример ТС-а является подтверждением моей позиции :) Но вот лично мне - представить подобный документ сложно. Возможно, это узость кругозора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 18:00 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Денис Б.Мне хочется сделать универсальное решение. Каждый раз писать новую функцию это проблематично. Как вариант, можно сделать такой пользовательский интерфейс, где юзер сможет создавать свои условия по установке дат. Но тогда в любом случае нужна будет архитектура базы данных, способная учесть универсальный механизм по установке сроков и их зависимостей.Если хочется сделать систему, удобную для пользователей, то вариант sofwarer'а лучше. Несколько готовых функций в качестве "преднастройки". Не надо считать, что пользователи идиоты и не смогут написать еще одну функцию. А вот "универсальный пользовательский интерфейс" с кучей полей, опций и переключателей заставит пользователя вспоминать разработчика матом при каждой попытке использования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 00:44 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинМне сложно представить документ, ссылающийся именно на рабочие дни организации (т.е. по описанию, включая субботники и исключая диспансеризации)." Как-то звучит противоречиво. То ИДкалендаря обязательно запихать, то сложно представить такую ситуацию. Я же говорю, что есть мероприятия строго календарные (они могут касаться внешней отчётности, договоров и т.д.), а есть не такие уж и строгие. Кот МатроскинВ случае чего в суде представители организации будут довольно глупо смотреться с заявлениями вроде "Ну да, мы обязаны были сделать расчет в течение 5 рабочих дней - но мы же один день не работали, а ходили на диспансеризацию!" Причём здесь ответственность исполнителей? Почему не успели - их проблемы (переносите, согласовывайте, ночуйте...). Им был дан срок и нужно проконтролировать исполнение. Но зачем ломиться к ним с контрольной проверкой, если знаем, что они в суде сегодня? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 08:01 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
softwarerКот МатроскинМне сложно представить документ, ссылающийся именно на рабочие дни организации Я бы предположил, что это должен быть документ, относящийся к внутренней деятельности этой организации. Не нужно ссылаться на непредвиденные ситуации. Нужно тупо поставить галочку, что срок строго директивный и исполняется вне зависимости от внутренних условий день в день. А если галочки нет, то функция должна проверить кучу условностей, табелей, графиков, событий и предложить перенос срока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 08:10 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Денис Б.Кот МатроскинМне сложно представить документ, ссылающийся именно на рабочие дни организации (т.е. по описанию, включая субботники и исключая диспансеризации)." Как-то звучит противоречиво. То ИДкалендаря обязательно запихать, то сложно представить такую ситуацию. Никакого противоречия нет - "запихать ID календаря" нужно, потому что календари бывают разные, но конкретный вид календаря "Рабочие дни вместе с субботниками" - у меня вызывает сомнения. "Может существовать множество различных планет, но в планету, состоящую целиком из голландского сыра, я не верю" - как-то так. Вот отрицание этого тезиса "ИД Календаря не нужно, и так ясно, от какого календаря отсчитывать, хотя может существовать еще и календарь рабочих дней вместе с субботниками" - оно противоречиво, да ;) Денис Б.Кот МатроскинВ случае чего в суде представители организации будут довольно глупо смотреться с заявлениями вроде "Ну да, мы обязаны были сделать расчет в течение 5 рабочих дней - но мы же один день не работали, а ходили на диспансеризацию!" Причём здесь ответственность исполнителей? Почему не успели - их проблемы (переносите, согласовывайте, ночуйте...). Им был дан срок и нужно проконтролировать исполнение. Но зачем ломиться к ним с контрольной проверкой, если знаем, что они в суде сегодня? [/quot] Вы отвечаете на что-то совсем другое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 09:50 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Мне сложно представить документ, ссылающийся именно на рабочие дни организацииИ в чем сложность ? Плохое воображение ? :) Берем ежемесячный кейс "сверить в тлф. режиме суммы" по расписанию "каждого 1-го числа месяца". Как быть с 1 января и 1 мая ? А если еще выходные наложатся ? Сверка возможна только в ближайший раб.день. В некот. орг-циях эти дни могут быть рабочими. Поэтому именно "рабдень организации" (если точнее, то рабдень конкретного подразделения) - единственный способ точно спланировать задания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 10:36 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
постоянный мембер Мне сложно представить документ, ссылающийся именно на рабочие дни организацииИ в чем сложность ? Плохое воображение ? :) Берем ежемесячный кейс "сверить в тлф. режиме суммы" по расписанию "каждого 1-го числа месяца". Вы внимательно прочитали мой тезис? Какой документ порождает этот "кейс", и как он буквально звучит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 11:22 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинВы внимательно прочитали мой тезис? Какой документ порождает этот "кейс", и как он буквально звучит?Да мало ли какой ? Вполне достаточно, что это жизненный кейс. :) Не нужно понимать дословно "Рабочий день организации". Это может быть "Рабочий день отдела" или даже "банковский день в другой стране". В общем случае понадобится ссылка на рабочие календари, кот. может быть много и разных. Может даже понадобится наложение двух календарей для поиска ближайшего общего дня, н-р пересечение раб.дня бухгалтерии и банковского дня в Германии. :) Вариантов много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 12:40 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
постоянный мемберКот МатроскинВы внимательно прочитали мой тезис? Какой документ порождает этот "кейс", и как он буквально звучит?Да мало ли какой ? Вполне достаточно, что это жизненный кейс. :) Не нужно понимать дословно "Рабочий день организации". Т.е. Вы, когда квотите мое утверждение, возражаете не мне, а голосам в своей голове? Ну, не буду мешать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 13:38 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Если храним раздел даты (день, месяц, квартал и т.д.) и приращение, то как лучше организовать хранение в базе данных? Текстовое поле или таблица (ИДразделаДаты, РазделДаты)? При использовании в запросах функций работы с датами хотелось бы избежать динамического sql. Писать свою функцию работы с датами на основе системных (например, dateadd) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2015, 14:25 |
|
||
|
Вместо даты хранить условия её расчёта
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Складываем в табличку текст РазделДаты и используем свою функцию по собиранию нужной даты SELECT dbo.UserDateadd('year', 1, GetDate()) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2015, 09:29 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1540600]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
143ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 10ms |
| total: | 254ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...