Сейчас опишу задачу, которая должна решаться софтиной.
Представьте, что у нас есть невероятное количество всего подряд.
Винты (тысяча видов, десятки-сотни экземпляров для каждого вида), болты (аналогично), гайки (аналогичн.), шайбы (аналог.), саморезы (анлгчн.), втулки, (ну вы поняли, дальше писать не буду) шпильки, шпонки, пружины шестерёнки и прочие механические детали. Радиодетали (резисторы, конденсаторы, транзисторы, микросхемы, ещё куча всего) — всего куча видов (типов, номиналов) и куча экземпляров каждого вида (типа, номинала). Разъёмы, гнёзда, штекеры, тумблеры, переключатели, кнопки, лампочки, джамперы, электродвигатели (как очень маленькие, так и очень большие). Патчкорды, просто кабели, кабели с разъёмами на концах, в том числе стандартные кабели (например нуль-модемные кабели, или кабели VGA—VGA), в том числе совершенно нестандартные кабели, переходники — мыслимые и немыслимые. А ещё очень большое количество уникальных предметов, которые достаточно сложны, имеются в единственном экземпляре и не могут быть отнесены к вышеописанным категориям.
Программа должна позволять следующее:
- Учитывать всю эту всячину, то есть знать, что есть и сколько
- Учитывать при этом такой важный аспект, как хранение, то есть ещё и знать, где что лежит.
Программа должна быть невероятно гибкой.
Во-первых, она не должна быть расчитана на учёт чего-то конкретного. Знаете, есть отдельные написанные кем-то программы для учёта хранимым радиодеталей, или для учёта ещё какой-нибудь фигни. Они заточены под то, на что они расчитаны, и использовать их для хранения чего-то совершенно другого — уже страшно неудобно.
Должно быть так, чтобы можно было кастомизировать программу исходя из того, что мы собственно собираемся хранить. Должно быть можно создавать классы сущностей для учёта сущностей, обладающих схожими свойствами, или вообще являющихся одинаковыми. Класс должен опеделять название сущности, набор характеристик, присущих сущности. Набор сущностей — это крайне важно. Он должен быть виден на странице каждой сущности. Должно быть можно искать сущности по характеристики, сортировать, фильтровать.
Классы сущностей должны иметь механизм наследования. Например мы создаём класс «крепёжное изделие с резьбой». У этого класса как минимум будет характеристика, описывающее параметры резьбы хранимой сущности. От этого класса будут унаследованы три класса: «Шпильки», «Винты», «Болты». У класса «Винты», например, будут новые характеристики: тип головки винта, типа шлица (прямой, крестообразный, Torx, и т.п.) и так далее. У каких-то характеристик должны быть субствойства. Например, если мы выбрали крестообразный шлиц, то мы должны смочь выбрать между PH и PZ, или ничего не выбирать.
Возможно должно быть такое понятие как группы (или категории), потому что сущность не сможет является экземпляром сразу нескольких классов, но сможет входить в несколько групп. Поиск, сортировка, фильтрация по группам — обязательно. Должна быть возможность сделать так, чтобы членство в группе определялось фактом наличия, отсутствия или специального значения какого-либо из параметров.
У отдельных сущностей должна быть возможность указания каких-то новых опциональных параметр, которые, в таком случае, заменят параметр, определяемый классом, к которому принадлежат сущности.
То есть либо переопределять значение параметра уже имеющегося у класса сущности для отдельно взятой сущности.
Либо создавать новый параметр для сущности.
Например пусть есть класс, и для класса мы определяем такой параметр как «фотография сущности». Разумеется, мы не будем фотографировать каждую сущность, например, каждый коннектор из тысячи одинаковых коннекторов. Но, например, если вдруг такое понадобится, мы должны иметь возможность для отдельно взятой сущности задать особую фотографию.
Или мы имеем тысячу одинаковых сущностей, но одна сущность всё-таки незначительно отличается от других. Мы должны иметь возможность указать эту особенность для отдельно взятой сущности.
Или какая-то сущность имеет какую-то проблему. Например брак или возникшую неисправность или грозящую возникнуть неисправность. Мы должны не только иметь возможность указать её, но где-нибудь потом посмотреть список всех сущностей, имеющих проблему. Есть, например, патчкорд в котором оболочка кабеля вылезла из коннектора — надо переобжать. Или у коннектора обломился фиксатор — надо переобжать. Значит мы должны иметь возможность открыть окно и увидеть список всех сущностей, имеющих проблемы, которые нужно решить. Своеобразный TODO-лист. И конечно убрать сущность из списка, когда проблема решена. А лучше не просто убрать, а «закрыть проблему», чтобы потом можно было посмотреть, как когда и кем проблема была решена. Возможно проблема была решена, но не полностью.
Желательно при формировании проблему иметь возможность сослаться на другую сущность или на другой класс. Например, в вышеуказанном примере мы ссылаемся на класс «Коннектор 8P8C». Мы должны иметь возможность при указании проблемы как-то связать проблему с классом «Коннектор 8P8C», чтобы потом (например, когда появится куча этих коннекторов), иметь возможность посмотреть список проблем, требующих для своего решение привлечение коннекторов 8P8C.
Должна быть возможность иметь составные сущности. Например есть у нас класс сущностей «Коннектор DB-9». Есть сущности, то есть эти сами коннекторы. И есть сущности «нуль-модемные кабели». Очевидно, что в составе сущности «нуль-модемный кабель» есть две сущности «Коннектор DB-9». Должна быть возможность при поиске сущности поставить галочку «Показать также составные сущности, имеющие в составе искомую сущность».
___________________________
Совершенно другой момент — учёт всего этого с учётом места хранения. У каждого класса должна присутствовать возможность указать такой параметр как «location». Логично, что одинаковые сущности будут лежать в одном месте, например сотня 47 килоомных резистора будет лежать в одном контейнере. С другой стороны, должна быть возможность переопределить location для каждой отдельной сущности. Несколько сущностей разных классов могут лежать в одном и том же location. Просто так, или потому что у сущностей есть какая-то проблема.
Я специально пишу location. Система должна быть очень гибкой в вопросе того, как сохранять данные о местоположении сущностей.
Сущности могут лежать просто в 10 пронумерованных коробках.
Сущности могут лежать в матричном хранилище со строками и столбцами (и каждому контейнеру, например, присвается идентификатор A01, где A — идентификатор столбца, 01 — идентификатор строки)
Сущности могут лежать в кубическом хранилище со строками, столбцами и этажами.
Сущности могут лежать в коробках (каждой из которых присвоен идентификатор).
Коробки могут лежать на полках (полки пронумерованы).
Полки могут принадлежать стеллажам.
Стеллажей может быть много (пронумерованных).
Стеллажи могут находится в разных комнатах. Комнаты в разных зданиях. Здания в разных городах.
Сущности могут лежать в коробках. Или в пакетах. Пакеты в коробках. Коробки в других коробках, которые будут внутри других коробках, которые будут стоять на 5-ой полке 10-го стелажа в 401-ом кабинете на 4-ом этаже по улице Герцена.
Иными словами, принцип матрёшки
Я конечно утрирую, но система не должна быть завязана на конкретный принцип хранения. Иными словами, если система устроена так, что предполагает, что всё тупо хранится в пронумерованных коробках, то этого недостаточно. Окей, теперь мы знаем, что что-то лежит в коробке с кодом Ю4853, но, чёрт возьми, а где находит сама коробка Ю4853?
Программа должна позволять делать как очень простую систему хранения (тупо пронумерованные коробки), так и очень сложную (смерть Кощея на конце иглы, та игла в яйце, то яйцо в утке, та утка в зайце, тот заяц в сундуке, а сундук стоит на высоком дубу). Организацию хранения должно быть можно менять в процессе, и должно быть можно менять легко, а не с большим геморроем.
______________
В общем, программа должна решать две типовых задачи:
- Мы знаем, что нам нужно, но не знаем, где это лежит. Программа должна нам выдать местоположение: 10-ый стеллаж, 6-ая полка, на ней коробка с кодом «NZ423», в ней коробка «GR87», в ней пакет с кодом «60482».
- Мы знаем location, но не знаем, что там лежит. Что, чёрт возьми, хранится в этой коробке? Чем, блин, занята эта полка? Какой, ё-моё, хлам хранится в таком-то шкафу?
Конечно, можно пойти, вскрыть, и посмотреть, но смысл в том, чтобы этого не делать.
______________
Должно быть можно кастомизировать страницы-карточки, посвящённые сущностям разных классов.
Иными словами, я хочу, чтобы можно было сделать один layout для страницы «саморез такой-то» и совершенно другой layout для страницы «зубчатое колесо такое-то», и третий дизайн для страницы «пуговица такая-то».
И желательно — возможность кастомизировать форму поиска для поиска по определённым классам/подклассам.
_____________
Очевидно, что это должна быть какая-то очень гибкая система. Возможно — со скриптингом. С одной стороны, я понимаю, что программа очень сложная, и должно быть очень дорогая. С другой стороны — вдруг есть что-то гениально простое, но удовлетворяющее моим требованием (или, скажем так, способное быть настроенным так, чтобы удовлетворять моим требованиям).
Кто что посоветует?
