Раскритикуете логику моей БД Склада для MySQL (скрины и модель MySQLWrkBnch под катом)?

Question

[Gudsaf]

Модель на скриншоте:


Модель для тех кто хочет пощупать в MySQLWorkbench:
редирект на киберфорум

Таблицы user и rule будут использоваться для разграничения доступа.
Вообще планирую написать клиент на c# vs forms.

Answer 1

[Gudsaf]

Зелим Бельтоев: выбрал второй подход, он рационален. Задумался про единую таблицу для накладных. У меня их два типа - приходная и требование-накладная. Оба вида накладных имеют следующие общие атрибуты:
- ID_рабочего: кто оформил накладную
- ID_единицы: на каком складе оформили накладную
- ID_типа: приходная/накладная требование
- ID_партии: количество и вид товара отпускаемого/расходуемого товара

И тут есть тоже проблемы в логике.
По рабочему и единице можно в лёгкую определить в:
- приходной накладной, куда пришёл товар
- требовании-накладной, откуда ушёл товар
Сейчас всё выглядит так (кликабельно):


Что если надо в:
- приходной накладной, ОТКУДА пришёл товар
- требовании-накладной, КУДА ушёл товар?

Я пока вижу решение проблемы в следующем: в таблице "Накладная" убрать поле ID_Единицы (оно наследуется с таблицы Рабочий), добавить два поля ID_откуда, ID_куда - эти два новых поля привязать к таблице Административная единица. Вроде ок, но двойные связи ещё не делал не разу, да и опять, колхоз какой-то, у меня даже на попытке это воплотить в реальность воркбенч упал

Comments

[Зелимхан Бельтоев]

> добавить два поля ID_откуда, ID_куда

Вполне логично, двойные связи ничем не отличаются от обычных

Answer 2

[Зелимхан Бельтоев]

Из того, что бросается в глаза:

1. Таблица "rule" - что будете делать, когда появятся новые привилегии? Например, "write_employee". Добавлять новый столбец?
Намного логичнее будет разбить на две таблицы:

rules (id, rule, description)
user_rules (user_id, rule_id)

Таким образом, избавляемся от переизбыточности и нормализуем БД: храним только те привилегии, которые есть у тех или иных пользователей. К тому же, появляется возможность добавления/удаления новых привилегий внутри приложения (правда, нужно учесть привязку прав к тем или иным действиям).

2. Не уловил, зачем в goods_receipt поле product_name, если оно есть в таблице product (опять-таки переизбыточность). Поле price как-то спорно: с одной стороны, тоже дублируем, с другой - стоимость может меняться. Как вариант, можно завести отдельную таблицу для отслеживания изменения цен (в product поле price убрать):

product_prices (id, product_id, price, date_start, date_end (NULL))

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

3. shop и warehouse аналогичны (кстати, что есть поле size?). Можно их заменить двумя другими таблицами:

building (id, name, address, phone, type_id)
building_types (id, name)

То есть, таблицы сооружения и типы сооружений (склад, магазин, ларёк, что-то ещё).

4. Если все склады и магазины расположены в одном городе, то address можно и так оставить. Иначе можно разбить на подтаблицы (город, регион и т. д.)

5. Очень много полей в разных таблицах повторяются (price, phone, address) - возможно, можно как-то сузить это

А в целом, вам нужно про нормализацию почитать

Comments

[Gudsaf]

Поле size - размер склада, объём хранения (возможно будет рассчитываться как сумма размера стеллажей, которая в свою очередь будет рассчитываться как сумма ячеек. В такой логике, можно убрать это поле.

Логику цены так же порезал - я занимаюсь складом, цена это дело финансового отдела и магазинов. Соответственно мы знаем только про товар и его название. Так же, мы можем взять как склад апельсины по 30 рублей и по 35 рублей. Отчёт о закупке будет отправлен в фин отдел, через таблицу operations->goods_receipt, где можно будет узнать какого продукта по какой цене мы взяли, опираясь на таблицу lot будут происходить авторасчёты закупки сервером (там же есть цена партии, вот её и использую для этого).

Добавил кое-какое разграничение по городам.

Добавил типы зданий.

Проверьте ещё раз на логику, буду очень благодарен.

И да, какой тип данных лучше использовать для полей:
- price
- phone?

[Зелимхан Бельтоев]

Gudsaf: Начну с конца:
1. phone - целые числа, price - с плавающей запятой (цены редко бывают 30 или 35 рублей - обычно 30.5 или 35.99 - это для примера).

2. rules - всё-таки добавьте поле rule или name, чтобы можно было добавлять записи так: name = "write_users", description = "Разрешение на редактирование пользователей".

3. Что будет, если в одном здании будет и магазин, и склад? Или сразу несколько магазинов? У вас появится несколько идентичных записей в address, которые будут различаться только номером телефона. Или такие варианты исключены?

4. Таблице product, скорее всего, нужно поле артикул, чтобы уникально идентифицировать товары. Например, сможем провести анализ, сколько апельсинов поступало на склад и каковы были их мин. и макс. стоимости.

5. Так как мы у складов "вырезали" поле size, можно добавить отдельную таблицу building_sizes, чтобы указывать, есть ли в том или ином помещении ячейки для хранения.

6. Не думали о том, что поставщик - то же здание/помещение, для которого не обязательна лишняя таблица? Достаточно добавить в building_types запись с именем "Поставщик". Ну, а employee привязывать к таким зданиям (может у магазина или склада будет несколько ответственных людей, которых тоже можно было бы учитывать).

7. Если системой будет пользоваться несколько пользователей (а таблица users на это намекает), то я бы к каждой операции, которые проводит пользователь, привязывал и id пользователя, чтобы, в случае чего, можно было найти виновника несостыковок.

В остальном, все рекомендации выше, с одной стороны, позволяют нормализовать БД и избавиться от лишних сущностей, а с другой стороны - местами усложняют запросы, которые придется написать для различных выборок. Так что лучше делайте так, как удобнее вам =)