Добрый день!

Хочу написать приложение (на java-ве) которое соединялось бы с базой для осуществления запросов, добавление удаление данных о товаре который храниться на складе. В качестве СУБД - mysql. Для хранения данных создал схему которую предполагаю использовать если она верна )))

В качестве примера взял задание одного из учебныx центров:

авторТребуется создать систему учета товаров на складе.
Основные параметры учета:
- код товара (уникальный), например артикул;
- наименование товара;
- количество едениц товара;
- еденицы измерения товара (выбор из справочника едениц измерения)
- место хранения товара (выбор из справочника мест хранения)

Процесс должен отображать этапы:
-приходование товара на склад
-выдача со склада на реализацию
-возврат некачественного товара поставщику

Для оптимизации предлагается использование общего справочника Организаций: Поставщиков и Получателей товаров.
Система учета должна хранить всю историю работы с товаром.


К сожалению не имею большого опыта в создании схем поэтому - есть то что есть ))
Ход мысли такой:
products - главная родительская (рутовая) таблица - которыя использует:

-junction_tb_for_warehouses для определения отношения многие ко многим - например если три контейнера с сигаретами занимают 2 зоны(2 сектора) или если сигареты, водка и спички хранятся в одной зоне на складе.

-junction_for_in_out - используется для отображения всех манипуляций с товаром и хранения истории.(приход, возврат, выдача)

- таблицы organizations и units_measurement используют отнашение один ко многим здесь все ясно.

В общем критика приветствуется.
Если есть где ошибки или неточности оставляйте комментарии.

Упс! уважаемые модераторы ошибся разделом перенесите пжлста в другую ветку по проектированию! спасиб.

Модератор: Тема перенесена из форума "Сравнение СУБД".

d7iShtock,
Это учебная задача?
Если учебная, то можете лепить что угодно, не спрашивая ничьих советов...

А если боевая, то структура никуда не годится.
К примеру, количество не должно храниться в таблице предметов (товаров), а должно быть на месте хранения.
Там же должно быть состояние предмета (статус). Рекомендую идентифицировать такие состояния, как: остаток, резерв, приход, кредит...
Ну и т.д. и т.п.

P.S. Все мои скромные рассуждения базируются на более чем 25-летнем опыте разработки и эксплуатации (по сей день)
подобных систем учета...

К сожалению не обладаю таким долгим опытом, поэтому прошу пояснить:

1. В моем случае есть общее количество товара на складе - скажем остаток, а есть количество которое приходит - уходит со склада - определенного товара. Соответственно в приложении будет грид который отображает общую картину, а если работнику склада - нужно посмотреть историю(хронологию) поступлений он будет запрашивать значение из другой таблице - во второй грид - и смотреть что происходило до этого.
2. Идентифицировать - это завести отдельную таблицу с идентификатором?

Old NickВот тут почитай.
Прочитал.

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

Вот что получилось:


Советы и критика приветствуется.

Old NickОстатки не по складу и не по товару, а по товару и по складу одновременно.

Не надо хранить остатки. Их нужно вычислять по таблице приходов/расходов. Хранить предварительно посчитанные остатки нужно только при очень больших объемах, от миллиарда записей.

Я не вижу таблицы приходов/расходов (регистра то есть)

авторwarehouses: место хранения товара -> поле status-осотояние -> сюда будет заноситься - (приход, расход)

Или нужно заводить отдельную таблицу или хранить в другой таблице?

Станислав С...кийDr.Hofmannпропущено...

этого я не совсем понял.
Советы и критика приветствуется.
остатки должны быть не просто по складу, а по товару (возможно, с учетом партии, цвета и др. "аналитики") на складе.
Это больше напоминает бухучет: для каждой аналитики заводите тетрадный лист и делите его на две колонки. Слева записываете приход, а справа - расход. В определенное время (например, в конце месяца) подводите итог - сальдо (остаток товара на дату).
Чтобы в следующую инвентаризацию не считать все приходно-расходные операции от "сотворения мира" Вы используете рассчитанные ранее сальдо (входящие остатки)...
Записи по приходам-расходам на листочке = таблица движения
Записи по остаткам = таблица остатков....
Как-то так...
ясно

авторОстатки не по складу и не по товару, а по товару и по складу одновременно.

Не надо хранить остатки. Их нужно вычислять по таблице приходов/расходов. Хранить предварительно посчитанные остатки нужно только при очень больших объемах, от миллиарда записей.

Я не вижу таблицы приходов/расходов (регистра то есть)


Добавил:

ой й-ой
Стрелку одну не нарисовал - между products и junction_tb.

авторколичество не должно храниться в таблице предметов (товаров),

авторWareID int, -- Товар

Это не противоречит сказанному?

Old NickDr.Hofmann,

А где тут таблица товаров?

сори - ошибся,

вот переделаная схема:


критика приветствуется.

АнатоЛойDr.Hofmann, резервирование есть, снятия с резерва нет.
ок, добавим.