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

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

Я согласен, и не спорю. ))

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

Там нужно время, надо ведь не просто таблички понаделать. Надо именно сравнить работу с одной таблицей(когда все они запиханы в одну таблицу). Плюс ряд разных запросов более "естественных" протестить. Но я еще вернусь и подолблю эту тему=) А пока было решено для атрибутов не создавать отдельные таблицы. А хранить их все в одной таблице, но со столбцами по типам "int" "text".


Ну форумчанин tuareg советует избежать в этом случае* создания мелких таблиц на каждый атрибут? Верно я понял? Аргумент - скорость. Вместо этого хранить их (уникальные значения атрибутов) в одной таблице

в этом случае* Я понимаю прекрасно что "серебрянной пули нет", и что все зависит от ситуации. Реал понимаю. В погоне за универсальностью мы приобретаем проблемы с быстродействием и сложностью системы. Это проблемы - ВСЕХ универсальных систем. Просто абстрагируемся от этого=) Есть бассейн, вода втекает/и вытекает. А что там СНАРУЖИ бассейна - насос работает, или мифический Евпидокл льет, по барабану=) Такова постановка задачи, в данной теме - универсальный скрипт Каталога/Магазина.

(Отредактировано автором: 24 Апреля, 2015 - 16:44:18)

взять пример из первого поста DeepVarvar, но не советует все типы (text, decimal) хранить в одной таблице. А для каждого типа сделать свою. ИМХО
+ Места меньше, индексы более вменяемы
- Дополнительные join-ы

Плохое имхо. Мутатень с таблицами же.

-----
Шта? Репозиторий?

К этому варианту я сначала и склонялся. Но фишка в том, что 1)Запросы будут проще если таблица одна 2)Про место понятно(в одной таблице будет много пустых ячеек), НО это таблица практически ни у кого не будет огромной, ну предел неск-ко тысяч записей, это ведь уникальные наборы значений. Исключения могут быть, но здесь мы идем по среднестатистическому магазину, а у него не много уникальных наборов значений.

(Отредактировано автором: 25 Апреля, 2015 - 09:47:34)

У нас на работе также было сделано. Все в одной таблице. Выборка по id +/- нормально, остальное ... .
Сейчас мы имеем жутко неповоротливый модуль. Потому как клиентам вдруг захотелось именно огромных каталогов( TECDOC ). Причем прикол в том, что в текстовых полях инфы почти и нет (20%-30%) заполнено.
Т.е я не претендую на истину в последней инстанции , но одна "свернутая" таблица ... . Я бы не использовал, с учетом вышесказанного.

[quote=tuareg][/quote]
А какое кол-во записей в этой таблице стало?

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

У нас была версия миллиона на 1.5 строк. Пытались сделать по 5-10 полей, для каждой строки ( 1.5 * 5). Выдержать то выдержало, но сортировки и т.д. Все стало очень плохо ((

Жесть Я рассуждаю когда вот проблема хай-лоада может стать не актуальной в вебе, для большинства крупных сирвисов? 13лет назад вспомнить смешно какое было железо. Лет через 15-20 мой вопрос "плодить ли таблицы" тоже был бы наверно не актуален=)