Предположим, есть регистр накопления, куда нужно воткнуть десять полей, не обязательных к заполнению.
Предположим, что предполагаемое количество комбинаций этих полей очень большое, например 1 000 000 000.
Что лучше с точки зрения формирования запросов к этому регистру с отбором по этим полям, дополнительная аналитика в одном поле типа справочник или десять полей в регистре?
Дополнительная аналитика предполагает, что поле одно, а уж из него через точку можно получать остальные реквизиты.
Десять отдельных полей предполагает просто 10 полей в регистре.

если уточнение модели сущности - добавить поле
если сопутствующий бизнес процесс - таблица

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

(1) Теоретические изыскания. Интересно только с точки зрения скорости.

(0) С точки зрения скорости - это значит поиск по индексу. Я думаю искать по одному полю индекса, в котором лежит ключ аналитики легче, чем по 10 полям, тем более, что раз они не обязательны к заполнению, то и по индексу их искать не всегда получится

Голосую

(2)
не верный подход.

на первом этапе оптимизацией не занимаются.

почитайте по книги по объектному проектированию.

опять же Вы путаете оперативный учет и аналитический.

+ забываете главное правило эксплуатации субд - подальше положишь поближе возьмешь.

РАУЗ доказал свою состоятельность уже, Измерение - это реквизит справочника, а в справочнике уже твои 10 полей.
Опять же зависит от того, в каком разрезе надо хранить в регистре, надо ли итоги по отдельным "полям" и прочая ересь

(5) Пятница. Теоретические изыскания. Вопрос только про скорость.
Причем здесь проекты, ОУ, АУ и прочая хрень? :))

(6) По отдельным полям, допустим, нужно.

(3) А если поля будут обязательными?

(8) что нужно? Итоги хранить? тогда отдельными измерениями. Или придётся самому высчитывать, вместо платформы

(9) при любом раскладе вопрос скорости сводится к тому, будет использован индекс при выполнении запроса или нет

С точки зрения скорости. 1 справочник и 1 регистр сведений для индекса

(10) Почему придется? Можно через отбор аналитик в списке делать. Разве нет?
Большой список может получиться, правда :))

Хм. Если говорим про регистр накоплений, то я вижу это так.
1. В остатках измерения необязательные для заполнения - это ересь.
2. Значит речь может идти только про обороты.
3. По оборотам я бы смотрел еще сопутствующие вопросы (доработка типовой или самописка - цена доработок и дальнейшей поддержки, возможное использование в отдельных запросах от основных данных, каким образом предполагается искать - возможные отборы).
3. Если рассматривать сферическую скорость запроса только к этим данным, то будет быстрее отдельные поля. Через точку - это всегда левое (либо внутренне средствами запроса), а так - наложил нужные тебе условия.

(12) А как же быть, например, с запросом "А сколько у нас остаток по аналитике1 = Х?" без уточнения остальных 9 аналитик? :))

(7)
никаких теоретических изысканий, кроме отсыла почитать

(6)    

по справочнику не сможете построить эффективного индекса
для отбора .

  
больше подойдет РС с измерениями реквизитами для кластерного индекса и ссылка индексированная.

(3) Однако чтобы найти эту запись придется таки найти комбинацию всех заданных параметров. Получается лишнее соединение. Делая запрос, мы же не будем ставить условие на ссылку служебного спр-ка? Ибо не знаем...
В плане живучести, простоте переделки и универсальности я за аналитику.
Помнится семерка загибалась при большом кол-ве измерений (особенно на ДБФ). Очень тяжко итоги ворочать.

(14) Тоже склоняюсь к тому, что по отдельным полям будет быстрее, но смущает только то, что при необязательном заполнении поля индекс на нем закончится.

(15) Если нужен остаток по аналитике, значит это обязательные поля для заполнения. И будет ли закрываться приход/расход внутри одной аналитики? Или в результате регистр остатков не закроется, т.к. приход был по одной аналитике, а расход по другой

(15)

это задача аналитического контура

решаются избыточными (экстенсивными) путями
например созданием доп индексов
в таких задачах соотношение и объемов памяти для индексов и данных может быть 1 к 30

для опер учета желательно 1:1


подойдут объекты метаданных агрегаты

(19) >>Если нужен остаток по аналитике, значит это обязательные поля для заполнения.
С чего бы вдруг?

Мдаа

(21) Рома, дай задание сотворить чудо своему сотруднику и займись уже своим делом.

(23) Это не реальная задача, так, разговор поддержать, потрындеть в пятницу :))

(24) реальная, просто постановка кривая. Так для раздумья тебе, почему думаешь в РНОстатки реквизиты регистра нет?

