Управління складом - модель даних - функції - обладнання; Матеріал - Готовність; Виживання

Зараз це може поміститися на складі або в ІТ, але спочатку подумайте, що область ІТ краще.
Якщо ви переглядаєте форуми, виглядає потреба в електронному управлінні складами, але більшість проектів, схоже, засинають порівняно швидко. З OpenSource ви все ще можете отримати доступ до даних і можете продовжувати працювати зі старим програмним забезпеченням деякий час, із ClosedSource або додатками, які більше не підтримуються, копітко підтримувані бази даних в якийсь момент втрачаються.
Для власних цілей я працюю над рішенням на основі LAMP (Linux/Apache/mysql/PHP). Але я хотів би спроектувати базову базу даних таким чином, щоб вона не тільки відповідала моєму малому та середньому проекту, але також могла відображати більші та менші проекти. Мета полягає у визначенні структури бази даних, яка може використовуватися для різноманітних проектів - і яка робить дані портативними. Звичайно, включений і API з основними функціями.

Основні міркування щодо бази даних:
- Мульти-клієнтська можливість, тобто кілька окремих сховищ в одній базі даних. З точки зору безпеки, особливо з нашими темами, а не NonPlusUltra, оскільки принаймні адміністратор бачить все, але він також пропонує можливість встановлення випробувальних таборів, не порушуючи роботу в режимі реального часу. Врешті-решт, це лише ще одне поле для таблиці
- EAN/GTIN тощо повинні бути відмінною рисою для всього, що зберігається. З вільних площ можна створити відповідне число для власних продуктів (перезаправлених, самостійно відварених тощо).
- Категорії (на основі державних систем)
- Ієрархія зберігання від місця зберігання-> полиця-> рівень-> рядок-> підвідділення повинна пропонувати достатню гнучкість для всіх розмірів. Має бути можливим багаторазове бронювання в відсіку для зберігання (дуже мало хто зробить це настільки точно, що окремий відсік буде призначений для кожного товару/дати, що передує даті). Для екстремістів ви можете додати прапор, який контролює цю поведінку.
- всього на UTF8 має бути достатньо
- Встановити можливість, якщо ви завжди складаєте однакові пакети. Наприклад, для мене це вакуумні пакети з основними продуктами харчування на тиждень/одну людину.

