Комментарии 27
Как-то все слишком усложнили тут. Вот простая схема:
— список сотрудников;
— список перемещений (прием, перевод, увольнение) с датой документа.
Всё. На основе этих сведений можно делать любые запросы и отчеты. Этот вариант в начале статьи предлагается как слишком затратный и т.п. Как раз для этих случаев и используется «регистр сведений» (аналог из 1С), где хранится актуальная информация по сотрудниках на текущий момент времени.
— список сотрудников;
— список перемещений (прием, перевод, увольнение) с датой документа.
Всё. На основе этих сведений можно делать любые запросы и отчеты. Этот вариант в начале статьи предлагается как слишком затратный и т.п. Как раз для этих случаев и используется «регистр сведений» (аналог из 1С), где хранится актуальная информация по сотрудниках на текущий момент времени.
НЛО прилетело и опубликовало эту надпись здесь
group by разве не спасёт отца русской демократии?
думаю, нет :)
особенно тогда, когда выборка не ограничивается только 2-мя объектами — чем их больше, тем сложнее будет использовать group by (вплоть до «невозможно»)
особенно тогда, когда выборка не ограничивается только 2-мя объектами — чем их больше, тем сложнее будет использовать group by (вплоть до «невозможно»)
ну приведи чтоли какой-нибудь невозможный пример
Например, если в контексте статьи потребуется вывести список Работников и их непосредственных начальников. В Работниках уже будет group by, в Начальниках тоже придется его использовать (т.к. начальник может меняться у работника), итоговый запрос я даже боюсь представить как написать без подзапроса.
странное желание. особенно в свете того, что начальники — тоже работники и у них есть начальники. но даже если заменить начальников на отделы, то что мешает отсортировать на дате, сгруппировать по номерам работников и номерам отделов и выбрать последнюю запись?
Для хранения истории вы предложили вполне адекватный подход — выносить карточку сущности в отдельную таблицу, используя при это основную таблицу, как связочную с небольшой константной информационной нагрузкой.
Неадекватность тут в том, что индексы будут строиться по всей истории, соответственно замедляя выборки (это в лучшем случае). Ну и постройка запроса становится неестественной.
Не проще ли было наряду с историей карточек хранить последнюю копию (заполненный соответственно набор полей с аналогичными именами колонок) карточки сущности непосредственно в сущности? В таком случае будет использоваться укороченный индекс для поиска данных — количество записей в таблице сущностей по определению меньше либо равно количеству записей в таблице карточек. Да и запросы приобретают естественный вид.
Кроме того, в карточку сущности полезно ввести дату создания карточки и ссылку (поле с идентификатором записи) на сущность, а в сущность — ссылку на последнюю карточку. Таким образом упростится обход всей этой структуры, да и можно будет без проблем отказаться от хранения данных карточки в самой сущности, если такое кэширование не применимо в какой-либо ситуации.
Неадекватность тут в том, что индексы будут строиться по всей истории, соответственно замедляя выборки (это в лучшем случае). Ну и постройка запроса становится неестественной.
Не проще ли было наряду с историей карточек хранить последнюю копию (заполненный соответственно набор полей с аналогичными именами колонок) карточки сущности непосредственно в сущности? В таком случае будет использоваться укороченный индекс для поиска данных — количество записей в таблице сущностей по определению меньше либо равно количеству записей в таблице карточек. Да и запросы приобретают естественный вид.
Кроме того, в карточку сущности полезно ввести дату создания карточки и ссылку (поле с идентификатором записи) на сущность, а в сущность — ссылку на последнюю карточку. Таким образом упростится обход всей этой структуры, да и можно будет без проблем отказаться от хранения данных карточки в самой сущности, если такое кэширование не применимо в какой-либо ситуации.
Для большинства случаев, у нас в сущности храниться текстовое наименование объекта, которое и вытаскивается. Я не говорю, что везде необходимо подключать таблицу истории — лишь для отчетов/выборок, ее использующих.
Про ссылку из сущности на карточку истории — да, можно сделать и так — я предложил свой вариант, который не встречал ранее.
Про ссылку из сущности на карточку истории — да, можно сделать и так — я предложил свой вариант, который не встречал ранее.
В 1с уже реализовано.Вообще как RAD для учетных систем — очень хорошая система (начиная с 8.1)
По работе общаюсь с банковским мейнфреймом на Teradata. Вся история хранится подобным образом. Никакого специального разбиения данных на таблицы нет, но все таблицы имеют по две дополнительные колонки — FromDate и ToDate. Максимальная дата во второй показывает активность записи. А так как Teradata легко переваривает громадные объемы данных, то такая избыточность для нее не помеха, тем более, что минимальная разность в истории обычно равна дню.
Ваш второй пример во-первых непонятный, а во-вторых неправильный.
1. Предыдущая и следующие даты относятся к работе в той же самой компании или любой? Если к той же самой, то как вы будете делать такой же запрос, только без условия на конкретную компанию. Если к любой, то это вообще работать не будет, если человек перевелся в другую компанию в пределах одного года.
2. Пример: (ДолжностьА, КомпанияА, 15/02/11-28/02/11), (ДолжностьБ, КомпанияА, 15/03/11-22/03/11). Ваш код не выдаст вообще ни одной записи на сегодняшнюю дату.
1. Предыдущая и следующие даты относятся к работе в той же самой компании или любой? Если к той же самой, то как вы будете делать такой же запрос, только без условия на конкретную компанию. Если к любой, то это вообще работать не будет, если человек перевелся в другую компанию в пределах одного года.
2. Пример: (ДолжностьА, КомпанияА, 15/02/11-28/02/11), (ДолжностьБ, КомпанияА, 15/03/11-22/03/11). Ваш код не выдаст вообще ни одной записи на сегодняшнюю дату.
На счет непонятности, да есть немного такое. Я рассказывал общий подход к организации регистров сведений, который мы используем, поэтому видимо из-за общности не нашлось нормального примера.
1) Вы совершено правы, совсем забыл упомянуть в статье, что в второй части «Следующая» и «Предыдущая» дата должна указывать на запись, относящуюся только к работнику одной компании, т.е. если человек перевелся в другую компанию, то «Следующая дата» остается в максимальной. Сейчас дополню.
2) Опять вы правы, там в запросе лишнее условие было. Сейчас поправлю.
Спасибо за внимательность!
1) Вы совершено правы, совсем забыл упомянуть в статье, что в второй части «Следующая» и «Предыдущая» дата должна указывать на запись, относящуюся только к работнику одной компании, т.е. если человек перевелся в другую компанию, то «Следующая дата» остается в максимальной. Сейчас дополню.
2) Опять вы правы, там в запросе лишнее условие было. Сейчас поправлю.
Спасибо за внимательность!
А разве для того, чтобы посчитать/вывести тех людей, кто поработал в компании с начала года недостаточно «р.ДатаУвольнения > НачалоГода»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ведение периодических сведений в информационных системах