@aalexander

Здравствуйте, форумчане. Просьба помочь с проектированием.

Назрели следующие вопросы:

1) Как может выглядеть таблица "Склад", если её нужно связать с таблицей "Поставки" и "Товары"? Одна компания-поставщик по идее должна иметь возможность поставлять несколько типов товаров.
2) Правильно ли я организовал связь "многие ко многим" в таблице "Заказ"? Конечная цель, которую хотелось достичь - чтобы пользователь мог заказать несколько товаров.

Текущую схему прилагаю на скрине.
Замечания по остальным таблицам приветствуются

Миниатюры

 

0

@qwertehok

а если один товар возят 2 конторы по разным ценам?

Добавлено через 2 минуты
а если в компании поменяются какие-либо данные, а вы захотите распечатать старый документ, то у вас подставятся новые данные

Добавлено через 4 минуты
по складу не забудьте таблицу остатков

1

@Hikari

А как такое может быть?
На этот случай ведется база сформированных документов. В любом случае старые уже оформленные документы не могут быть в движении товара, поэтому их просто нет смысла хранить в БД, либо же отсекать такие документы периодами проводок.
Однако все же соглашусь - В таблице компаний стоит добавить два поля: Дата регистрации компании и дата закрытия записи о компании. И если реквизиты обновились - создавать новую запись, а старую закрывать записью даты закрытия.

И еще мне не нравятся таблицы Доставки и заявки.
Я бы их объединила в одну потребительскую корзину. Тогда бы и таблица заказов не нужна была бы.

Добавлено через 41 секунду
А вот это будет ужасный просчет. Остатки ни в коем случае хранить нельзя.
Только вычислять на основании периодов.

1

@qwertehok

что значит как?
допустим вы покупаете товар ХХ по 500 штук в неделю, ваш продавец говорит: "извини на этой неделе только 450 - остальные утонули в песках сахары".
ты ищешь нового и покупаешь на 10% дороже

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

конечно их нет в БД, просто вместо поля ИНН\Телефон и прочее нужен справочник
и когда нам нужно сделать отчет берется дата документа и берутся нужные данные из справочников

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

другое дело что тогда нужно будет запрещать редактирование документов в старых периодах, иначе эти остатки будут некорректны

1

@Hikari

И много складов, которые на такое нарушение пойдут себе в убыток?
Я просто частенько сталкиваюсь с торговыми точками (делаем и сопровождаем для них ПО), и хорошо знаю как склады работают. И впервые слышу чтоб фирма так просто взяла и часть товара переключила с другого поставщика.
Да и ее бухгалтеры от такого повесятся.
Хорошо, как скажешь. Но ты сам обозначил основную проблему:
Однако это только верхушка айсберга )
Не буду вдаваться в подробности, просто скажу из своего 6-летнего опыта: Остатки хранить в виде живых цифр - злейшее зло для кладовщика. И с тем, как остатки между периодами рвутся, наша техподдержка сталкивается чуть ли не ежемесячно в тех ПО, которые та делают.

1

@qwertehok

при чем тут склады?
покупатель покупает по той цене что сможет купить.
даже не знаю какой пример привести. их же море

конечно, но на каждую проблему есть бизнес процесс

инвентаризации?

у ТС вроде учебное ПО, а мы с вами полезли в дебри ))

про НДС не будем рассказывать ТС?

1

@aalexander

Спасибо за советы насчёт потребительской корзины! Но всё же, может вам есть что сказать по тем двум вопросам, которые меня заботят?

p.s. насчёт учебного ПО qwertehok прав) можно отнестись проще к вопросу, однако если в проектировании допущены вопиющие ошибки, то жду ещё замечаний)

0

@qwertehok

вы придумали все таблицы и теперь не можете придумать "Склад"?

что делает склад - хранит
значит:
код_товара
код_поставщика
количество

если у вас планируется хранение по местам, то нужны еще размеры

ну так представьте себе документ "Заказ"

1

@aalexander

вчера под вечер уже голова не варила. да и в теории я уже много чего подзабыл, поэтому возникли трудности.

я думал о таком варианте, но скорее всего, придётся иметь как минимум парочку складов

0

@qwertehok

тогда добавьте еще код_группы - что бы товары хранить товары одной группы


ЗЫ не будете же вы хранить рыбу и чай на одном складе

1

@aalexander

