Процитировано сообщение: Рубанов Сергей от 17.10.2011 :: 17:27:43:Очень странное решение запихнуть в один справочник как товарные позиции, так и грузы с транспортными единицами. Больше я такого подхода нигде не видел. Если таблица SKU, то там описываются только товары.
Ну что же давайте обсудим. Вы объединили 2 проблемы в одну.
Для начала обсудим "проблему большого (потенциально бесконечного) справочника". И так предположим, что у нас в день приходит/отгружается 100 000 ТЕ или грузов * 365 дней * 10 лет = 365 000 000 записей. Но надо вспомнить, что справочник обладает кластерным индексом по ссылке, поиск элемента у нас всегда происходит либо по ссылке, либо по Наименованию (если ищем товар вводом по строке). Для кластерного индекса 365 000 000 записей не проблема (тестировал на MS SQL поиск по ссылке в таблице документов: поиск в таблице с 200 000 000 записями стал на 35% дольше, чем в 100 000 - то есть разница всего в 1.35), для поиска по наименованию, индекс по Наименование+Ссылка будет обладать огромной селективностью, тем самым мы быстро выделим сравнительно небольшой объем данных, который является товаром, поиск же ТЕ или грузов по наименованию не идет вообще никогда.
Проблема "много регистров в которых хранятся остатки" потому в запросе отбора 500 строк, для начала, скажу что строк в запросе 270 (релиз 3.1.3.5, но данный запрос начиная с 3.0.7.2 только немного подрос - добавилось еще несколько опциональных условий), при этом запрос поделен на 4 пакета, в каждом из которых выполняется сравнительно несложный запрос, главное преимущество, любой из подзапрос обладает подходящим индексом. Рассмотрим на примерах почему мы не храним остатки в одной таблице:
У нас возможно хранение товара в ячейке и на ТЕ и просто (навалом). Как реализовать данное хранение в одной таблице (пишу только измерения):
Ячейка, ТЕ, Номенклатура, Качество, Партия, СрокГодности, СерийныйНомер.
Индекс, в котором на первом месте стоит измерение ТЕ, нам будет нужен достаточно часто, при этом данное измерение будет полупустым (в половине записей не будет информации) Такой индекс будет обладать очень плохой селективностью.
Решение же Станислава в следующем:
Сделать два регистра: Остатки в ячейке:
Ячейка, ТЕ/Номенклатура, Качество, Партия, СрокГодности, СерийныйНомер
И Остатки в ТЕ:
ТЕ, Номенклатура, Качество, Партия, СрокГодности, СерийныйНомер
Оба регистра не имеют полупустых измерений, если имеют, то эти измерения стоят в конце индексов и уже практически не влияют на селективность.
В чем же минус такого решения? он понятен - первое - надо хранить ТЕ и Номенклатуру в одном месте (но если не учитывать некоторых проблем поиска по подстроке, как я уже писал, это врятли проблема) и второе - 2 регистра, сложнее запрос, но при этом есть несомненный плюс - 2 регистра обладают подходящими индексами, соединение таких таблиц произойдет быстро - любая СУБД запросто выберет правильный и оптимальный план запроса. При условии существования неселективного индекса, гарантировать такое поведение невозможно. Скажу больше - встречал ситуации когда MS SQL 2005 начинал искать по менее селективному индексу, чем следовало бы. Использовать хинты мы к сожалению не можем
Вопрос селективности индексов стал причиной, по которой начиная с 3-его или 4-ого релиза произошло разделения регистра Остатков товаров на 3 регистра - Остатки, Остатки на отгрузке, Остатки на приемке. Иначе мы бы имели не селективные индексы по заказу на отгрузку, и по документу приемка.
В общем пока не вижу архитектурных проблем, а только архитектурно верные решения Станислава, немного нестандартные и непривычные, но верные.
Если вы не согласны, то опишите пожалуйста конкретные причины, почему вы считаете использование общего справочника менее производительным, чем отдельных. Кроме того, что вы считаете это не удобным и не логичным. Подумаю, о том чтобы в следующем релизе
визуально разделить эти справочники (ранее не думал, что это вызывает много проблем).
Страниц: 1 
подскажите WMS на базе 1С (Прочитано 4272 раз)