(25) LOL
Еще раз, это не реальная задача, поверь, мне виднее, какие задачи у меня реальные, а какие нет :))
Реквизитов нет, думаю, потому, что они имеют смысл только для детальных записей и агрегаты по ним не считаются.

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

(27) он еще какие-то остатки хочет ))

+(27) но это, как правильно подметил МихаилМ, можно будет сказать только в конкретном случае на основании статистики того, какие данные и как чаще всего выбираются. Чисто теоретически в сферическом вакууме более точного ответа, чем (27) хрен дашь

В общем, я за отдельные реквизиты :))

(30) такие вопросы голосованием и предпочтениями не решаются

(31) Ну да, согласен. Как и клятвенными заверениями и фразами типа (29) :))

Я считаю, что отдельные реквизиты лучше потому, что так лучше будет работать индекс, без всяких точек и отборов в списке.

(33) >лучше будет работать индекс
признайся, ты не знаешь ни чего про индексы в целом и про то, как с ними обращается 1С

(0) С точки зрения SQL-сервера, если количество вариантов большое, то быстрее будет измерения регистра, т.к. будет обычный поиск по индексу.

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

(34) Оставь свои догадки при себе :))

(35) Ну я примерно так же рассуждаю. Но смущает (18).

Постановка задачи такова, что может быть верным любой ответ.
Берём крайние ситуации:
1. Отбор по 10 полям, конечно, аналитика, ключ единственный.
2. Отбор по 1 полю, измерения, проиндексированные для надёжности.
3. Комбинации (почти) не повторяются, справочник не имеет смысла.
А ещё есть промежуточный вариант: измерения и аналитика вместе.

(37) Так в регистрах же все измерения "NOT NULL" вроде?
Насколько я помню, для ссылки пишется пустойГУИД, поэтому индекс закончиться на нем не может.

(39) Да вроде как нет, попробовал только что.

+(40) А, пардон, ты вон про что.
Ну может быть, ХЗ.

Странно.
Набросал тестовую базу, два регистра, один с одной аналитикой и 10 реквизитами в аналитике, другой с 10 полями, сгенерил 10 лимонов записей, формирую по-всякому запросы, все 0 — 1 секунду.
Что за хня? Даже неинтересно :))

(42) По условию задачи - миллиард записей: будет интересней.

(43) Сейчас генерю 100 лимонов записей, но по ходу особого эффекта это не даст.
Даже странно.

(42) кэш ибо :)

(42) Куясе! Снеговик так быстро валит?
Какие запросы?
А если ближе к реальным?

(42) А разве больше должно быть? пофиг сколько там записей 1 тыс или 100 млн, попал в индекс - сразу получил данные, временная задержка для пользователя незаметна.
А дополнительные поля это удел нубов. Я за аналитику

(46) Ну хрен знает, смотри сам.
http://77.37.142.90/productivity/
На данный момент в базе по 100 миллионов записей в обоих регистрах накопления.

Первый замер производительности дал такие результаты:
Остаток по одному элементу: Аналитика 01
— Одна аналитика: 2 сек.
— Несколько полей: 3 сек.
Остаток по одному элементу: Аналитика 10
— Одна аналитика: 1 сек.
— Несколько полей: 0 сек.
Остаток по одной комбинации элементов: Аналитика 01 + ... + Аналитика 10
— Одна аналитика: 0 сек.
— Несколько полей: 0 сек.
Остаток с группировкой: Аналитика 01
— Одна аналитика: 0 сек.
— Несколько полей: 0 сек.
Остаток с группировкой: Аналитика 10
— Одна аналитика: 1 сек.
— Несколько полей: 1 сек.
Оборот по одному элементу: Аналитика 01
— Одна аналитика: 55 сек.
— Несколько полей: 391 сек.
Оборот по одному элементу: Аналитика 10
— Одна аналитика: 85 сек.
— Несколько полей: 289 сек.
Оборот по одной комбинации элементов: Аналитика 01 + ... + Аналитика 10
— Одна аналитика: 85 сек.
— Несколько полей: 313 сек.
Оборот с группировкой: Аналитика 01
— Одна аналитика: 106 сек.
— Несколько полей: 253 сек.
Оборот с группировкой: Аналитика 10
— Одна аналитика: 97 сек.
— Несколько полей: 260 сек.

