Pull to refresh

Comments 21

Я б тогда сделал голосвание, есть ли на хабре еще кодеры, не способные читать доку на английском. Может тогда какой-то смысл в этом переводе появится.
В любых перевода всегда есть смысл. Минимум для того, кто переводил. В этом случае есть плюс для меня лично, к автору никак не относящемуся, и базу эту использовал последний раз не меньше 5 лет назад. А все равно было интереснее читать, чем обзор нового телефона и перделки-свистелки на ардуино.
Да вы батенька эгоист! Среди такого населения как программисты, есть довольно таки большая прослойка как «начинающие», которые только знакомятся с той или иной технологией, ЯП, СУБД или еще чем либо. И раз такой знаток английского языка (что является сомнительным фактом), как ты может сидеть и спокойно читать документацию на англ, не многие начинающие готовы убивать время на перевод литературы, а если готовы, то это занимает время!

P.S. хабру читают только кодеры, которые способны свободно читать не отечественную документацию!? Ой, простите, видимо я не на тот ресурс забрел!
В таблице 1 по смещению 16 наверное должно быть 0х09 и 0х0F? (9я и 15я степень двойки)
Да верно, сформулировано некорректно. Исправил. Спасибо! Для лайка кармы не хватает, увы(((
Вы таки неправильно исправили. Не FF, а 0F (15)
Каждая запись в «index B – tree» состоит из произвольного ключа до 2147483647 байт в длину без данных.
А я-то думал, что там 64 бита данных, соответствующих ROWID записи…
Каждая таблица без rowId, представлена в базе в виде «index B – tree». Ключом для дерева является PRIMARY KEY.
Э… а остальные-то данные где хранятся, коли мы уже выяснили, что данных в index B–tree нет?
Ответ ниже, промахнулся слегка, получилось просто комментом((
Разобрался, откуда взялось недопонимание относительно этих самых index b-tree.

Перевод-то далеко не полный. Сравните:
2.4 Representation of WITHOUT ROWID Tables

If an SQL table is created using the «WITHOUT ROWID» clause at the end of its CREATE TABLE statement, then that table is a WITHOUT ROWID table and uses a different on-disk representation. A WITHOUT ROWID table uses an index b-tree rather than a table b-tree for storage. The key for each entry in the WITHOUT ROWID b-tree is a record composed of the columns of the PRIMARY KEY followed by all remaining columns of the table. The primary key columns appear in the order they they were declared in the PRIMARY KEY clause and the remaining columns appear in the order they occur in the CREATE TABLE statement.

Hence, the content encoding for a WITHOUT ROWID table is the same as the content encoding for an ordinary rowid table, except that the order of the columns is rearranged so that PRIMARY KEY columns come first, and the content is used as the key in an index b-tree rather than as the data in a table b-tree. The special encoding rules for columns with REAL affinity apply to WITHOUT ROWID tables the same as they do with rowid tables.

Table without ROWID

Каждая таблица без rowId, представлена в базе в виде «index B – tree». Ключом для дерева является PRIMARY KEY.


Как следует из английского текста, ключом для index B-tree является ключ таблицы, в конец которого дописываются все остальные, неключевые, поля. Выделенный фрагмент крайне важен, и не понятно, как автор вообще умудрился его пропустить.
Ну вот как то смог) Теперь подскажите, тогда как все же дело обстоит:

ключом для index B-tree является ключ таблицы, в конец которого дописываются все остальные, неключевые, поля


А в куда в конец? На листе то что в итоге хранится?

P.S. уж извиняйте, мои познания английского не столь глубокие как ваши, так что помогите пожалуйста разобраться и соответственно исправить пост!
Лучше приведу пример. Допустим, есть таблица CREATE TABLE ex25(a,b,c,d,e,PRIMARY KEY(d,c,a)) WITHOUT rowid;.
Тогда ее физическим представлением будет индексное B-дерево с таким вот составным ключом: (d,c,a, b,e).
А для этой же таблицы CREATE TABLE ex25(a,b,c,d,e), что тогда будет лежать на листьях table b- tree?
И у меня у самого возник вопрос, а как тогда спустившись по дереву получить физическую страницу?
На листьях табличного B-дерева лежат строки таблицы, то есть пятерки (a,b,c,d,e), это же очевидно.
P.S. уж извиняйте, но ваш «перевод», который следовало бы назвать пересказом, надо не исправлять, а делать заного — а желания этим заниматься у меня нет.
Косяк то только в дереве и freelist, потому что я сам не до конца понял что к чему. Зачем же так категорично-то!
А я-то думал, что там 64 бита данных, соответствующих ROWID записи…

Прочитайте внимательней раздел Representation. Для дерева index b — tree ключом является PRIMARY KEY!

Э… а остальные-то данные где хранятся, коли мы уже выяснили, что данных в index B–tree нет?

В дереве index b — tree на листьях хранятся ссылки страницы данных, а в table b — tree сами страницы данных. То есть не нужно путать запись страницы дерева, и страницы данных в базе.

P.S. на оф. сайте при использовании данных терминов ссылаются на книгу Кнута: The Art Of Computer Programming, Volume 3 «Sorting and Searching», pages 471-479
Прочитайте внимательней раздел Representation. Для дерева index b — tree ключом является PRIMARY KEY!
Прочитайте внимательнее, я спрашивал про данные, а не про ключ. Кстати, в том же разделе Representation «index b-tree» упоминается два раза, а не один.

В дереве index b — tree на листьях хранятся ссылки страницы данных, а в table b — tree сами страницы данных. То есть не нужно путать запись страницы дерева, и страницы данных в базе.
И чем же является эта самая «ссылка страницы данных»? Я-то думал, что это и есть ROWID.

P.S. на оф. сайте при использовании данных терминов ссылаются на книгу Кнута: The Art Of Computer Programming, Volume 3 «Sorting and Searching», pages 471-479
Спасибо, читал.
UFO just landed and posted this here
Почему естественно? Для не очень больших настольных приложений очень даже хороший вариант. Или для чего вы ее не используете в продакш?
Если продакшн=сайт, то «не очень большим» он не может быть никак.
UFO just landed and posted this here
Only those users with full accounts are able to leave comments. Log in, please.