Comments 21
Я б тогда сделал голосвание, есть ли на хабре еще кодеры, не способные читать доку на английском. Может тогда какой-то смысл в этом переводе появится.
В любых перевода всегда есть смысл. Минимум для того, кто переводил. В этом случае есть плюс для меня лично, к автору никак не относящемуся, и базу эту использовал последний раз не меньше 5 лет назад. А все равно было интереснее читать, чем обзор нового телефона и перделки-свистелки на ардуино.
Да вы батенька эгоист! Среди такого населения как программисты, есть довольно таки большая прослойка как «начинающие», которые только знакомятся с той или иной технологией, ЯП, СУБД или еще чем либо. И раз такой знаток английского языка (что является сомнительным фактом), как ты может сидеть и спокойно читать документацию на англ, не многие начинающие готовы убивать время на перевод литературы, а если готовы, то это занимает время!
P.S. хабру читают только кодеры, которые способны свободно читать не отечественную документацию!? Ой, простите, видимо я не на тот ресурс забрел!
P.S. хабру читают только кодеры, которые способны свободно читать не отечественную документацию!? Ой, простите, видимо я не на тот ресурс забрел!
В таблице 1 по смещению 16 наверное должно быть 0х09 и 0х0F? (9я и 15я степень двойки)
Каждая запись в «index B – tree» состоит из произвольного ключа до 2147483647 байт в длину без данных.А я-то думал, что там 64 бита данных, соответствующих ROWID записи…
Каждая таблица без rowId, представлена в базе в виде «index B – tree». Ключом для дерева является PRIMARY KEY.Э… а остальные-то данные где хранятся, коли мы уже выяснили, что данных в index B–tree нет?
Ответ ниже, промахнулся слегка, получилось просто комментом((
Разобрался, откуда взялось недопонимание относительно этих самых 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 является ключ таблицы, в конец которого дописываются все остальные, неключевые, поля. Выделенный фрагмент крайне важен, и не понятно, как автор вообще умудрился его пропустить.
Ну вот как то смог) Теперь подскажите, тогда как все же дело обстоит:
А в куда в конец? На листе то что в итоге хранится?
P.S. уж извиняйте, мои познания английского не столь глубокие как ваши, так что помогите пожалуйста разобраться и соответственно исправить пост!
ключом для index B-tree является ключ таблицы, в конец которого дописываются все остальные, неключевые, поля
А в куда в конец? На листе то что в итоге хранится?
P.S. уж извиняйте, мои познания английского не столь глубокие как ваши, так что помогите пожалуйста разобраться и соответственно исправить пост!
Лучше приведу пример. Допустим, есть таблица
Тогда ее физическим представлением будет индексное B-дерево с таким вот составным ключом:
CREATE TABLE ex25(a,b,c,d,e,PRIMARY KEY(d,c,a)) WITHOUT rowid;.Тогда ее физическим представлением будет индексное B-дерево с таким вот составным ключом:
(d,c,a, b,e).P.S. уж извиняйте, но ваш «перевод», который следовало бы назвать пересказом, надо не исправлять, а делать заного — а желания этим заниматься у меня нет.
А я-то думал, что там 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
Sign up to leave a comment.
Файловое строение SQLite