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

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

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

т.е. "по существу" сказать нечего, "фантазирование" замечено, начинаем "переводить стрелки" на знакомое... а по делу?

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

... а по делу, оказывается, вы пишете то же самое что написано мною, но "внезапно" забытое в цитировании...
Впрочем, я не гордый, не претендую на корректное заимствование.

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

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

уж будьте так любезны... а то я даже и искать не собираюсь без вашей помощи... давайте вместе ещё разок посмеемся.

softwarer,

"когда меня дополняют, я - молчу, но когда режут" (с) Барон Мюнхаузен. :)

Вы упустили один важный пункт, связанный с постановкой этой конкретной задачи, а именно: Что лучше (или - или). То есть суммарный объем информации - примерно константен. А стало быть вопрос звучит "чуть-чуть" не так:

Ваша редакция:
1. При поиске записи в одной [большой] таблице (по индексу) вычислительная сложность этой операции O(log(N))
2. При поиске записи в куче [небольших] таблиц вычислительная сложность этой операции O(N)
3. Таким образом, по мере нарастания объёма данных первый вариант становится всё более предпочтительным ("летает") по сравнению со вторым ("тормозит").

Мои утверждения:
1 пост:
Вы сравниваете "теплое с мягким" . ОДНА таблица с 100 строк работает быстрее ДРУГОЙ ОДНОЙ таблицы с миллионом строк.
(это было "теплое") Но:
ТЫСЯЧА таблиц в ОДНОМ запросе через UNION по 100 строк - далеко не факт, что будут быстрее чем 4 таблицы (EAV) по 100 тысяч строк в ОДНОМ запросе.
(а это - "мягкое")

2 пост (с оценкой сложности):
Да даже по миллиону. И даже если в реализации EAV более 4-х таблиц (например по одной на тип значений). От размера таблиц скорость работы зависит в среднем логарифмически (индексы). Запросы с Union по тысяче таблиц только парсится будут "годами"... :)
и даже при наличии индексов - падение производительности надо ожидать ... линейное от количества таблиц (у каждой свой индекс).

... найдите 2 отличия между редакциями. :)

Итого, хотите разобраться, давайте.
1. Вариант:
Имеем (пусть для определенности) 1000 таблиц по 100 записей с небольшим количеством "общих" (pos_x,pos_y,type_name, owner_id) и разным количеством (возможно и большим? давайте рандомно от 1 до 10 разных базовых типов) "почти" уникальными наборами полей (по задаче, каждый тип имеет свои атрибуты)... т.е. "объем инфы" в районе 1000*100*(4+5) = 90_000 значений атрибутов с рандомным заполнением. Начальное заполнение параметризованной процедурой, рандомно. Названия атрибутов пишем param_номер_типа_номер атрибута, где номер типа - сквозной по всем значениям всех таблиц.
2 Вариант:
То же самое, но в EAV:
Таблица всех типов: 10_000 записей.
Таблица атрибутов и их типов: 50_004 записи (4 общих).
Таблица всех значений (для простоты, всё храним как vchar): 90_000 значений.
Задача:
1. выбрать все значения всех объектов, находящиеся в квадрате {(X1,Y1),(X2Y2)} т.е. по общим атрибутам.
2. выбрать все объекты в том же квадрате, но имеющие атрибут типа "ДатаВремя" -- типа "время работы" (который в разных типах у разных пользователей может называться по-разному), со значениями заданном диапазоне...

Выкладывайте "своё" решение тут, и я выложу вам на EAV. Давайте на чистом SQL, прогоню оба на своем Мускуле. Запустим и сравним с разным объемом данных.

... тут есть ещё спецы по Каше и Мумпс (с "настоящими СУБД")... тоже можно поучаствовать.

... только сильно боюсь, что вашего решения на 1000 таблицах (впрочем как и от настоящих СУБД), врядли дождешься в этой жизни. Потому как "теоретики", блин.

ну что, будем тестить?

Arhat109,

Да, ещё п.3. Выдать список названий и типов ВСЕХ атрибутов (полезно для интерфейса пользователю для снижения количества "поохожих" атрибутов)... как понимаете, в EAV - это просто содержимое одной таблицы.

... Ваше решение, каково? :)

Arhat109,

, а если учесть, что UNION всегда предполагает одинаковую структуру объединяемых таблиц... то запрос по п.2. я думаю "в этой жизни" ждать смысла нету... только навороченная хранимая процедура ...

... вы ещё по-прежнему уверены, что ваше решение точно лучше? :)

Бредятина,

никакой проблемы с расчетами. Вы, как и большинство тут - не внимательны. Вы посчитали предельный объем атрибутов, а я - средний: "максимально 10 уникальных полей"... в среднем - 5 (половина есть, половины нет).

Что хочу? Предлагаю выложить "тестовый пример" и прогнать его на одной машинке... оценить "тормоза" каждого решения. Участвовать со своей "настоящей СУБД" - будете?

Если да - от Вас контрольный пример (даже готов себе ради такого удовольствия поставить Мумпс на машинку), который можно просто залить и прогнать. Требуемые запросы к СУБД - приведены (3шт).

Если нет - ещё раз к Вам просьба: не отвечать далее на мои посты. Желательно ни прямо ни косвенно.

Arhat109,

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

Бредятина,

Да "и я могу"... в т.ч. и на вашем любимом Мумпс. Но давайте, каждый сделает ТОТ пример, за который ратует. Считаете лучше - предложите пример, потестим. ЗА ВАС никто и ничего делать не будет. Не хотите делать - не отвечайте далее, как и просил ранее. Не надо флудить мне в ответ.

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

Arhat109,

Да, кстати там действительно есть ошибка... в среднем будет 900_000 атрибутов. Нолик потерялся. :)