дизайн для «простой» системы инвентаризации

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

Во-первых, у нас есть простой перечень деталей. Нам не нужно отслеживать отдельные части (в любом случае мы не можем), поэтому я хочу смоделировать количество. Моя мысль состоит в том, чтобы иметь разные «контейнеры» деталей, которые имеют простое количество. Поэтому, если мы переместим видеокарту из ее «инвентарной» корзины в «корзину», я хочу, чтобы -1 к инвентаризации видеокарты и +1 к утилизации видеокарты. Корзины могут быть более четко определены по мере необходимости, например, pci-video-cards, agp-video-cards и т. д. Или, если мы подсчитываем наш инвентарь, нам может потребоваться сделать -3 от инвентаря и +3 к ' усадка».

Смысл этого в том, чтобы в любой момент знать, сколько, скажем, видеокарт у нас есть, сколько планок оперативной памяти и т. д. Два аспекта корзины — это какая часть в ней находится (на любом уровне специфичности, например, «old-misc-card» или «32MB-3.3v-agp-video») и назначение корзины, например «пожертвование», «инвентарь», «переработка», «хранение», « усадка» и др.

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

Итак, как мне спроектировать таблицы, чтобы справиться с этим? Я думаю, это будет что-то вроде бухгалтерской книги с двойной записью. У меня может быть одна таблица под названием «BinTransactions», где будут from_bin, to_bin и сумма. Сумма будет положительным целым числом, и если я хочу написать запрос о том, сколько будет изъято из инвентаря, я сделаю его отрицательным. Что-то вроде «ВЫБЕРИТЕ СУММУ (сумма) * -1 ИЗ BinTransactions, ГДЕ from_bin = «инвентарь» И time_period = ...»?

Вторая часть — это сами компьютерные системы. Они поступают в качестве пожертвований в любом состоянии, в котором они находятся. Части могут быть извлечены из них и помещены в инвентарь или переработаны; части могут быть извлечены из инвентаря и помещены в компьютеры. Думаю, я мог бы сделать компьютер

Наконец-то компьютер выходит из нашей системы в качестве гранта, но эта структура как бы имеет один уровень вложенности. Это набор компьютерных частей в компьютере, но есть еще монитор, клавиатура, мышь, возможно, динамики. А большим грантом может быть несколько систем, в том числе и с сетевым оборудованием. Должна ли «вкладываться» логическая иерархия групп (детали в компьютеры, компьютеры в гранты), или можно было бы просто иметь каждое пожертвование только одной большой группой частей? Если бы это была одна большая группа деталей, не обязательно было бы знать, какие части идут с каким компьютером, если бы мы получили один компьютер обратно по гранту. Также мы хотели бы узнать из отчетов "34 полные системы были переданы в дар в этом квартале..."


person Community    schedule 08.01.2010    source источник
comment
Будет ли это обновляться каждый раз, когда совершается продажа? Или, может быть, он обновляется только при проведении инвентаризации?   -  person wallyk    schedule 08.01.2010
comment
Хотя я обычно говорю обратное, я думаю, что на самом деле это тот случай, когда вопрос не должен быть вики сообщества. Очевидно, что некоторые ответы будут более разумными, чем другие, объективно говоря.   -  person John Feminella    schedule 08.01.2010
comment
Хорошо, я могу признать, что есть объективно лучшее решение, но я не думаю, что способен это определить! :) Думаю будут разные предложения с разными преимуществами и недостатками.   -  person user151841    schedule 08.01.2010
comment
@wallyk - в «магазине» нет собственного инвентаря или запасов. Люди приходят и покупают вещи из нашего инвентаря. Итак, когда кто-то что-то покупает, нам нужно знать, сколько вещей было взято от «запасов» до «продаж».   -  person user151841    schedule 08.01.2010
comment
@unknown RE: сообщество-вики: в этом смысл голосов на этом сайте. Хотя вы, возможно, не сможете определить лучший ответ. Сообщество действительно может проголосовать, чтобы помочь вам с этой информацией.   -  person Kevin Peno    schedule 12.01.2010


Ответы (2)


Похоже, проблема уже решена: http://sourceforge.net/projects/phpmyinventory/ http://sourceforge.net/projects/asset-tracker/ Это просто две ссылки, которые я нашел на sourceforge, введя «инвентарь» в поле поиска.

Самое основное описание таково:

  • Приходят компьютерные комплектующие.
  • Детали компьютера хранятся.
  • Детали компьютера уходят.

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

  • Кто подарил компьютер
  • Кому подарили компьютер