Второй замер производительности дал такие результаты:
Остаток по одному элементу: Аналитика 01
— Одна аналитика: 1 сек.
— Несколько полей: 0 сек.
Остаток по одному элементу: Аналитика 10
— Одна аналитика: 0 сек.
— Несколько полей: 0 сек.
Остаток по одной комбинации элементов: Аналитика 01 + ... + Аналитика 10
— Одна аналитика: 0 сек.
— Несколько полей: 0 сек.
Остаток с группировкой: Аналитика 01
— Одна аналитика: 0 сек.
— Несколько полей: 0 сек.
Остаток с группировкой: Аналитика 10
— Одна аналитика: 1 сек.
— Несколько полей: 1 сек.
Оборот по одному элементу: Аналитика 01
— Одна аналитика: 101 сек.
— Несколько полей: 267 сек.
Оборот по одному элементу: Аналитика 10
— Одна аналитика: 86 сек.
— Несколько полей: 261 сек.
Оборот по одной комбинации элементов: Аналитика 01 + ... + Аналитика 10
— Одна аналитика: 86 сек.
— Несколько полей: 261 сек.
Оборот с группировкой: Аналитика 01
— Одна аналитика: 129 сек.
— Несколько полей: 260 сек.
Оборот с группировкой: Аналитика 10
— Одна аналитика: 120 сек.
— Несколько полей: 251 сек.

В общем, по ходу расклад такой.
Для остатков пофиг, для оборотов одна аналитика рулит :))

Забавно. Видимо в результате всех этих экспериментов скуль сожрал 11 гигов оперативы :))

Ну так что, господа, получается, что одна аналитика лучше, чем несколько полей? :))

Тест вообще ни о чем. Ибо кэш

(51) Какой кеш? Первый раз же запрос формировался.
Ну хочешь, буду формировать по любой аналитике, а не по первой попавшейся.
Что тебя убедит? :))

Что-бы еще такого в тест воткнуть. Что-то в голову ничего не приходит.

Хе, возникла забавная идея.
Для регистра остатков есть виртуальная таблица остатков.
Для регистра оборотов есть виртуальная таблица оборотов.
А вот если мне нужны и остатки и обороты (отчет оборотка, например), ну то есть читай регистр остатков, то обороты я буду считать без виртуальной таблицы, то есть по реальным записям.

Засада :))

Добавил еще пару регистров накопления, таких же, но оборотов, а не остатков.
Запустил генерацию записей в них, по 100 миллионов штук.
Скуль отожрал 13 гигов оперативы :))

(54) "Для регистра остатков есть виртуальная таблица остатков."
Вообще-то для такого регистра есть 3 виртуальных таблицы(остатки, обороты и остатки+обороты).

(55) 130 байт на пару записей, в одной из которых десяток ссылок, не так и много. Размер получившейся базы?

(56) Вообще-то нет.

(57) Размер отожраной оперативы.
База пока 300 гигов вместе с логом.
Без лога 64 гига.
Будет примерно 85 — 90 гигов.

(58) не понял, ты отрицаешь наличие таблицы ОстаткиИОбороты?

(60) Я отрицаю ее физическое наличие в базе.

(61)Вот ты о чем. Есть таблица со служебными итогами, которая используется при формировании виртуальных таблиц. Как ты определил что в ней только остатки?

(62) Да это как бы давно известно

(63) Не знал.
Ну вот тебе и идея для теста: сделай замеры по запросу к таблице ОстаткиИобороты при рассчитанных итогах и без них

(64) Что за фигня? Зачем?

(65) Чтобы проверить утверждение из (54):
"А вот если мне нужны и остатки и обороты (отчет оборотка, например), ну то есть читай регистр остатков, то обороты я буду считать без виртуальной таблицы, то есть по реальным записям. "

(66) Зачем его проверять, это и так понятно.
Тем более, что проверять это нужно с помощью ПолучитьСтруктуруБазыДанных().
А я вот решил пару регистров добавить :))

+(66) если утверждение верно, то замеры будут одинаковыми

(68) Так уж тогда лучше просто тупо по реальной таблице посчитать.

(69) ты меня окончательно запутал. Мы про работу платформы 1с при обращении к виртуальным таблицам говорим или про что-то другое?

(70) Да.

С использованием дублирующих данных в регистре сведений по аналогии РАУЗ вроде как все быстро и лаконично

(71) И ты утверждаешь, что
1. запрос к таблице ОстаткиИОбороты строится по одной только физической таблице записей
2.  наличие рассчитанных итогов не повлияет на время выполнения такого запроса

(73) Я утверждаю, что
1. Запрос к таблице ОстаткиИОбороты строится по двум таблицам, физической таблице записей и физической таблице итогов
2. Наличие рассчитанных итогов повлияет на время выполнения такого запроса

+(59) В итоге получилось: 90 гигов база, 400 гигов база вместе с логом :))

Повторные замеры с учетом новых регистров дали странные результаты :))

