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 часто встречались.
P.S.
И да, я помню, как в Зик-1 итоги в справочник складывались.

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

(14) Для программы какая разница 24 или 366 ?

(25) 366 даже удобней
По идее можно на каждый новый день новую табличку создавать
А затем удалять когда данные в архив переходят

Решение с 24 табличками (по 2 на каждый месяц) выглядит странным
Каждые новые текущие месяцы/кварталы будут явно самыми напряжными, больше всего движений/обращений
Затем постепенно все меньше движений, затем всплеск перед концом года
И когда год закрыт совсем нет почти

(27) Это же СДЭК, а не бухня с кварталами/закрытиями периода. Навряд ли там наблюдается сезонность. Каждый месяц примерно одно и то же.

(28) Это Б2Б с клиентами - контрагентами юриками
И вот когда они год закрывают/подбивают и начинается вся движуха
А в течении года на расслабоне

(28) >Каждый месяц примерно одно и то же.

Так может вынести в отдельные таблички текущий день, прошлый день, текущий и прошлый месяц и "все остальное"?
Этого достаточно?

(30)+ Иначе получается что в первых числах месяца все летает
А под конец месяца у всех тормоза ))

(29) Только движуха эта - не добавление/изменение данных, а чтение. А обрабатывать переходящие данные легче в 12 таблицах, нежели в 366.

(32) Они выставляют счета раз в месяц?
Тогда хватит одного незакрытого/закрытого месяца и целиком года, куда все переходит
Зачем 12 таблиц по числу месяцев в году?

(0) фигассе

(32) Если самое напряжное чтение - логичней как раз по дням хранить а не по месяцам
Ибо отчет может быть не за целый месяца и лезем в две большие таблицы
Вместо кучи мелких по числу дней

А еще можно не по периодам а по контрагентам делить ))
Тогда не надо заморачиваться некими календарными табличками
Тупо у каждого клиента-контрагента свой набор таблиц полный

(33)
Компромисс между объемом одной таблицы и накладными расходами на партионирование.