|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
scfО каком типе индекса идет речь? Назовите алгоритм или название базы+название типа индекса. MS SQL Server. B-tree. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2014, 23:35 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
pkarklinscf, Восстановите мне, пожалуйста, исходные данные индекса, полученного перемножением двух интовых полей, в значение ключа которого 12. Не, они видите что говорит, что помимо того что индекс будет построен, так ещё в листьях индекса будет храниться это число 12, это помимо двух интовых полей :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2014, 23:35 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
pkarklinscfО каком типе индекса идет речь? Назовите алгоритм или название базы+название типа индекса. MS SQL Server. B-tree. Отлично, а при чем тут перемножение целых чисел? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2014, 23:38 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
scfОтлично, а при чем тут перемножение целых чисел? Приведите другой пример, такого индекса: scfТ.е. такие колонки можно использовать в WHERE (по ним есть индекс) но нельзя использовать в SELECT (в них нет данных). Смысл том, чтобы хранить в базе только индекс для ускорения работы и уменьшения размера базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2014, 23:47 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovFunction Based Index - в любой приличной СУБД.В MySQL нету. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2014, 23:48 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
scfПервая строчка из цитаты относится к B-tree Вторая строчка из цитаты относится к case-insensitive индексам А Вы, стало быть, утверждаете, что B-tree индексы не могут быть регистронечуствительными. Ню-ню... PS: А вообще, я сильно сомневаюсь, что какая нибудь СУБД позволит создать таблицу, которая гарантированно не переживёт export-import, которую нельзя задействовать в репликации или standby. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2014, 23:51 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
pkarklinscfО каком типе индекса идет речь? Назовите алгоритм или название базы+название типа индекса. MS SQL Server. B-tree. B+ Tree ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2014, 05:52 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
scfкак колонки, которые не хранят вставленные данные, но по которым можно строить индексы. <>кхм, стесняюсь спьясить, мальчик , ты дуяк ? в общем ты хочешь index (F(x)) но так, чтобы от хранимого в индексе F(x) было затруднительно на стороне сервера, не зная способа F делать x= F -1 (Y), но при этом уметь таки поиск по x. (т.е. знать таки F) --> противоречие которое частично снимается "алгоритимически сложным" кодированием/декодированием. но кодировать все равно должно быть возможно на стороне делающей where F(x). А вот декодиявать должно быть алгоитмически сьёжно ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2014, 08:25 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
scf В каких СУБД есть такая штука как колонки, которые не хранят вставленные данные, но по которым можно строить индексы. Т.е. такие колонки можно использовать в WHERE (по ним есть индекс) но нельзя использовать в SELECT (в них нет данных). Смысл том, чтобы хранить в базе только индекс для ускорения работы и уменьшения размера базы. Это может быть полезно, например, для построения индексов для данных, хранящихся в виде BLOB-ов.СУБД Caché (разделы "Скрытие чувствительных данных") Я такую штуку использовал именно для индексации blob-ов (фото), для быстрого поиска похожих лиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2014, 10:03 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
То есть речь все-таки не про индексы без данных, а про индексы, построенные по существующим где-либо (не обязательно в данной БД) данным? Если так, то эти индексы - не индексы, а данные, по которым при желании можно еще построить индексы. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2014, 10:18 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
scfкак колонки, которые не хранят вставленные данные, но по которым можно строить индексы. Т.е. такие колонки можно использовать в WHERE (по ним есть индекс) но нельзя использовать в SELECT (в них нет данных). Смысл том, чтобы хранить в базе только индекс для ускорения работы и уменьшения размера базы. Это может быть полезно, например, для построения индексов для данных, хранящихся в виде BLOB-ов. в Virtuoso реализованы индексы без ссылки на исходную запись . нужно это тупо для экономии места, т.е.такой индекс может использоваться только как покрывающий (запрос). но тем не менее в Select list его можно использовать, как и в Where. это вообще странное требование автора вопроса. в FBI и индексах на выражения в оракл такое соблюдается, но автору все равно вроде не нравится. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2014, 07:31 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
кхмв общем ты хочешь index (F(x)) но так, чтобы от хранимого в индексе F(x) было затруднительно на стороне сервера, не зная способа F делать x= F -1 (Y), но при этом уметь таки поиск по x. Нет - человек хочет поиск по F(X). Другими словами ему нужен виртуальные столбцы {x} в которые он будет записывать значения, а в хранится будет только F({x}). Собственно в том же Oracle делается при помощи View поверх IOT с полем F и instead of триггерах on insert,update, в которых :new.F=F({x}). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 13:06 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
Сергей Арсеньевкхмв общем ты хочешь index (F(x)) но так, чтобы от хранимого в индексе F(x) было затруднительно на стороне сервера, не зная способа F делать x= F -1 (Y), но при этом уметь таки поиск по x. Нет - человек хочет поиск по F(X). Другими словами ему нужен виртуальные столбцы {x} в которые он будет записывать значения, а в хранится будет только F({x}). Собственно в том же Oracle делается при помощи View поверх IOT с полем F и instead of триггерах on insert,update, в которых :new.F=F({x}).тот же хрен, вид сбоку он хочет по табле с индексом F(x) искать , имея на руках x , а не F(x). т.е. он на руках должен иметь и саму производящую ф-ю F() [но хочет иметь проблемы с восстановлением x из F]. об чем и речь. ну там еще ф-ии бывают типа биекциями, и типа нет (кодирование с потерей данных). он кажется таки хочет без потери. А это значит, что он на руках должен иметь и производящую ф-ю, которой достаточно для восстановления обратной (хотя бы на конечном мн-ве значений), но , разве что, алгоритмически затруднено. Т.е. он, де факто, битым, но алгоритмически трудно-восстановимым словом хранит в таблице собственно и именно само "x" ну, и т.п. а что там делает ара-кал, и куда он пошёл -- это дело десятое. "вопрос реализации" , с чем у ларри большие успехи. в некотором смысле. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 13:21 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
кхмтот же хрен, вид сбоку Функцию то он знает. Поэтому можно сделать where F_field=F(X) . В, принципе, в СУБД, в которых есть табличные функции, можно сделать выборку из табличной функции, которая будет принимать параметры и строить таблицу с результатом, спрятав вышеуказанное условие, только с теми полями, которые храняться. Что-то типа select * from table(giv_me_table({x})) даже в where не нужно ничего указывать. Ну или использовать СУБД с переопределяемыми на лету запросами (которые вместо одного подставляют другой). Только вот зачем? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 15:16 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
Нет, никаких функций. Идея этого вопроса в том, что для поиска по b-tree индексу чтение собственно строки данных не требуется, даже если нужная колонка не перенесена в индекс. Контр-довод, который я смог найти: такая штука будет плохо работать с селектом по двум полям. Это обычно резолвится в выборку по первому индексу + table scan, а в моем случае получаем безальтернативно выборку по каждому индексу и их hash join, что намного затратнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 22:42 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
scfНет, никаких функций. Идея этого вопроса в том, что для поиска по b-tree индексу чтение собственно строки данных не требуется, даже если нужная колонка не перенесена в индекс. Контр-довод, который я смог найти: такая штука будет плохо работать с селектом по двум полям. Это обычно резолвится в выборку по первому индексу + table scan, а в моем случае получаем безальтернативно выборку по каждому индексу и их hash join, что намного затратнее. Ответьте четко на 3 вопроса: 1. Что такое Index Only Scan? 2. Что содержится в B-tree индексе, перечислите? 2.a) b-tree (сам индекс) 2.b) помимо самого индекса, в листьях содержаться ещё и поля по которым он построен 2.c) в листьях rowid (ссылка на строку в таблице) 3. Что содержится в Index Organized Table? 3.a) b-tree (сам индекс) 3.b) помимо самого индекса, в листьях содержаться ещё и поля по которым он построен 3.c) в листьях остальные столбцы, исключая индекс Если в 2 нет 2.b), то в 3 так же нет 3.b), т.к. формально эти структуры идентичны, т.е. IOT - то что вы ищете (а возможность получать поля в select просто приятный бонус, который вам не нужен). Если в 2 нет 2.b), то Index Only Scan - это получение в select полей содержащихся исключительно в самом B-tree индексе, а не в его листьях? Есть ли 2.b) в 2? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 23:01 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
Вася Уткин, 1. как подсказал гугль: https://wiki.postgresql.org/wiki/Index-only_scans "Btree indexes contain what are technically redundant copies of the column data that is indexed." Я так думаю, что 2.c Судя по докам оракла, 3.b Насчет того, что IOT - это то, что мне нужно. b-tree - это дерево, проходом по которому из вершины в лист можно "собрать" значение, по которому этот индекс был построен. Судя по вышеприведенной доке постгреса, они именно это и делают. оракловый IOT меня смущает тем, что в документации *явно* написано, что в индекс включают данные колонки, что избыточно (см. цитату в кавычках выше) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 23:20 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
Вася Уткин, Вообще Index Only Scan - это, похоже, именно то, что я ищу. Разве что без опции "не хранить эти данные в таблице". Есть ли аналогичная штука в оракле? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 23:22 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
http://www.dba-oracle.com/concepts/index_only_tables.htm Вот интересная ссылка в тему... ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 23:26 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
scfВася Уткин, 1. как подсказал гугль: https://wiki.postgresql.org/wiki/Index-only_scans "Btree indexes contain what are technically redundant copies of the column data that is indexed." Я так думаю, что 2.c Судя по докам оракла, 3.b Насчет того, что IOT - это то, что мне нужно. b-tree - это дерево, проходом по которому из вершины в лист можно "собрать" значение, по которому этот индекс был построен. Судя по вышеприведенной доке постгреса, они именно это и делают. оракловый IOT меня смущает тем, что в документации *явно* написано, что в индекс включают данные колонки, что избыточно (см. цитату в кавычках выше) Как вы перевели эту цитату? В оракловой документации "*явно* написано", что содержится явно копия поля , или что содержится само поле? Если "содержится само поле", то это и означает, что "дерево, проходом по которому из вершины в лист можно "собрать" значение, по которому этот индекс был построен." ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 23:30 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
scfb-tree - это дерево, проходом по которому из вершины в лист можно "собрать" значение, по которому этот индекс был построен. В общем случае - нельзя. Потому что индекс строится не по значению, а по ключу. Преобразование значения в ключ может быть, а может и не быть обратимым. Так что из индекса можно получить ключ, но не значение. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 23:33 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
scfВася Уткин, Вообще Index Only Scan - это, похоже, именно то, что я ищу. Разве что без опции "не хранить эти данные в таблице". Есть ли аналогичная штука в оракле? Да, долго IOS (в виш листах лет 5 наверно висел) и no-logged tables рожали в PostgreSQL, но если бы ещё запилили и Intra Query Parallelism - стало возможным использовать PostgreSQL в ETL/DWH :) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 23:34 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovscfb-tree - это дерево, проходом по которому из вершины в лист можно "собрать" значение, по которому этот индекс был построен. В общем случае - нельзя. Потому что индекс строится не по значению, а по ключу. Преобразование значения в ключ может быть, а может и не быть обратимым. Так что из индекса можно получить ключ , но не значение . А значение ключа можно получить? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 23:35 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
Я так понял, что под "значением" подразумевается значение колонки, а под "ключом" - преобразованное значение, по которому строится индекс и которое собственно в этом индексе ищется. Например, ключ = uppercase(значение) для case-insensitive индексов. Но дело-то в том, что читать "значение" мне нафиг не нужно) Мне бы только rowid узнать, чтобы мирно прочитать мой блоб из тейблспейса. Насчет IOT - я так думаю, что данные все-таки дублируются, т.е. хранятся и в индексе, и в таблице. Иначе full scan таблицы потребует чтения из двух разных мест. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 23:41 |
|
В каких СУБД есть такая штука...
|
|||
---|---|---|---|
#18+
scfЯ так понял, что под "значением" подразумевается значение колонки, а под "ключом" - преобразованное значение, по которому строится индекс и которое собственно в этом индексе ищется. Например, ключ = uppercase(значение) для case-insensitive индексов. Но дело-то в том, что читать "значение" мне нафиг не нужно) Мне бы только rowid узнать, чтобы мирно прочитать мой блоб из тейблспейса. Насчет IOT - я так думаю, что данные все-таки дублируются, т.е. хранятся и в индексе, и в таблице. Иначе full scan таблицы потребует чтения из двух разных мест . IOT - это B-tree индекс в листьях которого нет rowid, но есть все поля за исключением содержащихся в индекс, т.е. IOT это одна структура в которой все есть, какие ещё два разных места? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2014, 23:46 |
|
|
start [/forum/topic.php?fid=35&msg=38828866&tid=1552350]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 144ms |
0 / 0 |