Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / EAV или Create table для фиксированных наборов значений атрибутов? / 25 сообщений из 46, страница 1 из 2
  1  все
22.04.2015, 18:29
    #38942906
Anchor
Anchor
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EAV или Create table для фиксированных наборов значений атрибутов?
Всех приветствую.

Для БД универсального скрипта интернет-магазина был выбран паттерн 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:34
    #38942909
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EAV или Create table для фиксированных наборов значений атрибутов?
Anchorнужно определиться где хранить "фиксированные наборы значений", наподобие
значений цветов, значений материалов. В одной таблице? Или для каждого атрибута создавать
по таблице?
Конечно же для каждого создавать по таблице. Это же совершенно разные вещи: справочник
цветов, справочник материалов (а у материалов есть и свои характеристики) и т.д.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.04.2015, 19:01
    #38942923
SERG1257
SERG1257
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EAV или Create table для фиксированных наборов значений атрибутов?
Anchor При одновременном выполнении этих условий - без EAV просто никакЛегко. Запихиваете свой сложный объект с переменной структурой, как есть в блоб, xml, json и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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