Выбор связей таблиц

@TopolM · Регистрация: 31.03.2013

Студворк — интернет-сервис помощи студентам

Всем доброго времени суток.
Столкнулся с дилеммой, затрудняюсь в выборе связей сущностей:
Имею сущности: Корзина_заказы, продукция (решил эту сущность разделить на составные сущности, т.к. их атрибуты уж очень разношёрстные : мотоциклы, детали, одежда…); Составил 2 модели связей, ну они мне не особо нравятся:
1) Потому что будет иметь много атрибутов товаров (товаров будет больше чем приведено);
2) Не понравилась, потому что усложняет написания SQL запросов к определению товара по заказу ( придётся использовать скорее всего динамический SQL);
Ну и собственно главный вопрос, может, есть какой-нибудь 3 вариант решения задачи? Если нету 3 варианта какой более предпочтительнее вариант выбрать?

Заранее благодарю всех за подсказки.

@MLPMan · 05.02.2014, 16:22

Мне нравится первое(когда для каждого своя таблица). Еще можно хранить все товары в одной таблице, и каждый раз добавлять столбцы для новых категорий. (и там многие будут null). Но так будет изменчивая схема, могут быть сложности с использованием DAO. Еще есть EAV-паттерн.

Добавлено через 12 минут

Не по теме:

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

Для реляционных, как я понял, традиционным все-таки является entity-attribute-value подход.

@TopolM · 05.02.2014, 22:44 **[ТС]**

Сообщение от MLPMan

Мне нравится первое(когда для каждого своя таблица). Еще можно хранить все товары в одной таблице, и каждый раз добавлять столбцы для новых категорий. (и там многие будут null). Но так будет изменчивая схема, могут быть сложности с использованием DAO. Еще есть EAV-паттерн.

Добавлено через 12 минут

Не по теме:

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

Для реляционных, как я понял, традиционным все-таки является entity-attribute-value подход.

Спасибо за ответ пока я задумываюсь тоже на 1 вариантом, он как-то понятнее..

Насчёт вашего сообщения: "При первом подходе я бы не заводил поле для каждого вида товара, а сделал сущность "товар", у которой была бы ссылка на "тип товара" со строковым полем - названием таблицы, где будут свойства." - это разве не аналогично 2 предложенному варианту?

Новые блоги и статьи Все статьи Все блоги /
Использование SDL3-callbacks вместо функции main() на Android, Desktop и WebAssembly 8Observer8 24.01.2026 Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а привычная функция main(). . .	моя боль iceja 24.01.2026 Выложила интерполяцию кубическими сплайнами www. iceja. net REST сервисы временно не работают, только через Web. Написала за 56 рабочих часов этот сайт с нуля. При помощи perplexity. ai PRO , при. . .	Модель сукцессии микоризы anaschu 24.01.2026 Решили писать научную статью с неким РОманом	http://iceja.net/ математические сервисы iceja 20.01.2026 Обновила свой сайт http:/ / iceja. net/ , приделала Fast Fourier Transform экстраполяцию сигналов. Однако предсказывает далеко не каждый сигнал (см ограничения http:/ / iceja. net/ fourier/ docs ). Также. . .
http://iceja.net/ сервер решения полиномов iceja 18.01.2026 Выкатила http:/ / iceja. net/ сервер решения полиномов (находит действительные корни полиномов методом Штурма). На сайте документация по API, но скажу прямо VPS слабенький и 200 000 полиномов. . .	Расчёт переходных процессов в цепи постоянного тока igorrr37 16.01.2026 / * Дана цепь(не выше 3-го порядка) постоянного тока с элементами R, L, C, k(ключ), U, E, J. Программа находит переходные токи и напряжения на элементах схемы классическим методом(1 и 2 з-ны. . .	Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/

@TopolM 13 / 13 / 2 Регистрация: 31.03.2013 Сообщений: 107

	Выбор связей таблиц 05.02.2014, 13:57. Показов 842. Ответов 2 Метки нет (Все метки) Всем доброго времени суток. Столкнулся с дилеммой, затрудняюсь в выборе связей сущностей: Имею сущности: Корзина_заказы, продукция (решил эту сущность разделить на составные сущности, т.к. их атрибуты уж очень разношёрстные : мотоциклы, детали, одежда…); Составил 2 модели связей, ну они мне не особо нравятся: 1) Потому что будет иметь много атрибутов товаров (товаров будет больше чем приведено); 2) Не понравилась, потому что усложняет написания SQL запросов к определению товара по заказу ( придётся использовать скорее всего динамический SQL); Ну и собственно главный вопрос, может, есть какой-нибудь 3 вариант решения задачи? Если нету 3 варианта какой более предпочтительнее вариант выбрать? Заранее благодарю всех за подсказки. Миниатюры 0

@MLPMan Кандёхаем веселее! 296 / 330 / 76 Регистрация: 02.10.2012 Сообщений: 2,175
	05.02.2014, 16:22
	Мне нравится первое(когда для каждого своя таблица). Еще можно хранить все товары в одной таблице, и каждый раз добавлять столбцы для новых категорий. (и там многие будут null). Но так будет изменчивая схема, могут быть сложности с использованием DAO. Еще есть EAV-паттерн. Добавлено через 12 минут Не по теме: При первом подходе я бы не заводил поле для каждого вида товара, а сделал сущность "товар", у которой была бы ссылка на "тип товара" со строковым полем - названием таблицы, где будут свойства. Для реляционных, как я понял, традиционным все-таки является entity-attribute-value подход. 1