Многоуровневая проблема продукта / запаса с NHibernate

Question

Я работаю над приложением ERP, где необходимо динамически поддерживать несколько запасов, т.е.каждому депо / филиалу нужна отдельная стоимость запаса для каждого продукта.Один из подходов - избегать использования статических столбцов таблицы - состоит в том, чтобы иметь отдельную таблицу Stock следующим образом:

[Product]
Code
...

[Branch]
Code
...

[Stock]
ProductCode
BranchCode
StockValue
...

Это фактически становится отношением "многие ко многим", разделенными таблицей Stock.Сразу же кажется ловушками в этом подходе, например:

• Если есть 5 филиалов (складов) и продуктовые линейки 50 тыс., То будет 5 * 50 тыс. Запаслиний.Является ли это чрезмерным?
• Каждый раз, когда добавляется Продукт, необходимо добавить 5 новых линий запаса - по одной на каждую ветвь.
• Каждый раз, когда добавляется филиал, необходимо добавить 50 000 новых строк запаса.быть добавленным.

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

Кто-нибудь работал с подобной концепцией в прошлом и, возможно, может иметь более эффективное решение?Или, если это кажется подходящим решением, то какой метод ассоциации NHibernate может быть наиболее эффективным?

Спасибо.

Answer 1

Я бы создал отдельную сущность - Warehouse и Stores - это общие названия - в качестве контейнера для склада. Затем создайте отношения «многие ко многим» между Отделением и Складами, с которых они могут получить доступ к Складу. Это дает вам возможность хранить запасы в филиале и другом месте (арендуемое пространство) или позволяет нескольким филиалам получать запасы из нескольких складов. Надежные системы ERP дополнительно классифицируют складские запасы, например, по полкам и позициям.

Если не каждый товар есть в каждом филиале, тогда я не вижу, что ваш список потенциальных ловушек действителен. Используя модель склада, Stock - это запись в таблице «многие ко многим», содержащая количество товаров на складе. Если запись не существует, то в этом месте ее нет.