powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / EAV или Create table для фиксированных наборов значений атрибутов?
46 сообщений из 46, показаны все 2 страниц
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942906
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всех приветствую.

Для БД универсального скрипта интернет-магазина был выбран паттерн Flate table. Т.е. значения товаров будут храниться не в одной таблице EAV, а для каждого типа товара будет создаваться таблица.

В таблицах типов будет много значений которые лучше куда-то отделить в "фиксированные наборы значений". Т.е. например "цвет", "текстура", "материал". Писать миллион раз в каждой записи "красный","желтый",... "пластмасса"... - вот от этого нужно избавиться. Вместо этого, естественно, будут id значений. И здесь, опять приходим к EAV vs Create table =)))
Итак, нужно определиться где хранить "фиксированные наборы значений", наподобие значений цветов, значений материалов. В одной таблице? Или для каждого атрибута создавать по таблице?

1.EAV. По идеи он так и просится сюда. Действительно, нам советуют EAV, тогда когда кол-во атрибутов велико, а количество записей не велико. Если делать таблицами - то они будут содержать мало записей. Недостатки EAV я думаю итак известны - это скорость, и сложность 3-хэтажных запросов. Но... Для меня как для человека учившегося на мат.факе, EAV, в первую очередь, не симпатичен тем, что коверкает самую основную идеологию РБД - relation, "отношения". Все последующее строение будет "оторвано" от математики. Не я не фанат) и тоже за практичные решения) Просто мое сугубо индивидуальное мнение, EAV целесообразен: Если 1)Атрибуты очень динамичны (каждые неск-ко часов и даже каждые 10мин, они изменяются/добавляются/удаляются) И ПРИ ЭТОМ 2)Кол-во записей таблиц(у которых меняется структура) очень велико (>1млн. записей). При одновременном выполнении этих условий - без EAV просто никак. Каждое изменение (ALTER TABLE) будет блокировать базу, и будет выполнятся очень долго.

2.Flate table. Насколько я понимаю, непосредственно кол-во таблиц в БД не значительно влияют на скорость. Встает лишь вопрос удобства. Но ведь ничего не мешает таблицам прилепить префикс "z_"/"zz_" и все они будут отображаться в конце БД. Хоть их там тыща - растут себе вниз БД да и все. А имена их заданы по строгому формату "zz_"."type_value_"."{atribute_name}"

Вообщем хочу услышать ваши мнения, приветствуются ЛЮБЫЕ рассуждения=)))
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942909
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anchorнужно определиться где хранить "фиксированные наборы значений", наподобие
значений цветов, значений материалов. В одной таблице? Или для каждого атрибута создавать
по таблице?
Конечно же для каждого создавать по таблице. Это же совершенно разные вещи: справочник
цветов, справочник материалов (а у материалов есть и свои характеристики) и т.д.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942923
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anchor При одновременном выполнении этих условий - без EAV просто никакЛегко. Запихиваете свой сложный объект с переменной структурой, как есть в блоб, xml, json и т.д.

Anchor Но ведь ничего не мешает таблицам прилепить префикс "z_"/"zz_" и все они будут отображаться в конце БД. Хоть их там тыща - растут себе вниз БД да и все.Идею с префиксом не понял.

Anchor А имена их заданы по строгому формату "zz_"."type_value_"."{atribute_name}"
Имена таблиц или полей?

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

Поэтому для обучения начинать надо с банальных простых линейных ER диаграмм,
а для работы надо начинать с анализа имеющегося на рынке софта
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942925
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anchor Действительно, нам советуют EAV, тогда когда кол-во атрибутов велико, а количество записей не велико.
Это советуют какие-то странные люди. Количество атрибутов само по себе - совсем не причина использовать EAV (другой вопрос, что если при анализе получаются тысячи и десятки тысяч атрибутов сущности - скорее всего выделение сущностей проведено неправильно ;))
EAV советуют тогда, когда кол-во атрибутов неизвестно и может активно меняться пользователями в процессе работы системы.

В Вашем случае вообще речь идет не о EAV, а об "универсальном справочнике" - но и он для Ваших условий малоосмысленен.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942930
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257Anchor А имена их заданы по строгому формату "zz_"."type_value_"."{atribute_name}"
Имена таблиц или полей?
Имена таблиц

SERG1257Ваша проблема в слишком академическом подходе. На практике универсальный интернет - магазин будет торговать реальным (ограниченным) набором товаров, с реальными (ограниченным) набором свойств, которые будут менятся вовсе не по желанию левой пятки.
На этапе разработки универсального скрипта мы ж не знаем об конкретном наборе товаров=)) Естественно за универсальность придется платить. Усложнение кода, проблемы со скоростью. Это проблема всех универсальных решений.

SERG1257Anchor При одновременном выполнении этих условий - без EAV просто никакЛегко. Запихиваете свой сложный объект с переменной структурой, как есть в блоб, xml, json и т.д.
Я про это знаю конечно=) По этим атрибутам завтра понадобится сортировать, фильтровать, сделать гибкий поиск. Абстрагируемся, что зачем почему, в данном конкретном случае, задача именно универсальный скрипт, аля Prestashop, Virtuemart, etc.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942935
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry SibiryakovКонечно же для каждого создавать по таблице. Это же совершенно разные вещи: справочник
цветов, справочник материалов (а у материалов есть и свои характеристики) и т.д.

В EAV создают(как правило) по таблице на каждый тип данных. Т.е. eav_int, eav_varchar, ... Т.е. в этих нескольких таблицах все значения хранятся. Минус у flat table, в том, что таблиц может быть ОЧЕНЬ МНОГО, больше тысячи. Соответственно один из вопросов об этом нюансе, насколько критично, чем чревато огромное кол-во таблиц?
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942937
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Anchorв данном конкретном случае, задача именно универсальный коробочный скрипт, аля Prestashop, Virtuemart, etc.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942938
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anchor Имена таблицА нахрена? Чтобы не как у всех?

Anchor По этим атрибутам завтра понадобится сортировать, фильтровать, сделать гибкий поискВот когда все вышеизложенное потребуется, будет реализованно в коде, тогда этот атрибут никто не будет удалять, его один раз внесут в виде поля в таблице либо в виде индекса на XML, JSON (по сути тоже самое только средствами СУБД)

Anchor На этапе разработки универсального скрипта мы ж не знаем об конкретном наборе товаровА кто мешает узнать? Интерфейс вы тоже универсальным делаете?

Кто оплачивает ваше решение для сферического коня в вакууме?
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942946
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257Anchor Имена таблицА нахрена? Чтобы не как у всех?
С flat table все таблицы, образно говоря, разделим на два вида. Те, структуру которых нельзя менять из админки, только ниже уровнем. И те (с "динамичной" структурой) структуру которых может менять из админки контент-менеджер. Таблицы (назавем их так) с "динамичной структурой" будут иметь префикс "z_" . Таблиц может быть ОЧЕНЬ много. Поддерживать БД может оказаться неудобно. Префикс (вроде бы) ничего криминального не делает, при сортировке таблиц, в банальных БД Менеджерах(PMA, etc), все эти таблицы будут - внизу. Ну это я так вижу) Я поэтому и спрашиваю любые мнения))

SERG1257А кто мешает узнать? Интерфейс вы тоже универсальным делаете?
Once more=))) Пишется - универсальный, коробочный скрипт ИМ. Абстрагируйтесь кто что платит, кто что кушает/какает, кто на чем ездит=)))
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942947
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AnchorВ EAV создают(как правило) по таблице на каждый тип данных. Т.е. eav_int,
eav_varchar,
Не, это абсолютно идиотское решение. Запросы же превращаются в жуткий ужас.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942957
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry SibiryakovAnchorВ EAV создают(как правило) по таблице на каждый тип данных. Т.е. eav_int,
eav_varchar,
Не, это абсолютно идиотское решение. Запросы же превращаются в жуткий ужас.

