Есть ли смысл разделять большое количество данных по таблицам?

Например разделить остатки магазинов по регионам? (Сеть очень большая поэтому записей тоже очень много) В МСК 20 млн

В питере чуть меньше, в регионах больше

Эскалацию словишь - задумаешься. Один из примеров.

Распределенную сеть инфобаз не предлагать?

(2) Можно пример?

(2) Это не значит что для каждого города своя таблица
просто хотяб Москву и питер вынести

(4) Попробуйте сформулировать свою мысль так, чтобы её можно было прочитать без мата.

(8) Это только для веб сервиса. На уровне запроса указывается конкретный магазин, далее идет определение таблицы и запрос

20 млн - это не много )

Хотя это остатки, движений думаю поболе

Мне кажется субд практически пофигу сколько в таблице строк. Главное не больше максимального предела. Но тебе до него несколько десятков лет еще таблицу эту наполнять.  Скорость выборки практически не изменится. Главное правильные индексы.

план запроса или хотя бы сам запрос в студию

Короче в целом вопрос такой:
Сильно ли падает производительность
20 млн записей
60
100

(14) Смотря что ты с ними делаешь.

(13)
Все очень просто
StoreId
GoodsId
Where
StoreId = x

Просто запросы и запись с отбором по магазину

индексировано по 2ум полям

Если есть индекс по StoreId, то разделение на скорость никак не повлияет.

А запись с отбором по магазину

(17) Структуру регистра (картинкой) и запрос в студию

(19)  было бы очень круто если был бы какой-то источник факта)

(5) https://its.1c.ru/db/v836doc#bookmark:dev:TI000000537

(21)  картинку скинуть не могу, сейчас не за компом
Измереня
Store
Goods

Ресурсы
Quantity
Price

Реквизиты
StoreId
GoodsId

И просто плоский селект без соединений

(24) Store и StoreId - это как и для чего? не проще в указать условием Store?

(24) Если при чтении и записи всегда накладывается отбор на измерение Store, то блокировок лишних не будет и делить смысла нет.

(13) Поддерживаю. В смысле о важности плана запроса - ссылка (много буковок в статье, но ничего лишнего, всё по делу, доступно о сложном):

"Влияние оптимизатора запросов на производительность 1с"
http://www.gilev.ru/optimquery/

Я один задался вопросом - а сколько миллионов строк будет выбрано даже при отборе по одному магазину?

Магазинов же не миллионы , а максимум 1000

(29) Москва это 10 тыс~. Регионы 5-6 тыс~

(24) "просто плоский селект без соединений" // Ты точно отвечаешь на мой вопрос-запрос?

Хрена себе. Технопоинт перешёл на 1с?

(31)
Выбрать
*
Из Stocks как Stcs
Где
Stcs.Store = Store

Может я не правильно понимаю вопрос?

(32) Они давно на нем. Даже на кассах я помню был 1С.

В общем если подытожить:

Если писать с отбором по магазину блокировок не будет - логично, скорость записи тоже не меняется (check)

Если поля отбора индексированы, то время запроса не увеличивается вне зависимости от размера таблицы (1 таблица, без соединений) (check)

Все согласны?

(33) Ну раз в условиях запроса есть условие на первое (по порядку) измерение регистра, тогда не все так плохо. Нет смысла разделять таблицу (с точки зрения какой-то там производительности), если конечно ты не хочешь положить таблицу для Мск / Спб на быстрые диски, например.
https://its.1c.ru/db/v8std#content:-2145782995:hdoc

Но че-то раньше ты писал в (16), что условие не на измерение, а на реквизит регистра

разве в плане запроса (33) "выбрать все" не будет скана?

(38) Они тоже индексированы

(39) мне было лень писать все поля, звездочку я не использую, с телефона сложно писать

(35) ну время записи с индексами немного возрастает
(39) с чего бы

У меня в одной из табличек 1.2 млрд записей - все норм выбирается, если по индексу разумеется

(40) Так реквизит регистра не используется в таблице остатков. Ты из какой таблицы выбираешь записи?

(44) http://shot.qip.ru/00V0at-1ZCpdk7i4/
Вот регистр

пример регистра*

(45) Ну это ты в (24) написал, Я верю. Ты текст запроса не показал

Если запрос к основной таблице с условием по реквизиту, то почему не заменить его запросом к таблице остатков с условием по измерению? Накуя у тебя в реквизитах регистра реквизиты объектов БД, ссылки на которые сидят в измерениях?

(48) Думал так будет лучше, чтоб не обращаться через точку, типа исключить левое соединение со справочником.

(48) Я неправильно думаю?)

(49) Зачем левое соединение? Формируй список ссылок и условие на измерение В

(32) Но как, Холмс?

(50) Не знаю как ты думаешь :) Но, если запрос к основной таблице по неиндексированному реквизиту - то Clustered Index Scan, иначе - Clustered Index Seek (+Nested Loops). Две большие разницы.

А если запрос к виртуальным таблицам остатков/оборотов - то там нет реквизитов (только измерения и ресурсы) и нет смысла "в дублировании" измерений в реквизитах.

(53) Виртуальных таблиц не будет, плоский, индексированный по всем полям, регистр сведений

(53) Nested Loops при кластерном индексе - лишнее.

(54) Ну тогда учитывай, что реквизиты перед измерениями в индексе идут. В таблицах БД позырь, в каком порядке твои реквизиты идут в платформенных индексах

(55) Эээ... может быть и не прав, но там ДВА индекса в запросе участвуют.

(54) Остатки в регистре сведений? Эээ... без комментариев :)

(58) Так это пади у него срез регистра накопления регламентом формируется для выгрузки на сайт и помещается в этот отдельный регистр сведений, и сайт спокойно забирает

(59) Ах, да, sorry, забыл. Замечание снимается :)

+(56) "Индексы таблиц базы данных"
https://its.1c.ru/db/metod8dev#content:1590:hdoc:spr

(39) "Вы не понимаете о чем пишите"(с)

Подытожу: Разносить ничего не надо по таблицам(если не используется какой-то хитрый замысел), нужно попадать в индексы и использовать максимальные отборы, следить что бы не было эскалации (вроде 100к записей для ms sql)