EAV или Create table для фиксированнных наборов значений атрибутов?

для этого EAV обычно дублируют плоскими таблицами
для наиболее часто запрашиваемых данных
в плоской таблице можно себе позволить помещать данные в поле через разделитель
там где идет выборка по первичному полю(заказы)
для отчетов и тому подобным изыскам уже пользоваться чистым EAV
в каждом подходе есть свои плюсы и минусы
компромисс как обычно решает основные проблемы )
(Добавление)
Magento
как всегда наскоро пробежал тему и повторил все выше сказанное
да простят меня мужчины))

вроде как тут это было http://forum.php.su/topic.php?fo...opic=828&p=2
особенно хорошо все описанно в посте Евгена, но опять же на англ языке
http://stackoverflow[dot]com/questio[dot][dot][dot]0783125#20783125

-----
Just do it

ну тогда юзать NoSQL решения/ Вот здесь на англ.
http://stackoverflow[dot]com/questio[dot][dot][dot]and-alternatives

esterio уверен?
я может чего плохо прочитал но имхо очень плохая замена EAV
NoSQL очень специфичное решение
очень легко ошибиться посчитав его хорошим решением
например очень плохо выбирать по поддокументам
esterio ай ай

Вообще я пришел к тому, чтобы использовать в будущем гибрид(в тех случаях когда с MySQL будут напряги), MySQL + NoSQL, вообщем 2-е СУБД.


+10! БД эта самый фундамент. Надо тщательно его выстроить, иначе потом сама же технология может загнать в тупик. Рекомендую статью http://habrahabr[dot]ru/post/231213/ Заголовок конечно "желтый", но статья полезная. Я ее внимательно прочитал, обратите внимание на самый последний абзац "Найдите ценность"

(Отредактировано автором: 23 Апреля, 2015 - 15:37:27)

я об этом и говорил

Последний вопрос задам в этой теме Повлияет ли на скорость работы MySQL огромное кол-во таблиц(скажем 3-6тысяч?) Может ли это стать критичным?

(Отредактировано автором: 23 Апреля, 2015 - 19:49:12)

да
это может стать критичным
дело в том что для внутренних целей MySql использует базу данных Information Scheme
в этой базе хранятся все служебные данные для бд...ну не все но инфо о таблицах и базах там точно хранятся
и если у тебя очень много таблиц
тысячи тысяч
то для всяких внутренних нужд мускул лезет в эту самую информатион схеме
и потом найдя в тысяче таблиц твою еще долго ищет ее
короче идея очень плохая
это может стать очень критичным
если у тебя много данных которые по логике могут быть разнесены на разные сервера тогда лучше использовать балансировку и горизонтальное шардирование
(Добавление)
но
это надо делать очень аккуратно
(Добавление)
любой сервер при таком количестве таблиц ляжет гарантировано
потому что не будет использоваться кэш
а прямое обращение к памяти кушает так как будто с диска читаешь...ну чуть быстрее при первоначальном поиске начала данных
(Добавление)
такого количества таблиц нет ни у одного супер нагруженного сервиса
а ты уверен что у тебя есть такое колво таблиц?
имхо комп ляжет от одного колва

Допустим есть ИМ гипермаркета. Типов товаров - будет много. Атрибутов - еще больше. Если для каждого атрибута (для которого есть уникальный набор значений, например размеры для одежды XL,XM; материал - "хлопок", ""пластмасса", "Дигидро-альфа-эргокриптин"") будет создаваться своя таблица, то таблиц может быть больше тысячи - запросто.



Понятно. На другом форуме, вроде опытный чел пишет что для СУБД - десятки тысяч таблиц не проблема http://c2n[dot]me/3gDoW8x Надо короче делать тесты=)) Но они все равно будут, собака, синтетические.

UPD: Да кстати, ВАЖНОЕ замечание. Таблицы все эти будут (как правило) содержать небольшое кол-во записей. Т.е. уникальных значений атрибутов(кол-во размеров напр., материал) как правило - мало, десятки, сотни.

(Отредактировано автором: 23 Апреля, 2015 - 20:41:15)