Вот и мне этот подход не по душе. Этот подход(EAV) использует Magento(самый монструозный скрипт ИМ), скрипт ИМ-а Bitrix, скрипт ИМ-а Drupal(если не изменяет память) Просто в противном случае имеем - ОГРОМНОЕ кол-во таблиц. Я и спрашивал - насколько это критично, чем чревато?
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942961
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
То бишь вы хотите дать пользователю конструктор, чтобы пользователь сам себе скроил интернет-магазин. На выходе вашего тула будут команды типа create table, alter table и так далее...
Знаете, я очень плохо отношусь к EAV, но в данном случае порекомендую именно это, с EAV проект проедет дольше, прежде чем будет заброшен.

Anchor В EAV создают(как правило) по таблице на каждый тип данных. Т.е. eav_int,
eav_varchar,А почему не поля в таблице V?
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942963
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257То бишь вы хотите дать пользователю конструктор, чтобы пользователь сам себе скроил интернет-магазин. На выходе вашего тула будут команды типа create table, alter table и так далее...
Знаете, я очень плохо отношусь к EAV, но в данном случае порекомендую именно это, с EAV проект проедет дольше, прежде чем будет заброшен.

Понятно благодарю за мнение.

SERG1257Anchor В EAV создают(как правило) по таблице на каждый тип данных. Т.е. eav_int,
eav_varchar,А почему не поля в таблице V?
Делают так, потому что будет слишком много пустых ячеек. (ну поняли почему)
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942968
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anchor Делают так, потому что будет слишком много пустых ячеек.И кого это напрягает? Ваша СУБД не умеет эффективно хранить пустые значения?
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942973
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257Anchor Делают так, потому что будет слишком много пустых ячеек.И кого это напрягает? Ваша СУБД не умеет эффективно хранить пустые значения?
Да нет, я говорил ВООБЩЕ так делают. Magento к примеру. Это называется "разрежение матриц".
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942978
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257Знаете, я очень плохо отношусь к EAV, но в данном случае порекомендую именно это, с EAV проект проедет дольше, прежде чем будет заброшен.
Уточню=) Вы имели ввиду рекомендуете EAV для продуктов как для сущностей? Или для наборов значений атрибутов(то о чем этот сабж)? Я тоже плохо отношусь к EAV(в сабже написал почему). Кстати, те же Magento 1000 и 1 раз пожалели что выбрали EAV в качестве основной модели. И САМИ же хотели перейти на Flat table. Работать с EAV - сущий ужас=)
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942983
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ваш термин паттерн Flate table для меня непонятен. Приведите пример на пальцах что подразумевается.
Непонятен пассаж про "ОГРОМНОЕ кол-во таблиц" - по таблице на каждый товар? по таблице на каждую характеристику товара? по таблице на каждый уникальный набор характеристик?
Для СУБД большое количество таблиц - десятки тысяч не проблема.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942994
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257Ваш термин паттерн Flat table для меня непонятен. Приведите пример на пальцах что подразумевается.

Смотрите. Есть товары. Есть "типы товаров"(аля ООП-классы) майки, куртки. У типов есть атрибуты - цвет, размер, материал. Есть два варианта как хранить товары. Первый - это EAV. Второй - создавать ДЛЯ КАЖДОГО типа - таблицу. Было выбранно - второе. Но теперь для атрибутов "цвет" "материал" мы будем иметь в таблице текстовые значения "красный", "красный", "желтый". Эти значения, например набор цветов нужно вынести. И здесь опять встает вопрос - куда вынести? Два варианта - EAV=)) Или для каждого (теперь уже) атрибута создавать таблицу. Таблица "цвет". В ней значения - красный, черный.... Таблица "материалы". В ней значения - "хлопок", "синтетика", "Дигидро-альфа-эргокриптин". Теперь в таблицах со значениями будут храниться не "Дигидро-альфа-эргокриптин" 1000раз, а id "Дигидро-альфа-эргокриптин"-а


