Процитировано сообщение: Шорин Дмитрий от 17.10.2011 :: 19:43:27:
В общем пока не вижу архитектурных проблем, а только архитектурно верные решения Станислава, немного нестандартные и непривычные, но верные.
Если вы не согласны, то опишите пожалуйста конкретные причины, почему вы считаете использование общего справочника менее производительным, чем отдельных. Кроме того, что вы считаете это не удобным и не логичным.
Дмитрий, особо спорить не хочется т.к. нету такой цели.
Но как WMS-ник и одновременно 1С-ник готов пообщаться на интересную для меня тему, тем более что на форуме практически нулевая активность в области WMS.
Итак по полочкам:
1. Вы очень увлеклись цифрами, но нужно вначале задаться вопросом - удобно ли пользователю в справочнике Номенклатуры видеть как товары, которые он хранит и обрабатывает на складе, так и транспортные единицы, которые являются всего лишь контейнером для тех же самых товаров. Вопрос не в количестве регистров остатков (об этом речь пойдет в следующей главе), а совмещения в одном справочнике двух
совершенно различных элементов.
Мне даже затруднительно объяснять такие вещи т.к. это вроде настолько понятно, что не ясно почему это не понятно другим. Выглядит как в детской рекламе "а давайте зашоколадим молоко - дадим корове шоколад и она нам даст шоколадное молоко"
Со скрипом сердца я еще понимаю задумку совместить в одном справочнике Ячейки и ТЕ т.к. они имеют схожие характеристики (только одни "стационарные" контейнеры, а другие "мобильные" контейнеры), но Товары и ТЕ - совершенно не те объекты, которые нужно совмещать в единой таблице. С таким подходом можно было бы объединить что угодно, например, "Единицы хранения" и "Качество"
Почему нельзя было сделать двумя раздельными справочниками - отдельно Номенклатура и отдельно Транспортные единицы?
Во всех системах (Exceed, PSI, Manhattan и т.п.) это сделано именно подобным образом. И в любой форме где нужно выбрать товар не нужно проверять, чтобы пользователь случайно не выбрал бы ТЕ или груз. И наоборот, если нужно ввести ТЕ, то никто и не будет предполагать, что случайно могут ввести товар...
Эти два объекта кроме того что имеют совершенно разные параметры, имеют и разную тенденцию - Номенклатура примерно стабильна в размерах, ТЕ постоянно разрастаются.
2. Опыт работы в самой фирме 1С наложил некую ответственность за каждую запятую в коде, поэтому как бы меня сейчас коллеги по работе не призывали не обращать внимание на детали, я постоянно всех заставляю писать везде оптимальный код, даже если потенциально проблемы не видны.
Любая таблица должна быть построена оптимальным образом так, чтобы система работала стабильно и быстро, в независимости от мощности сервера. Если одна и та же таблица в одном месте используется наполовину, а другая ее половина используется в другом месте, то можно сказать, что такая таблица создана не корректно. Разрастание таблицы за счет роста количества ТЕ будет отражаться на быстродействии получения данных по товару, даже если количество товара будет неизменно. Также с учетом того, что в 1С на справочнике нельзя создавать составные индексы, то любой отбор товара по какому-либо товарному реквизиту будет уже не оптимальным т.к. нам нужно будет наложить два условия - первое на нужный реквизит, второе - на то, что ТипНоменклатуры = Товар. Если в таблице и по тому и по другому полю много значений, то SQL отберет данные по одному полю с учетом индекса, а по второму - перебором.
При доработке такого справочника клиент будет дополнять его как нужными товарными реквизитами, так и реквизитами, свойственными только с ТЕ. Это приведет к разрастанию справочника, к большому числу операций записи/чтения данных на SQL для выборки результатов.
Из жизни: недавно клиент пожаловался, что одна форма открывается долго. Посмотрели запрос - нашли подсоединение таблицы по индексируемому реквизиту. Все правильно - индексы есть, а работает долго. Посмотрели размер справочника - 1 330 000 элементов. Перестроили запрос и опа - форма открывается моментально. Изначально была ошибка программиста и эта таблица вообще не нужна в запросе, но пока справочник был маленький никто не замечал такой ошибки.
Так что с любыми большими таблицами нужно быть начеку.
3. По поводу селективности индекса при построении таблица типа
"Ячейка, ТЕ, Номенклатура, Качество, Партия ..."
Не вижу в такой схеме ничего плохого т.к. используя регистры сведений мы можем построить нужные нам индексы к этой таблице:
а) Ячейка, ТЕ, Номенклатура ...
б) ТЕ, Ячейка, Номенклатура ...
в) Номенклатура, Ячейка, ТЕ ...
В итоге в зависимости от целей запроса система всегда подберет оптимальный индекс в соответствии с установленными отборами.
При запросе типа "на какой ТЕ стоит Товар1 в Ячейке1?" SQL даже не будет обращаться к данным, а выдаст результат используя только индекс.
4. При таком "странном" разделении остатков на две таблицы опять же видится не оптимальность.
Регистр усОстаткиТоваров хранит остатки товаров по 8 измерениям, 5 из которых тесно связаны с Номенклатурой. Когда у нас Номенклатура есть ТЕ, то эти 5 измерений просто ничего не содержат. Их значения хранятся уже в таблице усСоставТранспортнойЕдиницы. Т.е. вынужденное соединение двух этих таблиц всегда будет содержать пустые данные.
Постоянна связка двух таблиц (не только этих, а и другим - об этом позже), чтобы получить конечный результат, сильно отягощает систему, что видно по здоровым запросам. Такой подход неплохо еще работает когда мы четко знаем, что работаем с конкретной ТЕ, но когда нам нужно просто получить "все товары с определенными параметрами" мы вынуждены собирать данные из разных мест.
5. Поддерживается ли при такой реализации работа с вложенными ТЕ?
Не секрет, что на многих складах есть паллеты и коробки. Товар может храниться в номерных коробках, которые в свою очередь храниться на паллетах. Во многих WMS поддерживается вложенность ТЕ, но в версии 3.0 я такого не нашел, да и вряд ли будет возможно красиво при такой реализации справочника Номенклатуры.
6. Открою большую коммерческую тайну - в большинстве западных WMS то ли никогда не слышали об нормализации таблиц, то ли на своем горьком опыте пришли к тому, что лучше получать данные из одной таблицы остатков, чем собирать из разных. Поэтому многие таблицы совершенно не нормализованы и содержат множество дублирующих данных. Стоит призадуматься, почему именитые производители используют единые таблицы остатков, а не разбивают их по отдельным таблицам.
ОК, на этом пора остановиться - я описал проблему, вы детализировали почему так было сделано, я прокомментировал. Дабы не свалиться в техническую переписку (напомню, что форум не 1С-кий, а логистический) оставим заинтересованным лицам самостоятельно проанализировать текущий подход и сделать собственные выводы.
А завтра обсудим вторую главу "2. Оптимальность построения регистров остатков".
Еще не передумали?
Страниц: 
подскажите WMS на базе 1С (Прочитано 4273 раз)