Товар будет только трёх видов - холодильники, ноутбуки, моб. телефоны. Можно хранить и в одном месте всё, но преподаватель говорил, что нужно иметь несколько складов. тогда опять нужно делать "многие-ко-многим" через 3-ю таблицу?

хотя, думаю, стоит поговорить с ним насчёт одного.

0

@qwertehok

тогда при приеме нужно указывать склад куда это будет поступать

а при расходе - указывать откуда. Тут надо учесть что всего может быть 10 холодильников, но на 1 складе 7, а 3 на втором.
тогда при расхода нужно делать 2 документа - по 1 на склад

1

@aalexander

чуть позже закину исправленную схему, постараюсь учесть пожелания. может ещё вопросы возникнут)

спасибо всем

0

@Hikari

Переоценки, пересортицы, возвраты... Много факторов.
Так то да, но если топикстартер хочет научиться делать хорошее качественное и востребованное ПО - лучше начинать заранее вникать в смысл проектирования. И изучать область более плотно.
Какие именно?
Я уже выразила мнение, что у тебя лишние сушности.
Упразднив их твои два вопроса отпадут сами собой.
Не потребуется делать M:M связь.
Вопрос по поставке товаров тоже отпадет. У каждого товара есть номенклатурный код. Ничего не мешает проводить накладные с разным ассортиментом товара в них.
Главное тут - структуру оптимальнее сотворить.

1

@aalexander

Вот что вышло на данный момент. Надеюсь, это не хуже, чем было

Что можете сказать?

1) может показаться странным наличие двух идентичных таблиц "Склад" и "Поставки". Предполагаю так - мы поставляем что-то от кого-то столько-то и, когда запись в таблице "Поставки" появляется, то мы обновляем количество этого товара в таблице "Склад".
2) объединил 2 таблицы в "Потребительскую корзину". Так, чтобы один человек мог купить несколько товаров, это должно выглядеть так примерно (во втором столбике 1 - это код одного и того же покупателя)?

1 1 2 1 10.10.2016 Иванов
2 1 3 1 10.10.2016 Петров

Или я снова намудрил?

0

@aalexander

Схема:

Миниатюры

 

0

@Hikari

1) Не очень понимаю почему поставщики не связаны с справочником товаров
2) Сушности "Поставки" и "Склад" можно упразднить, если считать потребительскую корзину единственным местом проводок, а склад как часть поставщика. Все равно склад таковым для торговых точек является. Но это если захочется оптимизации базы. Мы собственно так и делаем.

Т.е.
Сушности: Корзина, Поставщик, Получатель, Ассортимент товаров.
Все остальные кроме пожалуй счетов\договоров как по мне лишние.
Все проводки и движение товара вполне вместит в себя корзина, если (повторюсь) посчитать склады как Получателя.
Группы товаров... Я понимаю для чего тебе это, но как по мне для учебной задачи морочно. Я бы в общем товар не группировала, хотя...

0

@aalexander

ну вроде в "Складе" можем смотреть, кто поставил этот товар...

Если я правильно понял вашу мысль, то так не подойдёт. Тут склад как бы местный, магазинный, а не склад компании-поставщика. Надо будет организовать что-то типа выгрузки на местный склад. Я это планирую сделать просто увеличением количества конкретного товара на "Складе", когда имеем новую поставку этого товара.

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

0

@Hikari

Да без разницы. Значит сам магазин выступает складом - еще проще. Нет складской базы, которая раздает магазинам товар. Но все равно твой магазин можно записать в Получатели и без сушности Склада.
Обычно это делают записью в БД приходно-расходного ордера (он же "Накладная").
Для этого у тебя потребительска корзинка есть. Говорю же - в качестве потребителя может выступать и твой магазин.
Разницы между магазином и покупателем практически нет - и там и там требуется одинаковая фиксация движения товара, только тип накладных различается: У Магазина это расходный ордер, а у покупателя - приходный (он же: Чек за покупку)
Логично, но морочно. Например Ноутбук и Холодильник должны быть в разных группах по назначению товара, но в одной по некоторым характеристикам. Например и то и другое - электроприбор. Получается они должны присутствовать в двух группах. Поэтому я и говорю: Это морока. Тут нужно семь раз подумать, а стоит ли навешивать на ПО такие утяжеления? Как часто и важно будет получение группировки товаров? В общем этот тот еще вопрос. Ближе к технологии торговли чем к программированию, и далеко не так просто (это из своей практики говорю).

1