SERG1257Непонятен пассаж про "ОГРОМНОЕ кол-во таблиц" - по таблице на каждый товар? по таблице на каждую характеристику товара? по таблице на каждый уникальный набор характеристик?

Не на каждую характеристику. На это - "по таблице на каждый уникальный набор характеристик"?

SERG1257Для СУБД большое количество таблиц - десятки тысяч не проблема.
Понятно
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942999
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257Ваш термин паттерн Flat table для меня непонятен. Приведите пример на пальцах что подразумевается.

Т.е. вот это создание для каждого типа товара - по таблице и есть "flat table". Т.е. "горизонтальная" "плоская" структура. У EAV же она "вертикальная", структура "лежит" в записях таблицы, и "расширяется" как бы вертикально.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943118
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если я правильно понял то у вас затык в справочнике товаров, кроме обязательных айди, категории, подкатегории, производитель, наименование и описание у вас будет еще и определяемые пользователем поля, по которым надо проводить поиск и возможно хитрую фильтрацию (like, <, >) плюс вы хотите добавить нормализацию (выпадающие списки в гуе)

Лобовое решение в виде понатыкать полей некрасиво и ограниченно - но оно дает наиболее быстрый и удобный поиск.
Вариант EAV - где таблица E это ваша таблица товаров, таблица А вам все равно нужна. А вместо таблицы V вы хотите каждое добавляемое поле реализовать в виде таблицы (или пары таблиц в случае с нормализацией) связаной с товарами как 1:0. По сути вы получаете проблемы с быстродействием EAV, где для сбора строки надо прошерстить всю базу.

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

Рекомендую таки присмотреться к варианту с XML. Однозначным плюсом будет, то что вся работа уже реализована и вам не придется изобретать велосипед - только пишите запросы на XQuery. XML индексы будут обновлятся автоматически и прозрачно для вас.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943119
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AnchorВсех приветствую.

Для БД универсального скрипта интернет-магазина был выбран паттерн Flate table. Т.е. значения товаров будут храниться не в одной таблице EAV, а для каждого типа товара будет создаваться таблица.

В таблицах типов будет много значений которые лучше куда-то отделить в "фиксированные наборы значений". Т.е. например "цвет", "текстура", "материал". Писать миллион раз в каждой записи "красный","желтый",... "пластмасса"... - вот от этого нужно избавиться. Вместо этого, естественно, будут id значений. И здесь, опять приходим к EAV vs Create table =)))
Итак, нужно определиться где хранить "фиксированные наборы значений", наподобие значений цветов, значений материалов. В одной таблице? Или для каждого атрибута создавать по таблице?

1.EAV. По идеи он так и просится сюда. Действительно, нам советуют EAV, тогда когда кол-во атрибутов велико, а количество записей не велико. Если делать таблицами - то они будут содержать мало записей. Недостатки EAV я думаю итак известны - это скорость, и сложность 3-хэтажных запросов. Но... Для меня как для человека учившегося на мат.факе, EAV, в первую очередь, не симпатичен тем, что коверкает самую основную идеологию РБД - relation, "отношения". Все последующее строение будет "оторвано" от математики. Не я не фанат) и тоже за практичные решения) Просто мое сугубо индивидуальное мнение, EAV целесообразен: Если 1)Атрибуты очень динамичны (каждые неск-ко часов и даже каждые 10мин, они изменяются/добавляются/удаляются) И ПРИ ЭТОМ 2)Кол-во записей таблиц(у которых меняется структура) очень велико (>1млн. записей). При одновременном выполнении этих условий - без EAV просто никак. Каждое изменение (ALTER TABLE) будет блокировать базу, и будет выполнятся очень долго.

