Как стать автором
Обновить
7
6.4
Калимулин Михаил Игоревич @exwill

AI developer

Отправить сообщение

Смотрите. Есть виртуальная таблица. Называется "Срез последних". В соответствии с названием, мы ожидаем, что она вернет последние записи. И это, и только это, надо считать правильной работой. Однако, оказывается, что если вы укажете в запросе неполный набор измерений, вы получите в результате не последние записи. Вы не получите сообщение об ошибке. Вам не скажут: "Ей, парень, это так не работает! Нужен полный набор измерений". Вам просто выдается неправильный результат. Документация написана так, что можно понять, как угодно. Лично меня это задевает еще и потому, что я прекрасно представляю, как это устроено внутри. Вы все равно так или иначе транслируете исходный запрос в SQL запрос. И вы все равно формируете список полей для группировки. Сделать так, чтобы в список для группировки попадало только то, что есть в исходном запросе - это вопрос одного "если". Проще может быть только замена значения константы. И да, меня злит то, что разработчики нашли время на никому не нужный срез первых и не нашли время на это "если". И еще, я, так же, как вы, пытаюсь понять - что движет теми, кто пытается любыми способами защитить разработчиков, даже в такой очевидной ситуации

Что вы называете домыслами? Конкретно?

Что я допускаю, что разработчики не были знакомы с теорией баз данных?

Или что они как дети малые бросили все как есть, вместо того чтобы доделать?

Первое, согласен, домысел. А вот второе - это факт данный нам в ощущениях.

У вас странная логика. Если операция 237065122+486369458 встречается довольно редко (а ведь так оно и есть), то нет ничего страшного в том, что результат не 723434580, а 876222544.

Во-первых, реальный кейс, который побудил меня написать статью, был на типовой конфигурации. А менять типовую конфигурацию ради одного отчета неразумно.

Во-вторых, если у вас два измерения, тогда вам надо будет создать три регистра, чтобы покрыть все возможные случаи. Если три измерения, тогда регистров будет шесть. А для четырех измерений потребуется уже 13 регистров. Вы уверены, что это правильный путь, вместо того чтобы убрать всего лишь одно (2,3) лишнее поле из группировки?

Ничего не делать. Бери любую, любая годится

Платформа и будет отвечать. Добавляешь к дате четыре байта и инкрементируешь

В статье подробно об этом написал.

В идеале у вас должна быть обеспечена уникальность значений типа дата хотя бы в рамках информационной базы. Это соответствует тому, что мы имеем в реальном мире.

Если уникальность дат не обеспечена, тогда запрос будет возвращать несколько строк. Но это должны быть последние цены, а не как сейчас - тоже несколько строк, но не последние, а все подряд

Вы сами себя прочтите медленно и внимательно.

С документацией у 1С все в порядке. Там про этот случай ничего не написано (!) Ну ха-ха же, нет?

Из нас двоих вы гораздо более "упертый". Я не делаю ОТБОР. В диалоге два раза сказал об этом. Давайте здесь еще раз повторю. Я не делаю ОТБОР.

Что касается индексов и производительности. Ну допустим, разработчики все предусмотрели и сделали быструю операцию для полного набора измерений. Для неполного набора быстрая операция невозможна. Ну и? Дальше-то что? Что с этим делать? Запрещать операцию? Делать хоть и медленную, но правильную? Ответ разработчиков 1С - а пусть будет неправильно, зато быстро. Это по-вашему разумно?

Вы полагаете, что тех, кого что-то не устраивает в 1С, доли процентов?

Нет. У меня претензия именно к платформе. Я хочу, чтобы если таблицу назвали срезом последних, мне последние записи и выдавали

Так было бы, если бы 1С сделала срез правильно. Но сейчас запрос вернет и 19 и 20 и 21 год как последние записи. В этом и проблема

Ну подумайте сами. Смысл писать? Кто-то все равно будет введен в заблуждение, думая что механизм работает, как в РН. Надо не просто документацию исправлять, надо переделывать, вызывать сообщение об ошибке при выборе неполного набора измерений. А это, в свою очередь порождает вопрос: а не проще ли группировать правильно?

Не совсем так. Как они должны исправить документацию? Не делайте запрос по неполному набору измерений, потому что получите бессмысленный набор данных? И это при том, что переделать на правильный срез займет примерно столько же времени, что и переписывание документации

И часто вы таким образом меняете типовые конфигурации ради одного отчета?

Не могли бы пояснить: что именно я, по-вашему, не понимаю?

Конечно же я все внимательно слушаю. Более того, я подробно отвечаю на объяснения и показываю, чем они меня не устраивают. Иначе бы та ветка не была бы такой длинной.

Пожалуйста. Вот вам другой пример. Заказчик говорит иногда мне будут нужны последние документы продажи по контрагенту, иногда последние документы продажи по складу, а иногда последние документы продажи по сочетанию склад+контрагент. И что в этом случае следует делать? Создавать три регистра?

Получение последней цены товара из регистра сведений, где есть два измерения - это реальный кейс. Для наглядности. Вот исходные данные:

01.01.1990, ООО Ромашка, Ложка, 3 руб.

01.01.2021, ООО Василек, Ложка, 120 руб.

01.02.2021, ООО Василек, Ложка, 122 руб.

Так вот. Я хочу в результате запроса к срезу ПОСЛЕДНИХ получить:

01.02.2021, Ложка, 122 руб.

И я не хочу получать:

01.01.1990, Ложка, 3 руб.

01.02.2021, Ложка, 122 руб.

Потому что запись от 1990 года не относится к категории ПОСЛЕДНИХ. Это - просто ненужное старье

Там нет никакой логики, а есть просто небрежность.

Я хочу получать последние записи. И я не хочу получать бессмыслицу в результате запроса.

Но и обратное нигде не сказано. Вот дословная цитата из документации:

"Предназначена для получения наиболее поздних записей регистра сведений на указанную дату (включительно). Включает только активные записи. По каждой комбинации измерений будет найдена наиболее поздняя запись, но не более поздняя, чем указанная дата."

Информация

В рейтинге
879-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность