Кот МатроскинНу хорошо, Вы отберете ID-шники объектов из 1001-й таблицы - а дальше-то что? Все атрибуты как получать? Все равно либо 1000 Union, либо 1000 left join.
Мне кажется, в стремлении возразить Вы немного потеряли... задачу. Задача "получить в одной выборке все уникальные атрибуты тысячи разнородных типов объектов" - мягко говоря, нестандартна. "Дальше-то" просто ничего, как правило эта выборка и будет ответом на задачу.

Тысяча union, кстати, ничем особенно не плоха, кроме неудобного и громоздкого SQL. Технически она не так уж отличается от одной таблицы с тысячью партиций.

Кот МатроскинЕсли "дальше-то ничего" и атрибуты не нужны - то и в EAV запрос будет не по таблице "ЗначенияAтрибутов" с 100 миллионами строк, а только по таблице "Обьекты" c миллионом, со всеми вытекающими.
Не вижу причин оспаривать, поскольку вывод меня вполне устраивает :)

Кот Матроскин Насчет "задача нестандартна" - чего ж в ней нестандартного-то? Примерно такую штуку делают Яндекс-карты при вводе адреса дома - "в этом доме находятся...".
Кот, а Вы не пробовали запустить Яндекс-карты, посмотреть, что они делают на самом деле и перестать нелепо фантазировать? :)

Кот МатроскинНе рассматривайте задачу как "получить из базы выборку для грида", рассматривайте как "получить от Web-сервиса XML c обьектами".
А тут нет разницы. Ну ладно, допустим, Яндекс-карты работали бы так, как Вы нафантазировали. Обратились к сервису, получили от него список объектов вида id/name. При клике на объекте, если обратите внимание, идёт новый запрос к серверу, "покажи детальную информацию". Это уже ни в малейшей степени не запрос к тысяче таблиц, атрибуты идут из одной-единственной. Впрочем, я вообще не уверен, что у Яндекса для разных типов объектов заметно разные наборы атрибутов - поскольку для него аптека от школы отличается только картинкой.

Кот МатроскинДа и отбор 1000 записей из 100 млн. "ничем особенно не плох", движок СУБД заточен
Заточен. Но на моём ноуте будет работать слишком (с моей точки зрения) долго. Особенно если требуется мало-мальски нетривиальная фильтрация объектов.

Кот МатроскинА 1000 Union - и не оптимизировать особо никак.
Помнится, когда один наглый товарищ объявил себя гуру оптимизации, его попросили оптимизировать select 1 from dual.

Arhat109От размера таблиц скорость работы зависит в среднем логарифмически (индексы).
Само по себе это сферическое рассуждение в вакууме. Но более забавно то, что Вы, похоже, полагаете вычислительную сложность алгоритма единственной и всеобъемлющей характеристикой.

Кот Матроскин Пробовал - они выводят именно список обьектов.
То есть не смотрели. Подсказываю: существуют инструменты, с помощью которых можно посмотреть на запросы из браузера и ответы на них сервера. В данном случае никакого "списка объектов" сервер клиенту не возвращает вообще.

Кот Матроскин(как минимум еще название, против Вашей версии "кроме ID-шников больше ничего")
Будьте так любезны не приписывайте мне результатов собственной убогой фантазии.

Кот МатроскинCо всеми атрибутами или только с некоторыми - вопрос итоговой верстки.
Слабая попытка. Впрочем, Вы по-прежнему можете попробовать назвать хотя бы одну реальную задачу, вписывающуюся в Вашу канву.

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

Кот МатроскинТС-у нужно хранить разные обьекты и выдавать разные обьекты, по постановке.
Вот и нефиг приводить как пример систему, хранящую одинаковые объекты и их вообще не выдающую (в том смысле, в котором Вы употребляете слово "выдавать").

Кот МатроскинТак что кто тут "потерял задачу" - вопрос.
Ну-ну, прямо-таки вопрос.

Arhat109Без указания конретных ограничений,
Не имеет отношения к ситуации с довольно конкретными указаниями ограничений.

Arhat109которые больше оттолкнуть не от чего как от "сложности алгоритма"
(зевая) Пара заданий в любом приличном ВУЗе:

1. Назвать алгоритмы (например, сортировки), обладающие одинаковой вычислительной сложностью и при этом кардинально отличающиеся практическим быстродействием.
2. Сконструировать ситуацию, в которой алгоритм с большей вычислительной сложностью окажется значительно быстрее алгоритма с меньшей вычислительной сложностью.

Поясняю совсем просто: "вычислительная сложность" роляет только при решении задач типа "как изменится время выполнения программы на моём ноуте, если объём данных увеличить в десять раз". Но и тут существуют множество факторов, существенно меняющие картину по сравнению с напальцевыми теоретическими оценками.

Arhat109вы где нашли то, что написали про "всеоблемлемость"? :)
Там, где я нашёл, что Вы не написали ни слова о действительно определяющих вещах, а упомянули только вычислительную сложность, да и в той по торопыжести допустили совершенно детскую ошибку.

Arhat109если EAV на вашем ноуте "будет сильно тормозить", то решение с кучей таблиц тормозить будет значительно сильнее. А если оно НЕ тормозит, стало быть EAV будет просто летать в тех же условиях, начиная от определенного объема данных,
Смешно. Задача: внимательно прочитать то, что Вы написали про вычислительную сложность того и другого варианта и понять, почему Ваш вывод про "тормозить-летать" - совершенно не следует из Вами же написанного ¹ . Ну про соответствие практике и заикаться незачем.

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

LSVНо.... она имеет смысл при наличии тщательно вылизанного движка, обслуживающего сабжевые тыщи таблиц.
У Вас он есть ?
Да, он называется "СУБД". Во всяком случае, я пока что не вижу, какой ещё дополнительный движок Вы имеете в виду.

Если взять постановку задачи "написать с нуля движок, который поддерживает хранение данных различных объектных типов и некий набор операций над ними", то я не вижу никаких оснований утверждать, что EAV-подход даст более компактное решение. В простых случаях они будут примерно одинаковы, по мере нарастания сложности EAV, подозреваю, начнёт кардинально проигрывать из-за сложностей с использованием стандартных механизмов СУБД.

LSVСадиться писать на эдак парочку чел/лет ? ... некислый по сложности движок DDL-sql, ....
Хм. Как бы деликатно сказать... "DDL-движок", если я правильно понимаю, о чём Вы - это задача на несколько минут, а не на несколько лет.

LSVСкромный сервачок потянет на ура...
Допускаю, что так. Поэтому и начал с "мой ноут" - если у топикстартера есть лишний сервачок адекватной мощности, то может и можно выбрать EAV.

Кот Матроскин Что список обьектов должен запросить именно браузер - я нигде не писал,
Слабенько. Стандартный интерфейс названного Вами проекта - именно браузер. Если у Вас в кармане есть к нему другой, секретный, клиент, общающийся с сервером по другому, секретному, протоколу, и Вы "забыли упомянуть", что имеете в виду именно его.... ну ладно, показывайте этот клиент, посмотрим его

Кот МатроскинВ свою очередь, если список обьектов с атрибутами присутствует на страничке, которую отдали браузеру -
Ага, судя по всему, после подсказки таки посмотрели, как же работают Яндекс.Карты.

Кот Матроскинстоит предполагать, что его-таки каким-то образом из базы извлекли.
При этом Ваши фантазии "как именно его извлекли" - мягко говоря, малоинтересны из-за абсолютной беспочвенности. Ни Вы, ни я не можем обоснованно утверждать, что же там за фасадом. Я, например, вообще не дам зуб, что там используется реляционная СУБД.

Итого вывод: ни одного примера задачи под свою постановку Вы пока что не назвали. Единственная попытка в доступной для исследования части работает во всех смыслах иначе.

Кот Матроскин P.S. softwarer, у Вас что, критические дни? Что это за переходы на личности?
Хм. Хорошо, попробую высказаться подчёркнуто аккуратно. Вы в рамках нашей беседы несколько раз предлагали для решения простейших задач совершенно несуразные способы. По этой причине я вполне верю в то, что и правильное решение других задач Вы искренне предполагаете столь же несуразным, но я совершенно не вижу причин присоединяться к этой точке зрения и меня раздражают Ваши упорные попытки выдать эти решения за предлагаемые или предполагаемые мной.