javajdbc...вообше вы задали ну настолько абстрактный вопрос...
Вопрос конечно абстрактный, но он больше на понимание принципов поведения.
А в целом задача при всей своей абстрактности достаточно изолированная.
Это не летели два крокодила, один зеленый, другой на север... :-)
MasterZivесли ты всё делаешь правильно, join - довольно дешевая операция, а именно
n ✖ log m
где n количество записей во внешней (отфильтрованной) таблице, m - количество записей во внутренней таблице.
все делаешь правильно значит, что join по КНФ (без or), по равенству и по первичному ключу или по полю/полям с индексом.
Немного не понял по поводу алгоритмической цены n * log m, потому что коли тут только два параметра, то возможно вы имели ввиду стоимость запроса без коробки передач вообще, то есть вот так
1.
2.
3.
select * from cust c
join metamoz m on m.metaId = c.metaId
&& metaMask = 'some'
Значит ли это, что вы тем самым утверждаете, что если в таблицах коробки передач все поля i являются интовыми примарными ключами, а на все интовые поля m тоже кинуть индекс, то при объемах таблиц cust и metamoz до 100 тыс. записей коробка передач вообще не будет создавать никакого заметного "трения" на фоне стоимости запроса без коробки?
Примечания
1) В этой задаче select всегда меньше или равен
select count(*) from cust .
Всегда.
Вне зависимости от "винегрета", хранящегося в таблицах коробки передач.
2) В этой задаче важно выяснить не стоимость самого селекта, а разницу в стоимости между селектом с "коробкой" и без "коробки".
- Если окажется, что "коробка" ничего не добавляет, то есть добавляет 10-20% или меньше на фоне основного запроса, ну тогда и хрен с ней (то есть это классная новость).
- Но если окажется, что "коробка" по сравнению с прямым запросом увеличивает стоимости в разы, тогда хотелось бы выяснить эмперические правила прироста стоимости при каждом последующем каскаде.
