Статья "Складской учет"

Статья опубликована в журнале "Программист", февраль 2002 год.

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

Download PDF

P.S. Если будут замечания или комментарии, присылайте на почту - я их здесь выложу.

Глеб Головин

Q: Вопрос о иморте-экспорте данных. Какой посоветуете использовать копонент для формирования xml-файлов? И каким образом наладить связь между офисом и магазинами по передаче синхронизационных данных, если доступна только модемная связь?

A1: Для работы с XML можно использовать большое количество различных компонентов и библиотек. Мне нравится парсер от Microsoft (msxml 4.0). В первую очередь благодаря хорошей документации и поддержке XSLT. Для импорта-экспорта таблиц можно использовать средства Microsoft ADO и ADO.NET или написать собственные. Так же доступны библиотеки компонентов третьих фирм, к примеру от e-delos.com. Обязательно надо учесть наличие компоненты-обертки для XML парсеров в Borland Delphi 6. И, вообще, сейчас все инструментальные среды разработки программ предусматривают библиотеки для работы с XML.
A2: Для передачи XML данных советую использовать SOAP. Он для этого был специально разработан. Для работы с SOAP есть библиотека от Microsoft и набор компонентов в Delphi 6.
A3: А для собственно связи двух компьютеров можно использовать средства удаленного доступа к сети. Так компьютер со склада будет через Dial-up входить в сеть офиса (в Windows NT это RAS) и обмениваться через SOAP XML данными. При этом сервер по приему/отправке данных (к которому обращаются со склада) очень просто можно реализовать как расширение к WEB-серверу IIS и, вероятно, Apache тоже.

Ксения Гришанова

Q: Замечание по структуре БД. Вы создаете 3 пары одинаковых таблиц документ/спецификация документа - по количеству типов документов. Это, на мой взгляд, плохо, т.к.:
1. Усложняет модель структуры данных и в конечном итоге структуру БД
2. Не дает возможности добавлять новые типы документов без вмешательства в структуру БД

Наверное, можно вытащить и другие минусы, если подумать, но эти два очевидны. Я недавно сама написала программу складского учета для одной бюджетной организации и при ее создании делела так: создаем 3 таблицы: типы документов, документы, спецификации документов. При этом каждый документ имеет уникальный ключ по комбинации полей номер/тип, все остальное аналогично тому как это изложено в статье. По описанной мной схеме работает известная бухгалтерская программа "Парус Бюджет" и, наверное, программистов "Паруса" нельзя заподозрить в некомпетентности.

A: Справедливое замечание. Существует как минимум два подхода при определении структуры БД ИС. Первый из них (когда для каждого документа заводится отдельная таблица) описан в статье; второй - описали Вы. У каждого из подходов есть сильные и слабые стороны:

Если для каждого документа завести собственную пару таблиц, то:

  • Каждый документ может иметь собственный набор полей шапки и табличной части.
  • В ИС с большим набором разнородных документов такой подход упрощает структуру и повышает производительность СУБД.
  • За счет собственного автоинкрементного поля у каждого документа очень легко реализовать их автоматическую нумерацию.


    • Если для всех документов завести общий набор таблиц с выделением специального поля для определения типа документа, то:
  • В ИС с однородными документами существенно упрощается модель данных.
  • Пользователь может добавлять новые документы без внесения изменений в структуру БД.


    • Как Вы видите, оба варианта достаточно интересны. Но ИС с однородными документами все же большая редкость, поэтому первый подход универсальнее. В случае складской программы действительно можно очень эффективно применить предложенный Ксенией метод и получить простую по структуре БД с небольшой, но хорошо работающей программой. Кстати, по описанной в статье схеме, насколько я понимаю, работает 1С: Предприятие. А они - самые крупные производители бухгалтерских и складских программ в СНГ.

    Алексей Алексеев

    С: Запрос 

    SELECT serial
FROM (
  SELECT table2.serial AS serial, sum(table2.quantity) AS total_quantity
  FROM table2
  WHERE table2.name = 'Nokia 3210'
  GROUP BY table2.serial
  )
WHERE total_quantity > 0
    можно записать проще 
    SELECT serial
FROM table2
WHERE name = 'Nokia 3210'
GROUP BY serial
HAVING sum(quantity) > 0

    A: Спасибо.
    Хостинг от uCoz