Слишком ты серьезно...

> но ни к чему не пришли

Хмм... а к чему в этой теме вообще можно "прийти" (или что осталось неясным)?

> Я остался при своем мнении

Любопытно, при каком. ;)

> не считают в терминах O(N)

Да, разумеется. Но то, что и как считает "оптимизатор",  к асимптотике алгоритмов не относится.

> Оптимизатор в оракле , например , высчитывает стоимость , как количество одноблочных чтений

Да и во многих оптимизаторах это так, насколько я помню (хотя то, в чём именно считается стоимость, не имеет значения, и в некоторых СУБД номинальную стоимость операций можно настраивать).

> И это более практично

Чем что? Альтернатив я как-то сходу не помню. ;)

> То есть считать практичнее в чтениях с диска в штуках и сравнивать их .

Для оптимизатора и в конкретной ситуации — да, а для программиста и в общем случае — как раз нет.

> Это даёт оценку более приближенную к времени выполнения

Только для ответа на вопросы для "общих случаев" это просто бесполезные подробности, нет?

Для программиста удобно сравниватьO(N) и O(N*N). Это да. а вот сравниние O(N) и O(2N). что лучше? Или другой вопрос, а может время выполнения O(N*N) быть на каком-то наборе лучше, чем O(N)? Или вот может один O(N) быть существенно быстрее чем другой O(N)? ведь может

> что лучше?

По асимптотике — одинаково, да. Но см. ниже.

> может время выполнения O(N*N) быть на каком-то наборе лучше, чем O(N)?

Может.

> Или вот может один O(N) быть существенно быстрее чем другой O(N)?

И тоже может.

Вопрос в том, что почти всегда всё это несущественно — при N=5 все подходы примерно одинаково хороши (в контексте СУБД — почти всегда всё равно, происходит ли доступ к таблице размером 32 kB по индексу или нет), а при N → ∞ (или вообще к какому-то практически "большому" значению) асимптотика "перебивает" все константы. ;)

а вопрос же часто в том, что выбрать при N = 5000. Например Hash Join или Nested Loop. Т.е как выбрать это оптимизатору?. При стремлении к бесконечности вопросов, конечно нет. тут можно пологаться на Big O. Все же еще вопрос. Как выбрать, даже при стремдении к бескочнености между одинаковыми O?

Хотя, справедливости ради, из этого правила есть исключения (см. https://en.wikipedia.org/wiki/Galactic_algorithm ), особенно тогда, когда наборы входных данных не равновероятны.
И последнее есть даже в контексте СУБД — при сравнении производительности hash ( O(1) ) и b-tree ( O(log N) ) indexes (в тех ситуациях, когда оба применимы) почти в любой практической ситуации выигрывают, внезапно, b-tree.

Вопрос-то был другой: https://t.me/dba_ru/137426

> Т.е как выбрать это оптимизатору?

Хотя бы сравнением оценочной стоимости (как делают примерно все).
Хотя, в идеале, неплохо бы сравнивать и риски, но так не делает [примерно] никто. ;(

> тут можно пологаться на Big O.

И тоже нельзя, кстати. Потому что в реальности "константа" в hash join — совсем не константа (т.е., строго говоря, hash join — это почти всегда набор методов "под одной крышей" (одним названием, и даже зачастую одним типом узла в плане запроса)).

> Как выбрать, даже при стремдении к бескочнености между одинаковыми O?

В простых случаях ответ очевиден, в сложных — придётся разбираться с алгоритмами и данными.

все же почему опитимизаторы не используют Big O?

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

И да, некоторые оптимизаторы как раз используют в некоторых ситуациях (к примеру, trivial plans в MS SQL).
Идея состоит в том, что, например, для запроса вроде SELECT * FROM a_table WHERE pk_column = 2 выбор по этому первичному ключу — это почти всегда наилучший план (а даже если нет, то это несущественно, как я уже писал выше), зачем тут стоимости-то считать? Ну и так далее — в некоторых ситуациях наилучшие планы очевидны.

Здравствуйте. Подскажите пожалуйста.  Какую секцию SQL-реплики (или команду)  нужно использовать для обеспечения отсутствия прямого сканирования таблиц (т.н. TABLE SCAN)?

trivial plans мне скорее напомнил rule based optimizator чем Big O

Согласен. Но сами-то rule based optimizers на чём основаны? ;)

О какой СУБД вообще вопрос?

mySql

Ну смотри.

«каждый объект travels уникален» -- из этого напрашивается вывод, что по объекту travels навряд ли будут искать. Скорее всего они там будут селектить юзверей и для них вытаскивать их travels (один юзер - много тревелс).

Поиск юзера по каким-то параметрам -- это как ни крути (граф или рдбмс) поиск по индексу (хеш, битри, что угодно). Это занимает время, конечно, не так много, как линейный поиск, но всё равно не так быстро.

Разница начинается дальше. Когда мы нашли нужного юзера в рдбмс и хотим вытащить все его тревелсы, нам придется делать ещё один поиск по индексу, где в качестве ключа будет id пользователя.
В случае графа, у каждого юзера лежит указатель на массив переменной длины, в котором лежат указатели на все узлы (объекты) travels. И никакого индексного поиска делать уже не нужно. Смекаешь? Вытащив одного пользователя мы сразу имеем все его тревелсы под рукой.

Не говоря уже о том, что сами по себе travels включают в себя cities, rivers, ... И когда «они» захотят прикрутить поиск по «а какие юзеры в прошлом году ездили и в Торонто, и на Амазонку, но при этом не отметили experience как "good"» это только накинет (в случае рдбмс) ещё дорогих индексов в памяти (придется их создавать, хранить, обновлять при круд, ...) и индекс траверсов при селекте (о боже, да это начнет выполняться в сотни раз медленнее, чем на графе).

Такого ответа тебе достаточно?
P.S ну вот, я же говорил: https://t.me/dba_ru/137403

Заорал уже на смекаешь

Во-первых не будет ничего в графовой базе прямо в записи лежать. В графе эдж это отдельная сущность.

Как ты себе это представляешь? Обновлять родительскую запись на каждую новую связь? А что такое родительская? А если есть родительская, то как от детей к родителям прыгать?

Снова академические знания уровня «модели и структуры данных» или пойдем в исходники посмотрим?