Проектирование баз данных материально-технических ресурсов [закрывается]

• Книга Ресурса Модели данных, Издание 1: Библиотека Универсальных Моделей данных для Всех Предприятий
• Книга Ресурса Модели данных, Издание 2: Библиотека Моделей данных для Определенных Отраслей промышленности
• Книга Ресурса Модели данных: Универсальные Шаблоны для Моделирования данных

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

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

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

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

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

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

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

Смотрите на ARTS (Ассоциация для Розничных Технологических Стандартов) модель данных ( http://nrf-arts.org ). Это использует таблицу StockLedger с записью, каждый объект и изменения в материально-технических ресурсах все прослежены в InventoryJournalEntries.

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

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

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

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

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

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

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

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

Правильный Путь, IMO.

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

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

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

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

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

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

Для применения этого к материально-техническим ресурсам у Вас могло быть 3 поля:

inventory_received
inventory_sold
estimated_on_hand

Затем Вы могли выполнить процесс (ежедневно?) вроде:

SELECT * 
FROM   Inventory
WHERE  estimated_on_hand != inventory_received - inventory_sold

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

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

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

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

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

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

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

Спасибо все для Ваших ответов до сих пор.

Nelson Marmol

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

IE: ItemTemplate (класс) -> ItemsOnHand (instance)

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

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