Первый замер:
Остаток по одному элементу: Аналитика 01
— Одна аналитика: 3 сек.
— Несколько полей: 3 сек.
Остаток по одному элементу: Аналитика 10
— Одна аналитика: 0 сек.
— Несколько полей: 0 сек.
Остаток по одной комбинации элементов: Аналитика 01 + ... + Аналитика 10
— Одна аналитика: 0 сек.
— Несколько полей: 0 сек.
Остаток с группировкой: Аналитика 01
— Одна аналитика: 0 сек.
— Несколько полей: 0 сек.
Остаток с группировкой: Аналитика 10
— Одна аналитика: 1 сек.
— Несколько полей: 1 сек.
Оборот по остаткам по одному элементу: Аналитика 01
— Одна аналитика: 145 сек.
— Несколько полей: 351 сек.
Оборот по остаткам по одному элементу: Аналитика 10
— Одна аналитика: 110 сек.
— Несколько полей: 247 сек.
Оборот по остаткам по одной комбинации элементов: Аналитика 01 + ... + Аналитика 10
— Одна аналитика: 86 сек.
— Несколько полей: 257 сек.
Оборот по остаткам с группировкой: Аналитика 01
— Одна аналитика: 103 сек.
— Несколько полей: 259 сек.
Оборот по остаткам с группировкой: Аналитика 10
— Одна аналитика: 103 сек.
— Несколько полей: 240 сек.
Оборот по оборотам по одному элементу: Аналитика 01
— Одна аналитика: 57 сек.
— Несколько полей: 231 сек.
Оборот по оборотам по одному элементу: Аналитика 10
— Одна аналитика: 3 сек.
— Несколько полей: 1 сек.
Оборот по оборотам по одной комбинации элементов: Аналитика 01 + ... + Аналитика 10
— Одна аналитика: 4 сек.
— Несколько полей: 1 сек.
Оборот по оборотам с группировкой: Аналитика 01
— Одна аналитика: 10 сек.
— Несколько полей: 5 сек.
Оборот по оборотам с группировкой: Аналитика 10
— Одна аналитика: 10 сек.
— Несколько полей: 10 сек.

Второй замер:
Остаток по одному элементу: Аналитика 01
— Одна аналитика: 0 сек.
— Несколько полей: 3 сек.
Остаток по одному элементу: Аналитика 10
— Одна аналитика: 0 сек.
— Несколько полей: 0 сек.
Остаток по одной комбинации элементов: Аналитика 01 + ... + Аналитика 10
— Одна аналитика: 0 сек.
— Несколько полей: 0 сек.
Остаток с группировкой: Аналитика 01
— Одна аналитика: 0 сек.
— Несколько полей: 0 сек.
Остаток с группировкой: Аналитика 10
— Одна аналитика: 1 сек.
— Несколько полей: 0 сек.
Оборот по остаткам по одному элементу: Аналитика 01
— Одна аналитика: 144 сек.
— Несколько полей: 374 сек.
Оборот по остаткам по одному элементу: Аналитика 10
— Одна аналитика: 114 сек.
— Несколько полей: 246 сек.
Оборот по остаткам по одной комбинации элементов: Аналитика 01 + ... + Аналитика 10
— Одна аналитика: 85 сек.
— Несколько полей: 251 сек.
Оборот по остаткам с группировкой: Аналитика 01
— Одна аналитика: 99 сек.
— Несколько полей: 246 сек.
Оборот по остаткам с группировкой: Аналитика 10
— Одна аналитика: 120 сек.
— Несколько полей: 256 сек.
Оборот по оборотам по одному элементу: Аналитика 01
— Одна аналитика: 45 сек.
— Несколько полей: 205 сек.
Оборот по оборотам по одному элементу: Аналитика 10
— Одна аналитика: 4 сек.
— Несколько полей: 1 сек.
Оборот по оборотам по одной комбинации элементов: Аналитика 01 + ... + Аналитика 10
— Одна аналитика: 3 сек.
— Несколько полей: 2 сек.
Оборот по оборотам с группировкой: Аналитика 01
— Одна аналитика: 10 сек.
— Несколько полей: 4 сек.
Оборот по оборотам с группировкой: Аналитика 10
— Одна аналитика: 10 сек.
— Несколько полей: 10 сек.

И вот тут выяснилась забавная картина.
Везде лучше одна аналитика, а вот "Оборот по оборотам по одному элементу: Аналитика 10" и "Оборот по оборотам по одной комбинации элементов: Аналитика 01 + ... + Аналитика 10", то есть по-русски допустим "Продажи по одному товару" и "Продажи по одному товару по заданному складу по заданной организации и т. д." быстрее формируются по нескольким полям :))

а мне

(77) Настоящий одинесник. Продолжай в том же духе :))

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

(79) В базе по 100 лимонов записей в каждом регистре.
Количество аналитики в разных справочниках разное.
Структура требуемых отчетов разная.
Индексы вроде как строятся всегда по одним и тем же правилам.
Что еще надо-то?