2.Flate table. Насколько я понимаю, непосредственно кол-во таблиц в БД не значительно влияют на скорость. Встает лишь вопрос удобства. Но ведь ничего не мешает таблицам прилепить префикс "z_"/"zz_" и все они будут отображаться в конце БД. Хоть их там тыща - растут себе вниз БД да и все. А имена их заданы по строгому формату "zz_"."type_value_"."{atribute_name}"

Вообщем хочу услышать ваши мнения, приветствуются ЛЮБЫЕ рассуждения=)))Забудьте слово EAV, и если надо schema-less, то учите слова RDF и SPARQL :)
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943216
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
EAV советуют тогда, когда кол-во атрибутов неизвестно и может активно меняться пользователями в процессе работы системы.И правильно советуют. Именно так чаще всего и происходит.
Не слушайте, когда вам говорят, что "новые атрибуты добавляются раз в год". Придет новый начальник/добавится новый бизнес-проект и добавления будут 10раз в день. Наступит "треш и содомия". :)
ЕАВ это гибкость и универсальность. Вы добавляете только строки. Никакая логика в коде не меняется.
Импорт-экспорт-репликация не требуют никакой модификации.
Рядовой юзер не имеет права на создание/правку таблиц.
Недостатки ЕАВ хорошо компенсируются их достоинствами.
Применение ЕАВ не мешает использовать подход с новыми таблицами.
Как и любой подход, ЕАВ надо проектировать и применять с умом.

зы: В топку академичность. Поспрашивайте преподов, какого размера реальные системы они проектировали. Неожиданно окажется, что размер был чепуховый. Читай - академичный, учебный. Они преподают, а не разрабатывают. Им просто некогда. :)
Ехать надо, а не шашечки разглядывать.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943250
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVЕАВ это гибкость и универсальность.В новых проектах EAV напрочь не нужен. Как и свой карманный XML. Как и COBOL. Если вы сейчас сочините ещё один EAV-велосипед, то через некоторое время все равно будете мигрировать на стандартный RDF, так зачем создавать себе лишнюю зубную боль в будущем?
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943314
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
будете мигрировать на стандартный RDFRDF это что-то типа чертежа. Стандартизованное описание. Обычная бюрократия. Без уточнения, как это физически реализовать.

EAV это живая реализация в виде таблиц, ХП, ГУИ.

зы: "талон на ботинки это еще не ботинки" (с)
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943382
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Для БД универсального скрипта интернет-магазина

Зачем? Чем существующие не устраивают?

> Писать миллион раз в каждой записи "красный","желтый",... "пластмасса"...

Видите ли, в чём дело: сама постановка задачи предполагает бардак в атрибутах. "Пластмасса" - не материал, "металлик" - не цвет и т. д. Вам нужно чуть более строго сформулировать задачу, - получите вполне очевидное решение.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943397
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Ехать надо, а не шашечки разглядывать.

Угу. Проблема и в квалификации разработчиков баз данных, и в квалификации заказчиков. Если бизнес готов терять бабло на ровном месте - он сам себе злобный Буратино. Но архитектор должен понимать, где именно теряется это бабло и почему. И должен быть готов к тому, что завтра ситуация может измениться.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943525
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVбудете мигрировать на стандартный RDFRDF это что-то типа чертежа. Стандартизованное описание. Обычная бюрократия. Без уточнения, как это физически реализовать.

EAV это живая реализация в виде таблиц, ХП, ГУИ.

зы: "талон на ботинки это еще не ботинки" (с)А вам не надо самому реализовывать, достаточно взять СУБД с поддержкой RDF :)
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943555
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_an_ruА вам не надо самому реализовывать, достаточно взять СУБД с поддержкой RDF :)Дайтедве, чо :)
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943673
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
guest_20040621>
> Писать миллион раз в каждой записи "красный","желтый",... "пластмасса"...

