Дизайн базы данных инвентаризации

Я видел оба подхода в своей нынешней компании и определенно склоняюсь к первому (расчет итогов на основе операций с акциями).

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

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

• Справочник по модели данных, Vol. 1. Библиотека универсальных моделей данных для всех предприятий
• Справочник по модели данных, Vol. 2. Библиотека моделей данных для конкретных отраслей
• Справочник по моделям данных: универсальные шаблоны для моделирования данных

У меня есть Том 1 и Том 2, и они были очень полезны в прошлом.

Это зависит от того, системы инвентаризации — это гораздо больше, чем просто подсчет предметов. Например, для целей бухгалтерского учета вам может потребоваться знать учетную стоимость запасов на основе модели FIFO (First In First Out). Это нельзя рассчитать по простой формуле «сумма полученных запасов - общая сумма проданных запасов». Но их модель может легко вычислить это, потому что они изменяют учетную стоимость по ходу дела. Я не хочу вдаваться в подробности, потому что это не проблема программирования, но если они клянутся этим, возможно, вы не полностью поняли все их требования, которые они должны выполнить.

оба действительны, в зависимости от обстоятельств. Первое лучше, когда выполняются следующие условия:

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

с другой стороны, если у вас есть большое количество элементов, несколько исключительных случаев и частый доступ, будет более эффективно поддерживать количество элементов.

также обратите внимание, что если в вашей системе есть несоответствия, то в ней есть ошибки, которые следует отследить и устранить.

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

Важно учитывать существующую систему, а также стоимость и риск ее изменения. Я работаю с базой данных, в которой хранится инвентарь, как и у вас, но она включает в себя циклы аудита и хранит корректировки так же, как квитанции. Кажется, что это работает хорошо, но все участники хорошо обучены, а персонал склада не очень быстро осваивает новые процедуры.

В вашем случае, если вы ищете немного больше отслеживания без изменения всей структуры базы данных, я бы предложил добавить таблицу отслеживания (вроде вашего решения «транзакция»), а затем зарегистрировать изменения на уровне инвентаризации. Не должно быть слишком сложно обновить большинство изменений на уровне запасов, чтобы они также оставляли запись о транзакции. Вы также можете добавить периодическую задачу для резервного копирования уровня запасов в таблицу транзакций каждые пару часов или около того, чтобы даже если вы пропустили транзакцию, вы могли узнать, когда произошло изменение, или вернуться к предыдущему состоянию.

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

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

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

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

Я бы выбрал первый путь, где

количество в наличии рассчитывается путем суммирования полученных запасов - общего количества проданных запасов

Правильный путь, имхо.

РЕДАКТИРОВАТЬ: я также хотел бы учитывать любые потери/повреждения запасов в системе, но я уверен, что вы это предусмотрели.

Раньше я работал над системами, решающими эту проблему. Я думаю, что идеальным решением является столбец с предварительным вычислением, который дает вам лучшее из обоих миров. Ваша сумма будет где-то полем, поэтому нет дорогостоящих поисков, но она не может рассинхронизироваться с остальными вашими данными (база данных поддерживает целостность). Я не помню, какие RDMS поддерживают предварительно вычисляемые столбцы, но если у вас нет транзакций, они тоже могут быть недоступны.

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

Django-inventory больше ориентирован на основные средства, но может дать вам некоторые идеи.

IE: ItemTemplate (класс) -> ItemsOnHand (экземпляр)

ItemsOnHand можно связать с большим количеством ItemTemplates; Пример Требуется принтер и чернильные картриджи. Это также позволяет устанавливать точки повторного заказа для каждого ItemOnHand.

Каждый ItemsOnHand связан с InventoryTransactions, что позволяет легко проводить аудит. Чтобы избежать подсчета фактических товаров в наличии из тысяч инвентарных транзакций, используются контрольные точки, которые представляют собой просто баланс + дату. Чтобы рассчитать товары в наличии, запросите самую последнюю контрольную точку и начните добавлять или вычитать товары, чтобы найти текущий баланс товаров. Периодически определяйте новые контрольные точки.

Я вижу некоторую пользу от наличия двух столбцов, но я не понимаю часть о несоответствиях - вы, кажется, подразумеваете, что наличие двух столбцов (входного и исходящего) менее подвержено расхождениям, чем один столбец (текущий). Это почему?

Не имеет одного или двух столбцов, то, что я имел в виду под «суммарный полученный инвентарь - общее количество проданного инвентаря», выглядит примерно так:

Select sum(quantity) as inventory_received from Inventory_entry
Select sum(quantity) as inventory_sold from Sales_items

потом

Qunatity_on_hand = inventory_received - inventory_sold

Пожалуйста, имейте в виду, что я упростил это и мое первоначальное объяснение. Я знаю, что инвентаризация — это гораздо больше, чем просто отслеживание количества, но в данном случае проблема заключается в том, что мы хотим исправить. На данный момент причиной его изменения является именно стоимость поддержки проблем, вызванных текущим дизайном.

Также я хотел упомянуть, что, хотя это не вопрос «кодирования», он связан с алгоритмами и дизайном, которые, ИМХО, являются очень важными темами.

Спасибо всем за ваши ответы.

Нельсон Мармол

Мы решаем разные задачи, но наш подход к некоторым из них может быть вам интересен.

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

Чтобы применить это к инвентарю, у вас может быть 3 поля:

inventory_received
inventory_sold
estimated_on_hand

Затем вы можете запускать процесс (ежедневно?) в следующем порядке:

SELECT * 
FROM   Inventory
WHERE  estimated_on_hand != inventory_received - inventory_sold

Конечно, это зависит от того, просматривают ли пользователи это оповещение и что-то с этим делают.

Кроме того, у вас может быть функция для сброса инвентаря, либо путем обновления inventory_sold/received, либо, возможно, путем добавления другого поля «inventory_adjustment», которое может быть положительным или отрицательным.

... просто некоторые мысли. Надеюсь, это полезно.