Помоги анону с курсачом.Аноны, посмотрите, нормальная структура для базы данных интернет-магазина по продаже техники?
Бамп
>>124503269 (OP)Не понял, что за сущность "Товар-Заказ"? в чём её смысл?
>>124503746Ну, для связки.
>>124503269 (OP)ЗП можно и не указывать здесь. Она в базе храниться то будет, и ещё много всякой херни по сотрудникам, но конкретно для учёта товара она не имеет смысла. Можно убрать, сказать, что она в БД храниться, но для учёта товара используется представление (VIEW)
>>124503746для связки таблиц «Заказы» и «Товары», просмотра кода товара, кода его заказа и количества данного товара заказанное клиентом.
>>124504107Ну хз, может вас так учили. Я не понял, для какой ещё связки. Я бы сделал просто связь между товарами и заказам МНОГО-МНОГО.И в товары ещё неплохо бы добавить "количество на складе"
>>124504241код товара, (артикул кажется это называется, а может нет). код товара ты можешь хранить в заказе, что клиент заказал, количество тоже
Блять, а нормализация где?
>>124504409>Я бы сделал просто связь между товарами и заказам МНОГО-МНОГООтчислен. МНОГО-МНОГО не существует дальше логической модели.>>124506401А хули там нормализовать, на интуиции явно уже в 5 наебашено.
>>124503269 (OP)Не тянет на курсач, маловато таблиц. Неужели у тебя такое нераспространенное техническое задание?
>>124503269 (OP)Ах, да, называть таблицы множественным числом - моветон.
>>124508354Начнем с того что они на русском
>>124508602Как вообще можно строить модели без куриных лапок?
Вместо Заказы и Товар-заказ бы сделал Заказ Заголовок и Заказ Строка. Заказ Заголовок - ключ: Код; Заказ Строка - ключ: Код Заказа, Номер Строки.Во всяком случае такая бизнес логика используется в ЕРП системах.В Заказ Строка неплохо бы добавить поля Стоимость, Скидка %.А так же создать еще две таблицы, Учтенный Заказ, Учтенный Заказ Строка, куда будут переходить заказы после их учёта. На этом можно строить хотя бы базовую фин. отчетность, хотя по хорошему нужен ряд отдельных таблиц, где будут отображаться все финансовые проводки, счета, движение товаров, и так далее (G/L Entry, Value Entry, Item Ledger Entry, VAT Entry и т.д.)Использовать Заказ и Заказ Строка для учтенных заказов, хоть и соблазнительно (можно всего лишь добавить поле Учтен), но в итоге непрактично, т.к. когда учтенных заказов будут хулиарды, система начнет подлагивать, а клиент должен создавать новый заказ быстро и без задержек.мимокрокодил navision-кун
>>124510397Не уровень полушкольного проекта, прекращай.
>>124503269 (OP)ФИО одним полем.
>>124511138why? поменять две таблицы, добавить еще две (по сути, копирующие две измененные), добавить пару полей. сложно?
>>124511258Атомарненько.
>>124511363Логика не та, хуй знает, как по-другому объяснить. От него не этого, вероятно, хотели.
Клиенты и сотрудники - это пользователи. Они отличаются ничем.
>>124516696Клиент и сотрудник это две принципиально разные сущности.
>>124518834У тебя маня-мирок, или таки боевой пример?
>>124519104Если таки маня-мирок, то на той же джанге, к примеру, клиенты и сотрудники и даже админы сайта - один хуй. И я таки не понимаю, зачем плодить.
>>124519104операции с сотрудником это в основном: формирование табелей, расчет заработной платы, отчетность, разграничение прав доступа в систему (дворник не может провести заказ продажи, обычный продавец не может установить большую скидку, и т.д.), т.е. в основном HR, Payroll, Access Managementоперации с клиентом: расчет стоимости товара (группы клиентов, юр. лица, физ. лица, НДС, вот это всё), логистика (почтовые индексы, доставка, формирование путевых листов), и, самое громоздкое - финансовая история всех операций по каждому конкретному клиенту: 1. для формирования налоговой отчетности, 2. для формирования стратегии дальнейшего развития бизнеса - статистика продаж в разрезе клиентов, в разрезе городов в которых проживают клиенты, и т.д.я привел далеко не полный список возможных операций, но достаточный для того чтобы было понятно, что у этих операций нет ничего общего. в серьезных системах это огромные куски функционала, которые оперируют огромными объемами данных. если ты будешь скупиться на таблицы для разделения сущностей, очень скоро узнаешь что такое блокировки, deadlocks, и прочая поебень, характерная для плохо продуманной структуры данных.navision-кун
>>124503269 (OP)1. можешь сделать такую же картинку, только с типами колонок?2. какие сценарии должны работать с этой схемой? я вижу только "продажную" часть: т.е. товар собрался в заказ и куда-то ушел. откуда товар берется, где "склад"? можно ли по этой базе понять сколько у тебя сейчас бабла зависло в непроданном товаре?
>>124522091> в серьезных системах это огромные куски функционала, которые оперируют огромными объемами данных. если ты будешь скупиться на таблицы для разделения сущностей, очень скоро узнаешь что такое блокировки, deadlocks, и прочая поебень, характерная для плохо продуманной структуры данных.проекту уровня курсовой эти проблемы по барабану. sql antipatterns почитает, там ему расскажут что и как. до того момента как его инфраструктура упрется в lock contention в базе эту систему и так надо будет переписать с нуля три раза.
>>124523638этому проекту по барабану, да. но лучше привыкать писать качественно заранее. потом сложно переучиваться.
>>124524314ты же понимаешь, что если в дедлайн не укладывается, то надо урезать функционал. а апрель уже заканчивается.
>>124507949>Отчислен. МНОГО-МНОГО не существует дальше логической модели.Топкекус.
>>124503746Блядь, для связи многие-ко-многим используется промежуточная таблица. Ты вообще не шаришь в БД?
>>124524977 бд реляционная ведь.
>>124511258Понимаешь что атомарность, в даном случае абстракция? Если из фио никогда не придется извлекать отдельные части имени, то почему поле нельзя назвать атомарным?
>>124530026атомарное поле, только не это.
>>124503269 (OP)Я б добавил справочников для должности сотрудника, статусов заказов итд. Ну и для реальной БД магазина было бы неплохо, чтобы записи хранились с историей (как минимум - с признаком актуальности, а лучше - с датами). Но так в целом ничего
