Как стать автором
Обновить
25
0
Илья Киров @kirovilya

Пользователь

Отправить сообщение
Ну вот, что и требовалось доказать! Подобная избыточность полезна для выборок и не сильно нагружает обработку.
Как показать «последнюю» должность и «последнего» руководителя работника без поздапроса с LIMIT?
Я пытался это сделать в первой части статьи и пришел к выводу, что добавив одно поле этого можно избежать!
Я не говорю, что нельзя сделать без group by и limit, я говорю, что есть способ быстрее!
так вот, выбор последней записи и будет являться подзапросом.
при указанном в статье подходе подзапросов не будет.
Например, если в контексте статьи потребуется вывести список Работников и их непосредственных начальников. В Работниках уже будет group by, в Начальниках тоже придется его использовать (т.к. начальник может меняться у работника), итоговый запрос я даже боюсь представить как написать без подзапроса.
думаю, нет :)
особенно тогда, когда выборка не ограничивается только 2-мя объектами — чем их больше, тем сложнее будет использовать group by (вплоть до «невозможно»)
Для большинства случаев, у нас в сущности храниться текстовое наименование объекта, которое и вытаскивается. Я не говорю, что везде необходимо подключать таблицу истории — лишь для отчетов/выборок, ее использующих.

Про ссылку из сущности на карточку истории — да, можно сделать и так — я предложил свой вариант, который не встречал ранее.
согласен, но не все пишут на 1с
вроде понятно написал о чем
я же предупредил «включаем фантазию» :)
Если и дальше проводить аналогии с регистром сведений, то здесь и описано как они могли бы быть устроены внутри для оптимизации запросов.
В случае с «регистром сведений» происходит дублирование информации, а здесь попытался избавиться от этого.
Список перемещений — аналог «Работника», но с ним возникают указанные в статье проблемы.

Информация

В рейтинге
Не участвует
Откуда
Казань, Татарстан, Россия
Дата рождения
Зарегистрирован
Активность