Ліцензія тощо.
- Структура коду та бази даних за відкритою ліцензією, але я ще не знаю, чи дешевші GPL, BSD чи будь-яка інша.
- Оскільки доглянутих та безкоштовних баз даних EAN бракує, безумовно, слід зробити кілька ручних робіт. Зібрані дані (EAN, ім'я, таблиця поживних речовин, присвоєння категорій) повинні вільно обмінюватися і, за бажанням, бути доступними кожному у зібраній формі.

відкритий для всіх пропозицій - я вже писав щось подібне у дуже старій темі - мабуть, занадто старий.

Перш за все, я бажаю вашому проекту довгого та повноцінного життя!

Я розділив свої пропозиції на два компоненти "програмне забезпечення" та "база даних", щоб було легко зрозуміти, де я їх знаходжу:

"Функція переміщення" (коли харчовий продукт переміщується з місця X на полицю; наприклад, з міркувань простору)
Якщо EAN використовується як ключ: генератор EAN (для власних бакалійних продуктів; щоб не потрібно було шукати правильні номери з вільно доступного пулу та уникати дублікатів
Функція пошуку вже зареєстрованих статей
Дублікат перевірки
Якщо це вже мульти-клієнтська можливість, то також з (необов’язковою) концепцією авторизації.
Комп’ютер RDA (можливо, з кількома RDA, оскільки кожна економічна область, частково кожна країна, має свої рекомендації)
Функція імпорту та експорту, якщо це необхідно, машиночитання та читання людиною

Я б не використовував EAN як ключ, щонайбільше як просте поле даних (і навіть не як обов’язкове поле). Довідкова інформація: Я не завжди купую продукти X у однієї компанії (наприклад, тому що Inzersd * rfer діє сьогодні, а F * lix - завтра). Однак для мене перець чилі кон карне за великим рахунком такий самий, як чилі кон карне. Або запечена квасоля Хайнца, іноді з чилі, іноді без. Відмінності в харчовій цінності між двома марками або сортами, швидше за все, будуть меншими, ніж між двома партіями домашнього приготування.
Можливість запису мікро- та макроелементів. (Білок, жир, вода, вміст вуглеводів і цукру, мінерали, вітаміни, мікроелементи). І звичайно ккал/кДж.
Окрім грамів як одиниці ваги, включайте також шматочки, порції (особливо цікаві для вітамінів) та літри.

LG, удачі та збереження сили,

Працюй так, ніби живеш вічно. Любіть так, ніби сьогодні збираєтеся померти.

До баз даних EAN
База даних fddb навіть має API для зовнішнього доступу і є безкоштовною.
https://fddb.info/api/v18/documentation/

[USER = "2997"] Maresi [/ USER] На жаль, просто не так, що вміст готових страв є обмінним між різними виробниками.
Різниця в цінах виникає внаслідок різної частки води або "дешевих калорій", таких як промисловий цукор або зерно.
Для тих, хто базує свої запаси на готовій продукції та "банках", посилання на готову базу даних коштує золота.

Я використовую базу даних FDDB через розширювач для планування харчування. Це чудово працює.

Я думаю, що вся система ПОВИННА залишатися офлайн. Тож було б добре, якби інформація, «зібрана» в мирний час, будь то з fddb чи інших джерел, зберігалася локально.

Кілька років тому я представив "резервну базу даних" тут, на форумі. Не справжня програма БД, а файл Excel. З точки зору функціональності, це було б приблизно мінімальною вимогою до нової системи для мене.

1. База даних статей (ідентифікатор статті, назви, ціни, джерела постачання, харчова цінність та розподіл поживних речовин, категорія товару, мінімальний рівень запасу)
2. Управління запасами з датою зберігання, місцем зберігання, найкращим до дати, ідентифікатором статті
3. Автоматичне створення списків покупок на основі мінімальних рівнів запасів та/або MHD
4. Автоматичний звіт про прострочені та закінчувані терміни
5. Персональна база даних з віком, статтю, рівнем активності (для розрахунку потреб)
6. Розрахунок потреб та охоплення наявної їжі
7. Огляд поживних речовин зберігається продуктів харчування на основі рекомендованого розподілу.

Якби я міг програмувати, я б, мабуть, вирішив це за допомогою бази даних. На жаль, я не можу. За це мене в Excel ніхто не обдурив.

Убити людину, викопати дві могили.

Але повна копія бази даних FDDB не потрібна для роботи з базою даних.
У "мирний час" інформація з FDDB викликається, коли стаття зберігається, а потім обробляється, а отримана інформація зберігається локально. Це жодним чином не є порушенням політики API.
Ця ситуація комфорту не існує в режимі офлайн, і вам доведеться вводити її вручну.

Оскільки в заголовку Модель даних сказано, що я почав займатися одним

продукту
-------
Product_ID INTEGER
Product_NAM VARCHAR (50)
Product_TXT VARCHAR (255)

компонент
-----------
ІДЕНТИФІКАТОР ІНТЕГРА
Компонент_NAM VARCHAR (50)
Компонент_TXT VARCHAR (255)

од
-------
Unit_ID
Unit_NAM VARCHAR (50)
Unit_TXT VARCHAR (255)

Кількість інгредієнтів
----------------
Product_ID INTEGER
Component_ID INTEGER
Кількість_NUM ДЕКІМАЛЬНА (8.2)
Unit_ID INTEGER

продукту
1 - Гуляш - Великий консервований гуляш з легкою нотою чилі

компонент
1 - теплотворна здатність
2 - яєчний білок
3 - вуглеводи
4 - цукор
5 - жирний
6 - насичений жир
7 - клітковина
8 - натрій
9 - вітамін С.
10 - сіль

од
1 грам
2 відсотки
3 - ккал

Кількість інгредієнтів
1 - 1 - 110 - 3
1 - 5 - 5,5 - 1
1 - 6 - 1,6 - 1
1 - 3 - 4,7 - 1
1 - 4 - 0,9 - 1
1 - 2 - 10 - 1
1 - 10 - 1,1 - 1

Чого ще не вистачає, звичайно:
* Упаковка/контейнер (банка, пляшка, скло, папір,.)
* Виробник - можливо, є частиною товару
* Покупка (угода, дата, ціна, номер, знижка,.)
* Місце зберігання - вільно визначена ієрархія. Квартира - кімната - полиця - підлога - коробка - .
* Категорія (консерви, гарнір,.)
* Стан (консерви, MRE, сирі, варені,.)
* Рецепти

відчинено
Вжити до. Якщо я купую 5 банок одного і того ж товару в одному магазині, я все одно можу отримати 5 дат із найкращими термінами

Я можу придумати ще 100 речей. але перш ніж замислитися далі: чи йде це в правильному напрямку?