ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / EAV или Create table для фиксированных наборов значений атрибутов?
25 сообщений из 46, страница 1 из 2
  1  все
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942906
Anchor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
22.04.2015, 18:29
| Ответить | Цитировать | Написать  
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942909
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Anchorнужно определиться где хранить "фиксированные наборы значений", наподобие
значений цветов, значений материалов. В одной таблице? Или для каждого атрибута создавать
по таблице?
Конечно же для каждого создавать по таблице. Это же совершенно разные вещи: справочник
цветов, справочник материалов (а у материалов есть и свои характеристики) и т.д.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
22.04.2015, 18:34
| Ответить | Цитировать | Написать  
EAV или Create table для фиксированных наборов значений атрибутов?
    #38942923
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Anchor При одновременном выполнении этих условий - без EAV просто никакЛегко. Запихиваете свой сложный объект с переменной структурой, как есть в блоб, xml, json и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Рекомендую таки присмотреться к варианту с XML. Однозначным плюсом будет, то что вся работа уже реализована и вам не придется изобретать велосипед - только пишите запросы на XQuery. XML индексы будут обновлятся автоматически и прозрачно для вас.
...
Рейтинг: 0 / 0
23.04.2015, 05:29
| Ответить | Цитировать | Написать  
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943119
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
23.04.2015, 05:41
| Ответить | Цитировать | Написать  
EAV или Create table для фиксированных наборов значений атрибутов?
    #38943216
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
EAV советуют тогда, когда кол-во атрибутов неизвестно и может активно меняться пользователями в процессе работы системы.И правильно советуют. Именно так чаще всего и происходит.
Не слушайте, когда вам говорят, что "новые атрибуты добавляются раз в год". Придет новый начальник/добавится новый бизнес-проект и добавления будут 10раз в день. Наступит "треш и содомия". :)
ЕАВ это гибкость и универсальность. Вы добавляете только строки. Никакая логика в коде не меняется.
Импорт-экспорт-репликация не требуют никакой модификации.
Рядовой юзер не имеет права на создание/правку таблиц.
Недостатки ЕАВ хорошо компенсируются их достоинствами.
Применение ЕАВ не мешает использовать подход с новыми таблицами.
Как и любой подход, ЕАВ надо проектировать и применять с умом.

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

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

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

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

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

Видите ли, в чём дело: сама постановка задачи предполагает бардак в атрибутах. "Пластмасса" - не материал, "металлик" - не цвет и т. д. Вам нужно чуть более строго сформулировать задачу, - получите вполне очевидное решение.
...
Рейтинг: 0 / 0
23.04.2015, 11:59
| Ответить | Цитировать | Написать  
25 сообщений из 46, страница 1 из 2
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / EAV или Create table для фиксированных наборов значений атрибутов?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=38942973&tid=1540568]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 171ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 56ms
get tp. blocked users:
 1ms
others: 239ms
total:  511ms
созд. / загр.: 511ms
x
x
Закрыть


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