Створення бази даних інвентаризації [закрито]

Це питання насправді не про "програмування" (не характерне для будь-якої мови чи бази даних), а більше про дизайн та архітектуру. Це також питання типу "Який найкращий спосіб зробити Х". Сподіваюся, це не викликає великих "релігійних" суперечок.

У минулому я розробляв системи, які так чи інакше ведуть певну форму інвентаризації предметів (не стосується яких предметів). Деякі використовують мови / БД, які не підтримують транзакції. У цих випадках я вирішив не зберігати кількість товару на руках у полі в записі товару. Замість цього кількість на руці розраховуються на загальну суму інвентаризації отримала - загальна кількість запасів продана. Це майже не призвело до розбіжностей в запасах через програмне забезпечення. Таблиці належним чином індексуються, а продуктивність хороша. Існує процес архівування на випадок, якщо кількість записів вплине на продуктивність.

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

Я хотів би знати, чи існує консенсус щодо того, яким є правильний спосіб розробити таку систему. Також, які ресурси доступні, надруковані чи в Інтернеті, щоб отримати поради щодо цього.

Дякую

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

Якщо ви десь зберігаєте лише загальну кількість у полі, ви навіть не уявляєте, як ви дійшли до цього числа. Історія транзакцій відсутня, і у вас можуть виникнути проблеми.

Остання система, яку я написав, відстежує запас, зберігаючи кожну транзакцію як запис із позитивною чи негативною кількістю. Я виявив, що це працює дуже добре.

• Ресурсна книга з моделі даних, вип. 1: Бібліотека універсальних моделей даних для всіх підприємств
• Ресурсна книга з моделі даних, вип. 2: Бібліотека моделей даних для конкретних галузей
• Довідник з моделі даних: Універсальні шаблони для моделювання даних

У мене є Том 1 і Том 2, і вони були дуже корисні в минулому.

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

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

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

з іншого боку, якщо у вас велика кількість предметів, кілька виняткових випадків і частого доступу, буде ефективніше підтримувати кількість товару

також зауважте, що якщо у вашій системі є розбіжності, то вона має помилки, які слід відстежувати та усувати

я працював із системами в обох напрямках, і обидва способи можуть працювати чудово - доки ви не ігноруєте помилки!

Погляньте на модель даних ARTS (Асоціація стандартів роздрібних технологій) ( http://nrf-arts.org ). Він використовує таблицю StockLedger із записом кожного елемента, а зміни в інвентарі відстежуються в InventoryJournalEntries.

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

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

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

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

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

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

Я б обрав перший шлях, де

обчислювана кількість розраховується на загальну суму отриманих запасів - загальну кількість проданих запасів

Правильний шлях, ІМО.

РЕДАГУВАТИ: Я також хотів би врахувати будь-які втрати запасів / збитки в системі, але я впевнений, що ви це покрили.

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

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

Інвентар Django спрямований більше на основні фонди, але може дати вам кілька ідей.

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

ItemsOnHand можна пов’язати з більшою кількістю ItemTemplates; Приклад Принтер і чорнильні картриджі потрібні. Це також дозволяє встановити точки упорядкування для кожного ItemOnHand.

Кожен ItemsOnHand пов’язаний з InventoryTransaction, що дозволяє легко проводити аудит. Щоб уникнути обчислення фактичних наявних позицій з тисячі запасів, використовуються контрольно-пропускні пункти, які є просто залишком + датою. Для обчислення предметів, що знаходяться під рукою, потрібно знайти найновіший контрольний пункт і почати додавати або зменшувати елементи, щоб знайти поточний баланс предметів. Періодично визначайте нові пункти пропуску.

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

Не маючи однієї чи двох колонок, я мав на увазі "загальний обсяг отриманих запасів - загальна кількість проданих запасів" приблизно такий:

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 є дуже важливими темами.

Дякуємо усім за ваші відповіді.

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

Ми вирішуємо різні проблеми, але наш підхід до деяких з них може бути вам цікавий.

Ми дозволяємо системі зробити "найкращу здогадку" і регулярно надавати користувачам відгуки про будь-які з тих припущень, які виглядають неправильно.

Щоб застосувати це до інвентаризації, ви можете мати 3 поля:

inventory_received
inventory_sold
estimated_on_hand

Потім ви можете запустити процес (щодня?) За назвою:

SELECT * 
FROM   Inventory
WHERE  estimated_on_hand != inventory_received - inventory_sold

Звичайно, це покладається на користувачів, які переглядають це сповіщення та щось з цим роблять.

Крім того, у вас може бути функція скинути інвентаризацію деяким чином, або шляхом оновлення inventory_sold / получен, або, можливо, додавши інше поле "inventory_adjustment", яке може бути позитивним або негативним.

... лише деякі думки. Сподіваюся, це корисно.