Aeq
А если у нас 1 тысяча или 10 тысяч наименований?
_____________
Gear Framework
Gear Framework на Github
Полная Версия: Связи между таблицами
Aeq Ты фто??? 
Бить нещадно по рукам за такое!
Его ж потом никто на работу не возьмет. Ну, разве какой Раджа из Делли...
Ну, а чтобы тебе не очень обидно было, то попробуй теперь реализовать корзину.
Как будешь добавлять и цветную бумагу и пылесос в один заказ?
// вариант "Сделать еще одно поле, которое будет содержать имя таблицы" НЕ ПРЕДЛАГАТЬ, а то и Раджа не возьмет
_____________
[продано копирайтерам]
Бить нещадно по рукам за такое!Его ж потом никто на работу не возьмет. Ну, разве какой Раджа из Делли...
Ну, а чтобы тебе не очень обидно было, то попробуй теперь реализовать корзину.
Как будешь добавлять и цветную бумагу и пылесос в один заказ?
// вариант "Сделать еще одно поле, которое будет содержать имя таблицы" НЕ ПРЕДЛАГАТЬ, а то и Раджа не возьмет
_____________
[продано копирайтерам]
Мало того, как потом поиск по товарам производить? Это же сколько таблиц джойнить надо и какие условия задавать?
_____________
Gear Framework
Gear Framework на Github
_____________
Gear Framework
Gear Framework на Github
Вы ребята странные. Объясняю по-порядку:
1. Если атрибутов реально много: сотни, тысячи, то тогда есть смысл смотреть в EAV
2. В корзину вы складываете "товар", т.е. то что в табличке item, в которой только основные свойства товаров. И никаких проблем тут не наблюдается.
Дополнительные таблички хранят дополнительные атрибуты + ссылку на основную таблицу item с основными атрибутами. Мне показалось что из моего примера это явно видно, т.к. я прописал у доп.таблиц поле item_id
3. Поиск. Очевидно, что если ведется поиск цветной бумаги по ее цвету, поиск будет быстрее по таблице paper в которой к примеру 100 тыщ строк, чем по одной общей таблице товаров в которой к примеру 1 млн строк, и тем более быстрее чем поиск по вашей табличке product_property в которой будет > 1 млн. строк т.к. у каждого из 1 млн товаров еще по несколько пропертей.
Общий поиск может вестись только по общим полям ширина/высота, и спокойно делается по табличке item.
Поиск цветной бумаги по цвету + полям из основной таблички будет производиться всего одним джоином paper join item on (paper.item_id=item.id)
В противовес, сами подумайте сколько понадобится джоинов чтоб в вашем варианте с EAV и табличкой product_property сделать поиск по трем атрибутам: высота + ширина + цвет. Вам придется product_property (в которой более млн строк) джойнить саму на себя 2 раза, а если поиск по 4м пропертям, то 3 раза, и т.д.
1. Если атрибутов реально много: сотни, тысячи, то тогда есть смысл смотреть в EAV
2. В корзину вы складываете "товар", т.е. то что в табличке item, в которой только основные свойства товаров. И никаких проблем тут не наблюдается.
Дополнительные таблички хранят дополнительные атрибуты + ссылку на основную таблицу item с основными атрибутами. Мне показалось что из моего примера это явно видно, т.к. я прописал у доп.таблиц поле item_id
3. Поиск. Очевидно, что если ведется поиск цветной бумаги по ее цвету, поиск будет быстрее по таблице paper в которой к примеру 100 тыщ строк, чем по одной общей таблице товаров в которой к примеру 1 млн строк, и тем более быстрее чем поиск по вашей табличке product_property в которой будет > 1 млн. строк т.к. у каждого из 1 млн товаров еще по несколько пропертей.
Общий поиск может вестись только по общим полям ширина/высота, и спокойно делается по табличке item.
Поиск цветной бумаги по цвету + полям из основной таблички будет производиться всего одним джоином paper join item on (paper.item_id=item.id)
В противовес, сами подумайте сколько понадобится джоинов чтоб в вашем варианте с EAV и табличкой product_property сделать поиск по трем атрибутам: высота + ширина + цвет. Вам придется product_property (в которой более млн строк) джойнить саму на себя 2 раза, а если поиск по 4м пропертям, то 3 раза, и т.д.
Aeq, в чём-то вы правы, но на право и на лево плодить таблицы тоже не вариант, хотя и у меня была такая мысль, сделать таблицы под отдельные группы свойств.
Но как ни крути, то что я предложил в начале более универсально, хотя и придётся писать более детализованные запросы, но это плата за универсальность.
_____________
Стимулятор ~yoomoney - 41001303250491
Но как ни крути, то что я предложил в начале более универсально, хотя и придётся писать более детализованные запросы, но это плата за универсальность.
_____________
Стимулятор ~yoomoney - 41001303250491
| Цитата (Aeq @ 6.01.2014 - 16:39) |
| 3. Поиск. Очевидно, что если ведется поиск цветной бумаги по ее цвету, поиск будет быстрее по таблице paper в которой к примеру 100 тыщ строк, чем по одной общей таблице товаров в которой к примеру 1 млн строк, и тем более быстрее чем поиск по вашей табличке product_property в которой будет > 1 млн. строк т.к. у каждого из 1 млн товаров еще по несколько пропертей. |
В таких случаях средствами СУБД не ограничиваются.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
Aeq
Спорим, что я найду любой товар красного цвета быстрее, чем вы предлагаете? А спорим, что вы не сможете составить банальный SQL-запрос на выборку всех товаров со всеми их пропертями и их значениями?
_____________
Gear Framework
Gear Framework на Github
Спорим, что я найду любой товар красного цвета быстрее, чем вы предлагаете? А спорим, что вы не сможете составить банальный SQL-запрос на выборку всех товаров со всеми их пропертями и их значениями?
_____________
Gear Framework
Gear Framework на Github
linker
спорьте сколько хотите, но выбрать бумагу красного цвета очевидно быстрее в моем подходе. и не надо перефразировать то что я говорил, я говорил о выборке бумаги красного цвета, а не об абстрактном товаре красного цвета.
Ваш банальный запрос на выборку всего сразу на практике никогда не нужен. На странице всегда выводится ограниченное число товаров.
разные подходы имеют право на жизнь в разных ситуациях. тут уже говорили о том что нужно подробнее описать задачу чтоб было понятней каким подходом пользоваться.
я написал минусы EAV которые видны на поверхности, и даже они весьма серьезны (кол-во джоинов линейно зависит от кол-ва фильтров), чем глубже копаешь в EAV тем больше проблем всплывает. Целостность данных не поддерживается: я например могу бумаге добавить атрибут "мощность" и EAV это спокойно съест. Не вижу смысла продолжать описывать минусы, т.к. все легко гуглится. Настоятельно рекомендую изучить эти минусы, прежде чем заныривать в EAV, и по возможности, в зависимости от конкретной задачи, лучше выбирать другой подход ИМХО.
спорьте сколько хотите, но выбрать бумагу красного цвета очевидно быстрее в моем подходе. и не надо перефразировать то что я говорил, я говорил о выборке бумаги красного цвета, а не об абстрактном товаре красного цвета.
Ваш банальный запрос на выборку всего сразу на практике никогда не нужен. На странице всегда выводится ограниченное число товаров.
разные подходы имеют право на жизнь в разных ситуациях. тут уже говорили о том что нужно подробнее описать задачу чтоб было понятней каким подходом пользоваться.
я написал минусы EAV которые видны на поверхности, и даже они весьма серьезны (кол-во джоинов линейно зависит от кол-ва фильтров), чем глубже копаешь в EAV тем больше проблем всплывает. Целостность данных не поддерживается: я например могу бумаге добавить атрибут "мощность" и EAV это спокойно съест. Не вижу смысла продолжать описывать минусы, т.к. все легко гуглится. Настоятельно рекомендую изучить эти минусы, прежде чем заныривать в EAV, и по возможности, в зависимости от конкретной задачи, лучше выбирать другой подход ИМХО.
Aeq
Что вы к красной бумаге прицепились, я говорю вообще о продукте красного цвета, красным может быть не только бумага.
Нужен всегда, потому что на одной странице обычно располагаются товары из разных категорий с их основными пропертями, часть из которых общие, а часть индивидуальные.
Откройте любой магазин и вы офонареете от количества фильтров.
Не имеет смысла из банальщины городить огород таблиц.
Могу ещё предложить вариант из двух таблиц:
в табличку products добавляются новые поля, а описания этих полей добавляются в табличку properties
_____________
Gear Framework
Gear Framework на Github
Что вы к красной бумаге прицепились, я говорю вообще о продукте красного цвета, красным может быть не только бумага.
Нужен всегда, потому что на одной странице обычно располагаются товары из разных категорий с их основными пропертями, часть из которых общие, а часть индивидуальные.
Откройте любой магазин и вы офонареете от количества фильтров.
Не имеет смысла из банальщины городить огород таблиц.
Могу ещё предложить вариант из двух таблиц:
в табличку products добавляются новые поля, а описания этих полей добавляются в табличку properties
_____________
Gear Framework
Gear Framework на Github
Здесь расположена полная версия этой страницы.