Разработка базы данных инвентаризации

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

В прошлом я разработал системы, которые так или иначе сохраняют некоторую форму инвентаризации предметов (не уместно, какие предметы). Некоторые используют языки/БД, которые не поддерживают транзакции. В тех случаях я решил не сохранять количество предметов под рукой в поле в записи позиции. Вместо этого подсчитывается количество на общую сумму инвентаря - общее количество проданных запасов. Из-за программного обеспечения практически не было расхождений в инвентаре. Таблицы правильно проиндексированы и производительность хороша. Существует процесс архивирования, если количество записей начинает влиять на производительность.

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

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

Спасибо

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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

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

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

Ответ 5

Взгляните на модель данных ARTS (Association for Retail Technology Standards) (http://nrf-arts.org). Он использует таблицу StockLedger с записью каждого элемента и изменения в инвентаре отслеживаются в InventoryJournalEntries.

Ответ 6

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

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

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

Ответ 7

Я бы выбрал первый способ, где

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

Правильный путь, ИМО.

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

Ответ 8

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

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

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

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

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

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

Ответ 12

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

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

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

Также я хотел бы упомянуть, что, хотя это не вопрос "кодирования", он связан с алгоритмами и дизайном, которые IMHO являются очень важными темами.

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

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

Ответ 13

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

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

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

inventory_received
inventory_sold
estimated_on_hand

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

SELECT * 
FROM   Inventory
WHERE  estimated_on_hand != inventory_received - inventory_sold

Конечно, это зависит от пользователей, которые смотрят на это предупреждение и что-то делают с этим.

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

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