1. Введение

Каждая база данных SQLite содержит единственную таблицу "schema", которая хранит схему для той базы данных. Схема для базы данных это описание всех других таблиц, индексов, триггеров и обзоров, которые содержатся в базе данных. Таблица схемы похожа на это:

CREATE TABLE sqlite_schema(type text, name text, tbl_name text,
                           rootpage integer, sql text);

Таблица sqlite_schema содержит одну строку для каждой таблицы, индекса, представления и триггера в схеме, нет никакого входа для самой таблицы sqlite_schema. См. schema storage здесь для получения дополнительной информации о том, как SQLite использует таблицу sqlite_schema внутренне.

2. Альтернативные имена

На таблицу схемы можно всегда ссылаться, используя имя "sqlite_schema", особенно если схему называют как "main.sqlite_schema" или "temp.sqlite_schema". Но для исторической совместимости, некоторые альтернативные имена также признаны, включая:

1. sqlite_master
2. sqlite_temp_schema
3. sqlite_temp_master

Альтернативы (2) и (3) применимы только для базы данных TEMP, связанной с каждым соединением с базой данных, но альтернатива (1) работают где угодно. По историческим причинам, отзывы от sqlite3_set_authorizer() всегда относятся к таблице schema, используя имена (1) или (3).

3. Интерпретация таблицы Schema

Значения областей таблицы схемы следующие:

type

Столбец sqlite_schema.type будет одной из следующих текстовых строк: 'table', 'index', 'view' или 'trigger' согласно типу объекта. 'table' используется для обычных и для виртуальных таблиц.

name

Столбец sqlite_schema.name будет содержать название объекта. Ограничения UNIQUE и PRIMARY KEY заставляют SQLite создавать внутренние индексы с названиями формы "sqlite_autoindex_TABLE_N", где TABLE заменяется названием таблицы, которая содержит ограничение, а N это целое число, начинающееся с 1 и увеличивающееся на единицу с каждым ограничением в определении таблицы. В таблице WITHOUT ROWID нет никакой записи sqlite_schema для PRIMARY KEY, но имя "sqlite_autoindex_TABLE_N" обойдено для PRIMARY KEY, как будто запись sqlite_schema есть. Это затронет нумерацию последующих ограничений UNIQUE. Имя "sqlite_autoindex_TABLE_N" никогда не ассигнуется для INTEGER PRIMARY KEY в таблицах rowid или WITHOUT ROWID.

tbl_name

Столбец sqlite_schema.tbl_name содержит название таблицы или обзора, с которым связан объект. Для таблицы или представления столбец tbl_name это копия колонки имени. Для индекса tbl_name это название таблицы, которая внесена в указатель. Для триггера tbl_name хранит название таблицы или обзора, который заставляет триггер работать.

rootpage

sqlite_schema.rootpage хранит номер страницы корня b-tree для таблиц и индексов. Для строк, которые определяют обзоры, триггеры и виртуальные таблицы, rootpage 0 или NULL.

sql

sqlite_schema.sql хранит код на SQL, который описывает объект. Этот код на SQL это CREATE TABLE, CREATE VIRTUAL TABLE, CREATE INDEX, CREATE VIEW или CREATE TRIGGER, который, если оценен для файла базы данных, когда это главная база данных соединения, воссоздал бы объект. Текст обычно просто копия оригинального запроса, используемого, чтобы создать объект, но с нормализацией, примененной так, чтобы текст соответствовал следующим правилам:

• CREATE, TABLE, VIEW, TRIGGER и INDEX в начале преобразовываются во все прописные буквы.
• TEMP или TEMPORARY удалено, если оно происходит после начального ключевого слова CREATE.
• Любой определитель имени базы данных, который происходит до названия создаваемого объекта, удален.
• Удалены ведущие пробелы.
• Все пробелы после первых двух ключевых слов преобразовываются в одиночный пробел.

Текст в sqlite_schema.sql это копия оригинального текста инструкции CREATE, которая создала объект, кроме нормализации, как описано выше, и как изменено последующими ALTER TABLE. sqlite_schema.sql = NULL для внутренних индексов, которые автоматически создаются ограничениями UNIQUE или PRIMARY KEY.

4. Создание и модификация схемы

SQLite составляет таблицу схемы после создания базы данных и изменяет ее содержание, поскольку пользователи SQLite представляют запросы DDL для выполнения. Нет никакой потребности изменить таблицу при нормальных обстоятельствах, и пользователи имеют риск таким образом повредить БД.