Видите ли, в чём дело: сама постановка задачи предполагает бардак в атрибутах. "Пластмасса" - не материал, "металлик" - не цвет и т. д. Вам нужно чуть более строго сформулировать задачу, - получите вполне очевидное решение.
В чем заключается бардак? Эти варианты я привел ПРОСТО ДЛЯ ПРИМЕРА. Есть допустим магазин одежды. Есть майки, куртки. Атрибуты - цвет, материал, размеры(XL,XXL). Уникальные значения этих атрибутов должны быть вынесены.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943740
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> В чем заключается бардак?

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

> Атрибуты - цвет, материал, размеры(XL,XXL)

Домашнее задание: сформулируйте разницу между цветом и размером. Хинт: размер - шкала.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943754
Фотография DirksDR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anchor,

Вам в обоих случаях потребуются свои метаданные, в обоих случаях придется формировать запросы динамически.
Разница в скорости будет поэтому незначительна, половина времени уйдет на компиляцию селектов.
При таком раскладе я бы выбрал EAV, запросы формировать проще будет.
Но, раз уже выбрали Flat, флаг Вам в руки.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943763
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621сформулируйте разницу между цветом и размером
Хинт: размер - шкала.

Цвет, вообще говоря, тоже ;)
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943775
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
guest_20040621> В чем заключается бардак?

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

> Атрибуты - цвет, материал, размеры(XL,XXL)

Домашнее задание: сформулируйте разницу между цветом и размером. Хинт: размер - шкала.
Вы не внимательно прочитали тему. С Магенто имели дело? С другими коробочными скриптами ИМ? Для чего вы вообще сравниваете атрибуты между собой? Они могут иметь совершенно разные типы(типы данных MySQL).
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943777
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Цвет, вообще говоря, тоже

Нет. Есть вполне распространённое потребительское семантическое кодирование цвета. И есть - совершенно справедливо - шкалы. И вендор-лок, и унифицированные.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943780
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Вы не внимательно прочитали тему.

Напротив, корневое сообщение прочёл внимательно. Отсюда и тезис о бардаке. Боюсь, потерял время напрасно: вы не поняли, о чем вам говорят.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943790
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Цвет, вообще говоря, тоже

Нет. Есть вполне распространённое потребительское семантическое кодирование цвета.

Так и у размеров есть "распространенное потребительское семантическое кодирование", так что это не критерий.
Имхо реальный критерий в вопросе "шкала/не шкала" - это "имеет ли смысл отношение порядка между элементами множества" (притом что и размер и цвет - шкалы неодномерные).
И для нужд инет-магазина имхо они равно неосмысленны, число запросов "штаны темнее чем X" и "штаны больше чем X" - стремится к 0.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943831
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Так и у размеров есть "распространенное потребительское семантическое кодирование"

Можете привести пример?

> для нужд инет-магазина имхо они равно неосмысленны

Полагаете?
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943842
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Кот МатроскинИ для нужд инет-магазина имхо они равно неосмысленны, число запросов "штаны темнее чем X" и "штаны больше чем X" - стремится к 0.
"штаны темнее чем X" вряд ли понадобиться=)) Но вот "выбрать штаны больше/меньше XL" - запросто. В контексте БД, если это нужно, размер просто будет числовым типом, а XL, XXL - строковыми метками. То же самое про цвет.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943852
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Так и у размеров есть "распространенное потребительское семантическое кодирование"

Можете привести пример?

Ну как - Small, Medium, eXtraLarge и т.п. Распространенное? Распространенное. Потребительское? Конечно. Семантическое? Ну в каком-то смысле -да.

guest_20040621> для нужд инет-магазина имхо они равно неосмысленны

Полагаете?