Что касается логической обработки: например, веб-страница с надписью: «Вау! Мы получили компьютер! В нем есть:

  1. Блок питания?
  2. Видеокарта?
  3. Звуковая карта?
  4. И так далее."

То же самое можно сделать и при передаче компьютера - но вам нужно удалить «1» из хранилища для каждой из частей, которые уходят!

Итак, как мы обрабатываем инвентарь? Ну, вы могли бы иметь одну таблицу, которая выглядела бы так:

video card   | recycle | donation-in | storage | garbage
sound card   | recycle | donation-in | storage | garbage
power supply | recycle | donation-in | storage | garbage

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

И таблица, которая выглядела так:

part name | from_bin | to_bin | quantity

Большая часть логики для перемещения величин, вероятно, должна обрабатываться приложением (я больше люблю Ruby-on-Rails, так что для меня это имеет смысл). Надеюсь, это поможет.

person Community    schedule 19.01.2010
comment
Я надеялся найти решение, в котором компьютер представлял бы собой набор деталей, больше похожий на мусорное ведро. В нем будут транзакции, как в корзине, куда входят и выходят части. - person user151841; 20.01.2010
comment
Причина, по которой я хочу воздержаться от «жесткого кодирования» статусов деталей в столбцах, заключается в том, что компьютер, который мы получаем, может быть полностью разбит на части и переработан. Сущности, которые я хочу отслеживать в этой модели, — это движения частей — транзакции между контейнерами и компьютерами, а не сами системы. - person user151841; 20.01.2010
comment
Точно так же система может возникнуть, будучи полностью собранной из частей. Итак, модель, которую я хочу создать, — это система как слияние частей, а не сама сущность. - person user151841; 20.01.2010
comment
Добавьте еще одну таблицу: id | part_name Тогда у вас может быть: 1 | видеокарта 2 | звуковая карта 3 | блок питания 4 | клавиатура 5 | мышь И вы можете просто добавлять строки в любую другую таблицу, ссылаясь на эти имена - теперь имена не жестко запрограммированы. Что касается жесткого кодирования статусов, то же самое. Составьте таблицу статусов, а потом ссылку на тех. Таким образом, вы можете получить таблицу, которая делает следующее: date | part_id | from_id | to_id 20-01-2010, 14:15:14 | 5 | 1 | 4 - person Trevoke; 20.01.2010
comment
Вы хотите, чтобы многие части стали одним компьютером, и я не знаю, хотите ли вы, чтобы этот компьютер хранился в базе данных как дополнение или просто был отправлен. Я не уверен, что база данных может сделать это за вас, но с помощью внешней логики базе данных можно сказать: «Хорошо, теперь мы удаляем по одному из этих элементов и добавляем один из этих элементов». База данных содержит данные и отношения между данными. Это не соответствует бизнес-логике :) - person Trevoke; 20.01.2010
comment
Ну да ладно, но в этом проекте главная цель — следить за потоком деталей. Если конечная точка покоя детали находится в системе, а не в бункере, и база данных не может смоделировать предоставление вне системы, это нормально. То, что мы хотим отслеживать внутри, — это наши запасы, которые поступают из потоков деталей. - person user151841; 20.01.2010
comment
Позвольте мне проследить ход ваших мыслей. Дайте мне знать, если я ошибаюсь. Вы хотите отслеживать, какие части идут откуда куда. Для этого нам нужно знать часть, пункт отправления и пункт назначения, количество и, возможно, отметку времени. Часть это... Часть. Вы можете поместить его в таблицу с идентификатором и описанием. Пункт отправления и пункт назначения — это места: снаружи, внутри, переработка, холодильник. Их можно поместить в одну таблицу с идентификатором и описанием. Количество, ну, зависит от транзакции. Это должно остаться в этой таблице. К нему просто прикрепляется временная метка. (продолжает) - person Trevoke; 20.01.2010
comment
Итак, я только что описал именно ту систему, которую предложил вам, за вычетом исходной таблицы, в которой говорится, что у нас есть столько-то таких частей в том месте. Предположительно, потому что проведение первоначальной инвентаризации было бы проблемой, и вы хотите избежать этого. Если все, что вас действительно волнует, — это поток деталей через ваше местоположение, то вам не нужна последняя таблица. Однако в качестве предупреждения запуск отчетов может быть очень болезненным. Это примерно ваши мысли? - person Trevoke; 20.01.2010
comment
Ну, на самом деле мы не хотим отслеживать детали по отдельности. Система, которую я себе представлял, была больше похожа на систему бухгалтерского учета с двойной записью. В этой структуре базы данных у меня есть таблица транзакций, в которой указано, что мой текущий счет равен -500, а счет моей кредитной карты равен +500, а соответствующие балансы на определенный момент времени равны x и y. Мне на самом деле не нужно отслеживать каждый отдельный доллар, перешедший с одного счета на другой — мне важно сколько. - person user151841; 21.01.2010
comment
Точно так же в нашем магазине сейчас мы не отслеживаем запчасти. Все, что у нас есть, это инвентаризация (У нас 50 жестких дисков. Мы вытащили 10 планок из оперативной памяти из компьютеров). Таким образом, части одного типа взаимозаменяемы, как доллары. Все, что мы хотим отслеживать в этой системе инвентаризации, — это транзакции, суммы в и из, и использовать это для построения запросов баланса, таких как У вас есть 50 жестких дисков прямо сейчас или Инвентаризация жестких дисков имеет тенденцию к снижению с июня. Так же, как валютный учет. - person user151841; 21.01.2010
comment
Даже если бы мы хотели отслеживать детали, мы не могли бы организационно (кто будет вводить серийные номера деталей в базу данных? Мы не можем позволить себе термопечатаемые наклейки с серийными номерами — это благотворительность) что-либо. Кого волнует, что флешка № 283985209348 была вытащена из компьютера и выброшена в мусорное ведро? Мы просто выбросили один в мусорное ведро после того, как он прошел тестирование. +1 к инвентарю, -1 от тестирования. - person user151841; 21.01.2010
comment
Ах! Я понимаю. То, что я вам описывал, не отслеживает отдельные части, а только суммы. Я по-прежнему считаю, что это самый простой способ отслеживать все данные, которые вы хотите отслеживать. Я бы добавил простое задание SQL, чтобы регулярно выполнять инвентарный запрос и хранить его в другой таблице с датой и ячейками, чтобы вы могли видеть со временем изменения баланса в каждой ячейке. Я думаю, что недоразумение связано с тем, что мы думаем о «инвентаризации». Я просто имею в виду следить за тем, что у нас есть. Вот что я вам скажу — это будет для меня хорошим упражнением, я построю вам что-нибудь простое, чтобы показать, что я имею в виду. - person Trevoke; 21.01.2010
comment
:) Хорошо -- какая база данных? Если это не postgres или mysql, я не смогу его запустить. - person user151841; 21.01.2010
comment
MySQL.. Это то, что я установил. Это также будет Ruby on Rails. Это займет у меня некоторое время, так как у меня есть другие обязательства - поэтому, если у вас есть еще вопросы, о том, что именно я предлагаю и чем это отличается от того, что вы хотите, обязательно спрашивайте! Я действительно надеюсь, что получу твоего первенца или, по крайней мере, зеленую отметку, когда все будет готово :p - person Trevoke; 21.01.2010
comment
хм... у меня нет среды RoR! Это просто структура таблицы и запросы, которые вы пишете? - person user151841; 21.01.2010
comment
Конечно. Тогда я просто дам вам скелет/шаблон базы данных. - person Trevoke; 21.01.2010
comment
Вот оно: gist.github.com/283897 Не хватает хранимой процедуры/запланированной задачи для проводите регулярный опрос бункеров и добавляйте итоги в таблицу «ежемесячные подсчеты» — для облегчения составления отчетов об изменениях количества с течением времени. Дайте мне знать, как это происходит для вас. - person Trevoke; 22.01.2010
comment
Тебе эта ссылка вообще не помогает? Что-то не так? - person Trevoke; 25.01.2010
comment
Извините, что долго не отвечал, был занят другими делами. На нашем складе я не думаю, что мы сможем отслеживать детали по типам в отдельности. Все, что находится в одной коробке, является одной и той же «частью», например, «используемые жесткие диски» или «жесткие диски для тестирования». Так что я бы избавился от таблицы частей. Есть просто вещи, перемещающиеся из корзины в корзину, и то, чем они являются, зависит исключительно от того, в какой корзине они находятся. Кроме того, я пытался подумать о том, чем компьютерные системы могут быть похожи на корзины, которые также принимают частичные потоки. Если вы разместите код в другом ответе, я проголосую и приму его. - person user151841; 30.01.2010
comment
Жесткий диск является частью. Зачем вам избавляться от этого, ведь это именно то, что вы пытаетесь отследить? Полезным будет мусорное ведро. To_test будет другим бином. Вот... Прочтите это: rdbms.ca/database/introduction.html Может быть, это помогите лучше понять. - person Trevoke; 01.02.2010
comment
Мы не обязательно пытаемся это отследить. Мы просто пытаемся подсчитать, сколько вещей у нас есть. Таблица деталей слишком сложна. Если мы отправим 12 планок оперативной памяти и 20 старых модемных плат на «переработку», нам будет все равно, сколько у нас там планок оперативной памяти и сколько модемов. Нас волнует только то, что 32 вещи переместились из двух корзин в одну. - person user151841; 01.02.2010
comment
Или, другими словами, части получают свою идентичность от того, где они расположены; это не присуще. Или, даже по-другому, мы действительно не отслеживаем детали. Мы просто хотим отслеживать количество контейнеров в разное время. - person user151841; 01.02.2010
comment
Тогда попробуем надуманный пример. У вас есть: Только что полученная корзина с 15 планками оперативной памяти и 4 мышами. В нем 19 предметов. Проверенная исправная корзина с 3 клавиатурами и 6 жесткими дисками. В нем 9 предметов. Плохая корзина с 4 блоками питания и 2 батарейками ААА. В нем 6 предметов. Все, что вам нужно знать, это то, что 4 предмета перешли из состояния «только что получено» в состояние «проверено-хорошо», и для вас не имеет значения, были ли отправлены четыре мыши или одна мышь и три планки оперативной памяти. Это правильно? - person Trevoke; 01.02.2010
comment
Ну, они пойдут в tested-good-mice-trackball, tested-good-mice-optical, tested-good-512MB-DDR2 и т. д. Я имею в виду, что это те коробки, которые у нас есть буквально прямо сейчас. Поэтому я пытаюсь создать модель данных, которая соответствует тому, что мы уже используем. В противном случае это очень затрудняет принятие. И я не уверен, что мы могли бы справиться даже с более тонкой системой организационно. Все части внутри контейнера взаимозаменяемы. Если они разные, они помещаются в другую коробку. - person user151841; 01.02.2010
comment
Чем именно это отличается от системы, которую я вам дал? У вас есть детали и контейнеры. Это означает, что если OPTICAL_MOUSE имеет part_id 1, и если TESTED-GOOD bin имеет bin_id 1, то у вас может быть 15 частей 1 в bin 1. И это 15 хороших оптических мышей... В бине хороших оптических мышей. Если TESTED-BAD равен bin_id 2, то если у вас 5 частей 1 в bin 2, то у вас 5 плохих оптических мышей. Вы можете добавить неопознанную часть и иметь только 587 неопознанных объектов в папке «Входящие», а затем уменьшить количество неопознанных в папке «Входящие» и увеличить что-то еще в другом месте. Это все еще не имеет смысла? - person Trevoke; 01.02.2010
comment
Я размышляю над тем, как это может быть по-другому, а между тем у меня возникает такой вопрос: если это не по-другому, то зачем? Если это функционально то же самое, но структурно проще, не следует ли мне использовать более простую модель данных? Схема с parts сложнее — в ней есть дополнительная таблица. Если мы можем от него избавиться, то почему бы и нет? Это упростило бы запросы. - person user151841; 01.02.2010
comment
Потому что с добавленной таблицей вы получаете гораздо большую гибкость и меньшее количество повторений данных, что означает меньший размер базы данных. - person Trevoke; 01.02.2010
comment
Можете ли вы привести несколько сценариев, иллюстрирующих дополнительную гибкость и отсутствие повторений? - person user151841; 02.02.2010
comment
вздох У вас нет никакого опыта работы с базами данных, не так ли? Если у вас есть только таблица бинов, вам нужна строка для хороших видеокарт, строка для плохих видеокарт, строка для тестируемых видеокарт, а затем только один столбец для каждого счетчика. И каждый раз, когда у вас появляется новая деталь, вы должны добавлять X строк, где X — количество бинов. Если у вас есть таблица бинов и таблица частей, то вы можете иметь одну строку для видеокарт, столбец для каждого бина и количество в соответствующей ячейке. Просто добавьте строку для новой детали, столбец для новой корзины — и ВСЕ получат новую корзинку. - person Trevoke; 02.02.2010

Поскольку компьютер — это битовый набор деталей, мы отслеживаем сборки в LedgerSMB следующим образом:

У нас есть таблица деталей, в которой у каждой детали есть флаг сборки.

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

person Community    schedule 23.03.2013