Сеть "Красное и белое"
https://ru.wikipedia.org/wiki/Красное_и_Белое
16 байт преобразовали в 8?
Что будете делать с неминуемой неоднозначностью? Если ее нет сейчас, то она возникнет завтра-через неделю-через месяц.
База в 1С8 живет 7 лет и общим сканированием ключей bigint по всем документам и справочникам повторения нет (пока)
В каждом магазине (8500 магазинов) своя база - каждый день идет обмен
(товары централизованно вводятся) и коллизий не возникает, также есть стыковка со сторонними программами
А что будете делать, когда появится еще один источник данных, кроме 1с? Да хотя бы еще один экземпляр 1ски?
Вот у нас сделали отдельную базу 1С для хранения детальных чеков до товара
И внутренние разработчики ничего "умнее" не придумали как сделать регистр сведений с ключевыми полями НомерМагазина (varchar(5)) + КодТовара(varchar(5))+НомерЧека(varchar(18)) и отдельно регистр с шапкой чека
с ключевыми полями Период(Date) + НомерМагазина (varchar(5)) + НомерЧека(varchar(18))
Так загрузка этих данных занимает 50% от загрузки всех данных
Ну и изменение ключа повлечет за собой слом всех сохраненных пользователями эксельных отчетов.
Ну насколько я понял - слетят фильтры - когда в отчете отфильтровано по определенному товару и магазину - это не страшно ....
Таких отчетов единицы - пользуются OLAP пока 30 аналитиков -- т.е. проект пока в этапе опытно-промышленной эксплуатации (начали интенсивно с 1 марта пользоваться)
И мои аналитики занимаются в корне неправильным формированием отчетов
1.Формируют "простыню" (без кодов товара) по всем товарам по датам без всякой фильтрации с выводом в столбцах всех атрибутов товара
2.Переводят эту таблицу в POWER BI и там уже делают DashBoard
-- либо свою сводную делают
3.Стыковку с пока недостающими данными из 1С делают по наименованию товара через ВПР() .....
С переходом на 2019 убираю лишние атрибуты . Пример дублировал наименование отдельным атрибутом (был случай в предыдущих местах когда пользователям было нужно и краткое наименование и полное) - здесь это избыточное поле тормозящее расчеты
В любом случае придется моим аналитикам отчеты переделывать
Должно быть dwh с независимыми суррогатными ключами.
Внутрь OLAP особо никогда не залезал, но проанализировал сейчас структуру и понятно что можно в 2 раза утрамбовать с переходом на суррогатные ключи