Сужу по своему поведению в инет-магазинах одежды :) Анализа частоты запросов для какого-нибудь aliexpress - не делал, да.
Можно ТС спросить, что думают их бизнес-аналитики на этот счет.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943855
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anchor"штаны темнее чем X" вряд ли понадобиться=)) Но вот "выбрать штаны больше/меньше XL" - запросто. В контексте БД, если это нужно, размер просто будет числовым типом, а XL, XXL - строковыми метками. То же самое про цвет.

ТС уже ответил :)
Ну ок, значит guest_20040621 прав - размер в данном случае шкала, а цвет -нет.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943911
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Ну как - Small, Medium, eXtraLarge и т.п.

:) Это шкала, Кот. Поищите в Сети соответствие отечественной шкале, если интересно. Буквой вы обозначите размер или словом - не принципиально. И смысл использования шкал в данном случае вполне прозрачен. Если кто-то выбрал себе футболку определённого размера, то, возможно, есть смысл предложить ему и куртки того же размера, даже если в базе данных они имеют разные шкалы. Т. е. получили ещё одну неявную задачу. На самом деле не одну, но это не принципиально в данном случае.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38944043
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскинguest_20040621сформулируйте разницу между цветом и размером
Хинт: размер - шкала.Цвет, вообще говоря, тожеВ отличии от размера, цвета общеупотребительно не имеют порядка, кроме как в специфических случаях, например, привязка к физическим характеристикам типа длины волны, типа "каждый охотник желает...".
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38944132
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Ну как - Small, Medium, eXtraLarge и т.п.

:) Это шкала, Кот. Поищите в Сети соответствие отечественной шкале, если интересно. Буквой вы обозначите размер или словом - не принципиально. И смысл использования шкал в данном случае вполне прозрачен. Если кто-то выбрал себе футболку определённого размера, то, возможно, есть смысл предложить ему и куртки того же размера, даже если в базе данных они имеют разные шкалы. Т. е. получили ещё одну неявную задачу. На самом деле не одну, но это не принципиально в данном случае.
Совсем не про БД, но вставлю комментарий. В реале увы, это никакая не шкала, так, фикция. XXL одного производителя будет физически меньше XL другого... Советская шкала ростов и размеров была гораздо надежнее.
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38944229
ээээээ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ChAКот Матроскинпропущено...
Цвет, вообще говоря, тожеВ отличии от размера, цвета общеупотребительно не имеют порядка, кроме как в специфических случаях, например, привязка к физическим характеристикам типа длины волны, типа "каждый охотник желает...".какбе типографы, дезайгнеры и т.п. зайчеки с вами не согланы.

просто цвет это 3-х [или ч-х реперный вектор]. там 3[4] ортогональные шкалы

а вот с размерами -- полная невязка. то XXXL уже XXL то ещё какая лажа приключаицца. т.е. хуест кака бычна -- газифицировал лужу
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38945347
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Совсем не про БД

Как раз про базы данных. Формально каждый из размеров SML-шкалы соответствует диапазону размеров советской шкалы. Плюс к этому у каждого вендора могут быть свои особенности маркировки. Т. е. всё это формализуемо. Вопрос в том, где требуется остановиться. :) Никто не обещал, что структуры данных - это просто. Мельком видел заголовок об изменении лекал для массового пошива: фигура среднестатистического потребителя меняется достаточно быстро (быстро - не в потребительском смысле).
...
Рейтинг: 0 / 0
EAV или Create table для фиксированных наборов значений атрибутов?
    #38945443
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anchor... Смотрите. Есть товары. Есть "типы товаров"(аля ООП-классы) майки, куртки. У типов есть атрибуты - цвет, размер, материал. Есть два варианта как хранить товары. Первый - это EAV. Второй - создавать ДЛЯ КАЖДОГО типа - таблицу. Было выбрано - второе...
Лучший вариант третий - хранить "товары" в одной нормальной таблице. Для этого нужно иметь СУБД - вот с этим, как раз, проблема.
...
Рейтинг: 0 / 0
46 сообщений из 46, показаны все 2 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / EAV или Create table для фиксированных наборов значений атрибутов?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]