они шардируются на разные серваки
например первые 100 000 товаров лежат на одном сервере а следующие 10 000 товаров лежат на другом сервере
и тогда вопрос стоит не в количестве таблиц а в балансировке запросов
тоесть запрос для одних товаров идет на один сервер а запрос на другой товар идет на другой сервер
так именно и работают высоконагруженные сервисы
иначе они бы легли от простейшего запроса
более того
балансировка может быть разного типа
самая элементарная балансировка это балансировка по днс
давно уже не используется
потом возможно аппаратная баланстровка LVS - это есть в любом линуксе даже в десктопном
но по хорошему тоже костыль
лучшая балансировка это балансировка на уровне приложения
типа ты на своей странице все картинки тянешь с одного сервера
скрипты тянешь с другого сервера
это самая надежная балансировка
есть еще балансировка по днс
но это чисто вспомогательно
не буду углубляться иначе я тут целую лекцию прочту
много что кто то там пишет
не всему стоит верить
ты спроси это чела где он физически встречал такие беде?
такого не бывает
любой сервак уйдет в аут только по прерываанию запросов
не сумеет обработать такое колво таблиц...обещаю тебя обманули
шардирование бд есть самое узкое место высоконагруженных систем
и никто это до конца не решил еще
---похуй
главное что информатион схеме захлебнется
(Добавление)
не верь всему что дебилы городят
высокая нагрузка это очень большая проблема
(Добавление)
офигеть
нафига я рассказываю дураку о шардировании?
шоб я сдох

Один запрос к БД, не будет, как правило обращаться и к 10% таблиц атрибутов. Но как я понял не в этом проблема, а в работе СУБД с information schema.


Ясно. Вообщем вывод. Лучше использовать не кучу таблиц а запихнуть все в несколько таблиц (по типам _int _text) по твоему? Или все же таблицы на каждый атрибут, но в последствие, если их кол-во будет столь велико, решать эту проблему шардированием?


Ко мне обращение? Одни любезности=) Я никого не оскорблял=)

(Отредактировано автором: 23 Апреля, 2015 - 21:23:48)

ой ой
ни в коем случае не имел никого конкретно ввиду
просто не заметил моментальной реакции на написаное и вот среагировал так как не следовало
а далее я еще напишу...обнови страницу
(Добавление)
начнем с этого
у бд
как и у любого кэша
включая кэш диска
включая разные кэши разного уровня цп
все они пытаются оптимизироваться
они читают узлы которые идут после узла который ты запросишь
в надежде что ты будешь читать данные последовательно
и правильно
нормальные прогеры это знаютт и читают данные целиком
но если у тебя дофига таблиц то сначала указатель смотрит на адрес
откуда читать?
и он офигевает от колва таблиц
и вот он не успевает успокоится....а кэш проца не умеет помещать в себя много всего
он ждет твоего действия
и ты читаешь следующую таблицу
хорошо если таблиц мало
но их много тысяч
значит идем их искать
и пока мы все это мудрим к нам пришло еще несколько запросов
наша песня хороша начинай сначала
да мой запрос поместится в кэш
следующий мой подобный запрос будет отдан моментально из кэша
но хрен там
таблиц столько что я не могу все запросы держать в кеше
а зпросы идут
идут
идут
идут
я не успеваю закончить обработку
и проц только успевает переключаться между запросами
100% нагрузки на проц изза ожидания памяти
проц стоит ничего не делает но 100% нагрузки
(Добавление)
серебряной пули не существует
решают по ситуации
(Добавление)
никто не обещал что высокие нагрузки это легко
это просто рак головного мозга
(Добавление)
есть много разных способов
например ты знаешь что браузер может поддерживать 6 соединений одновременно?
значит можно картинки распределить на 6 хостов
но не более
потому что скачав одну картинку соединение уже разогнано
можно качать дальше
оооой
столько ньюансов
а ты дебилов слушаешь которые тебе советуют тупо плодить таблицы
ох сколько таких
(Добавление)
на самом деле нет рецепта
все что я тут нагородил это все теория

Давайте начнем с того, что кол-во join в запросе тоже ограничено (30 или 60 +/- не помню).
Т.е классическом (сво-во = таблица) Вы упретесь когда-нибудь в это число.

Anchor рекомендую послушать туарега
я лично не знаю никого более сведующего в вопросе беде
когдато по глупости и по гордости пробовал с ним спорить
бесполезно)) вот в чем он спец так это в беде
(Добавление)
tuareg кстати мне интересно ...выше я высказывал ...не соврал?

Я посмотрел, information_* там все таблицы(почти) типа memory. Обращение к ним если хватит памяти будет мгновенным. (Да я на хайлоде я спрашивал у MySQL вроде все должно быть норма) . Так что ИМХО, навряди ли в нее упремся. Но это так-то бред, у нас работе как то 1000 таблиц (включили дебаг и вместо временных начали генериться обычные таблицы) создались, это было феерически ))).