https://habr.com/ru/companies/cdek_blog/articles/1074562/
Пока читаю, но вот что удивило:
"Финансовые события и расценки — это первичные данные биллинга. Их очень много. Их нельзя терять. Мы являемся мастер‑системой этих данных. Поэтому хранить их должны максимально надёжно и экономно.

Храним в независимых регистрах сведений. Реквизитный состав этих регистров сведений имеет максимально примитивные типы, а сами регистры имеют минимальную индексную нагрузку.

Первичные данные партиционируем. Причём не средствами СУБД, а на уровне метаданных 1С.

Для каждого месяца у нас есть отдельный регистр для финансовых событий и для расценок. Итого — 24 регистра на год."

Как вам такой подход?

(0) В правильных системах можно было бы делать средствами СУБД. Но тут же 1С. Плюс ковыряние в СУБД всегда на свой страх и риск.

Так что подход понятен.

Не очень верится что у них первичка биллинга именно в 1С, но если б делал, то делал как-то в подобном варианте. Чем больше  нагрузка на регистр на запись, тем логичнее разнести эту нагрузку на разные регистры. Задача легко распараллеливается.  Для меня странно что всего 24 регистра.

Одно я не понял. Почему в СДЭК 1С сделали мастер системой для биллинга. Это какой-то кривой подход. Видимо там 1Сники в свое время захватили власть.

(3) Предполагаю что это после того, как их самаписку, несколько раз взломали.

(0) клоуны, поржал

Тупо сэкономили.
На 1С оказалось дешевле и спецы есть...

(5) У них там компромисс между имеющимися ресурсами и корректным (с технической точки зрения) выбором инструментов для решения задачи. Как система, смотрится не так уж и плохо.

(0) а они восстановились после того как месяц восстанавливали инфраструктуру?

По реализации:
Биллинг складских операций-1 регистр, 1 заполнялка табличной части реализации

Биллинг инжинириговой компании по заготовке леса(прокладка дорог, заготовка леса, транспортировка до зоны приемки, включая сплотирование)

1 регистр, +генератор пбз, для себеса


Ап регистр накопления ессно
(5) поддержу

Кривое архитектурное решение
Я бы сделал 366 * N регистров на каждый день в году и вид операции
Затем данные из этих регистров переносил в более полные сводные

(9) 👍 аналогично.

(0) Много разумных решений.И самое главное,есть что посмотреть на гитхабе.А критикам и выложить нечего.

(3) потому что 1С отлично подходит роль мусорки. не под фронт же ее использовать в самом деле

(12) Конечно,конечно.Java там не "шмогла" ибо нерусь, дорогая.

(9)
Еще более кривое решение.В СДЭК стояли на земле, и видели реальные объемы данных.Так что они пошли на компромисс между сложностью и скоростью.Вы же предлагаете систему космического масштаба...

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

(0) Не вижу ничего криминального. Самолюбы, которые тащат всё во внешние базы - просто не умеют готовить РС.

p.s. Скорее всего, под СДЭК 1С запилило механизм расширенной модификации РС, а потом и РН до кучи. Плохо чтоли, хорошо!

«Владислав был очень могущественным, он мог превратиться в любое животное. Вот только у него не всегда получались лица».

(16) 1С уже умеет программно в регзадании CREATE TABLE?

Думаю, имеет право на жизнь. Но сложно получилось, по меркам 1С.

(18) Докладчик написал, что раз в год создают.

(18) С момента появления Внешних источников данных.
Или вопрос про создание регистра в метаданных конфигурации?

(21) Про создание новых регистров и прочих объектов метаданных в СУБД
При необходимости, хотя и редкой

Заходишь в типовой 1С УХ, смотришь на синтетический регистр показателей, затем на пронумерованные аналитические регистры показателей.
Консолидация, конечно, древний продукт уже, но в 90-х такие решения для dbf часто встречались.

(22) Если есть pipeline, то запихнуть новые "типовые" объекты метаданных в GIT не большая проблема