rpsv20 мая 2014 в 02:56

Файловое строение SQLite

4 мин

43K

SQLite *

Перевод

+16

Комментарии 21

igordata 20 мая 2014 в 03:59

Я б тогда сделал голосвание, есть ли на хабре еще кодеры, не способные читать доку на английском. Может тогда какой-то смысл в этом переводе появится.

vladimirkolyada 20 мая 2014 в 05:41

В любых перевода всегда есть смысл. Минимум для того, кто переводил. В этом случае есть плюс для меня лично, к автору никак не относящемуся, и базу эту использовал последний раз не меньше 5 лет назад. А все равно было интереснее читать, чем обзор нового телефона и перделки-свистелки на ардуино.

rpsv 20 мая 2014 в 07:01

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

P.S. хабру читают только кодеры, которые способны свободно читать не отечественную документацию!? Ой, простите, видимо я не на тот ресурс забрел!

blueboar2 20 мая 2014 в 05:51

В таблице 1 по смещению 16 наверное должно быть 0х09 и 0х0F? (9я и 15я степень двойки)

rpsv 20 мая 2014 в 07:06

Да верно, сформулировано некорректно. Исправил. Спасибо! Для лайка кармы не хватает, увы(((

blueboar2 20 мая 2014 в 07:19

Вы таки неправильно исправили. Не FF, а 0F (15)

mayorovp 20 мая 2014 в 07:30

Каждая запись в «index B – tree» состоит из произвольного ключа до 2147483647 байт в длину без данных.

А я-то думал, что там 64 бита данных, соответствующих ROWID записи…

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

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

rpsv 20 мая 2014 в 08:06

Ответ ниже, промахнулся слегка, получилось просто комментом((

mayorovp 20 мая 2014 в 08:20

Разобрался, откуда взялось недопонимание относительно этих самых 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 является ключ таблицы, в конец которого дописываются все остальные, неключевые, поля. Выделенный фрагмент крайне важен, и не понятно, как автор вообще умудрился его пропустить.

rpsv 20 мая 2014 в 08:27

Ну вот как то смог) Теперь подскажите, тогда как все же дело обстоит:

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

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

P.S. уж извиняйте, мои познания английского не столь глубокие как ваши, так что помогите пожалуйста разобраться и соответственно исправить пост!

mayorovp 20 мая 2014 в 08:30

Лучше приведу пример. Допустим, есть таблица CREATE TABLE ex25(a,b,c,d,e,PRIMARY KEY(d,c,a)) WITHOUT rowid;.
Тогда ее физическим представлением будет индексное B-дерево с таким вот составным ключом: (d,c,a, b,e).

rpsv 20 мая 2014 в 08:39

А для этой же таблицы CREATE TABLE ex25(a,b,c,d,e), что тогда будет лежать на листьях table b- tree?
И у меня у самого возник вопрос, а как тогда спустившись по дереву получить физическую страницу?

mayorovp 20 мая 2014 в 11:21

На листьях табличного B-дерева лежат строки таблицы, то есть пятерки (a,b,c,d,e), это же очевидно.

mayorovp 20 мая 2014 в 08:33

P.S. уж извиняйте, но ваш «перевод», который следовало бы назвать пересказом, надо не исправлять, а делать заного — а желания этим заниматься у меня нет.

rpsv 20 мая 2014 в 08:41

Косяк то только в дереве и freelist, потому что я сам не до конца понял что к чему. Зачем же так категорично-то!

rpsv 20 мая 2014 в 07:58

А я-то думал, что там 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

mayorovp 20 мая 2014 в 08:11

Прочитайте внимательней раздел 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

Спасибо, читал.

НЛО прилетело и опубликовало эту надпись здесь

rpsv 22 мая 2014 в 16:33

Почему естественно? Для не очень больших настольных приложений очень даже хороший вариант. Или для чего вы ее не используете в продакш?

mayorovp 22 мая 2014 в 16:59

Если продакшн=сайт, то «не очень большим» он не может быть никак.

НЛО прилетело и опубликовало эту надпись здесь

Зарегистрируйтесь на Хабре, чтобы оставить комментарий