SQLite3 для целей сериализации

Question

Последние пару дней я возился с SQLite3, и кажется, что это неплохая база данных, но мне интересно узнать, как она используется для сериализации.

Мне нужно сериализовать набор пар ключ / значение, которые связаны с другой таблицей, и я так и делал до сих пор.

Сначала будет таблица предметов:

CREATE TABLE items (id INTEGER PRIMARY KEY, details);

 | id | details |
-+----+---------+
 |  1 | 'test'  |
-+----+---------+
 |  2 | 'hello' |
-+----+---------+
 |  3 | 'abc'   |
-+----+---------+

Тогда будет таблица для каждого предмета:

CREATE TABLE itemkv## (key TEXT, value);  -- where ## is an 'id' field in TABLE items

 | key | value |
-+-----+-------+
 |'abc'|'hello'|
-+-----+-------+
 |'def'|'world'|
-+-----+-------+
 |'ghi'| 90001 |
-+-----+-------+

Это работало нормально, пока я не заметил, что для каждого стола были накладные расходы в один килобайт. Если бы я имел дело только с несколькими предметами, это было бы приемлемо, но мне нужна система, которая может масштабироваться.

По общему признанию, это первый раз, когда я когда-либо использовал что-либо, связанное с SQL, поэтому, возможно, я не знаю, для чего должна использоваться таблица, но я не смог найти никакого понятия о таблица "или" структура "тип данных. Теоретически, я мог бы преобразовать пары ключ / значение в строку, например, «abc | hello \ ndef | world \ nghi | 90001», и сохранить ее в столбце, но это заставляет меня задуматься, не противоречит ли это цели использования базы данных во-первых, если я собираюсь преобразовать свои структуры во что-то, что может быть так же легко сохранено в плоском файле.

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

Answer 1

Вы можете попробовать PRAGMA page_size = 512; до создания БД, или до создания первой таблицы, или до выполнения оператора VACUUM. (Руководство немного противоречиво и зависит от версии sqlite3.)

Я думаю, что также довольно редко можно создавать таблицы динамически с высокой скоростью. Хорошо, что вы нормализуете свою схему, но нормально, если столбцы зависят от первичного ключа, и, хотя повторяющиеся группы являются признаком более низкого уровня нормализации, внешние ключи обычно повторяются в приемлемой схеме. То есть, я думаю, есть хорошая вероятность, что вам нужна только одна таблица пар ключ / значение с колонкой, идентифицирующей экземпляр клиента.

Имейте в виду, что для плоских файлов также выделяются единицы размещения. Посмотрите, что происходит, когда я создаю однобайтовый файл:

$ cat > /tmp/one

$ ls -l /tmp/one
-rw-r--r-- 1 ross ross 1 2009-10-11 13:18 /tmp/one
$ du -h /tmp/one
4.0K    /tmp/one
$ 

Согласно ls(1) это один байт, согласно du(1) это 4K.

Answer 2

Не составлять таблицу на предмет. Это просто неправильно. Аналогично написанию класса для каждого элемента в вашей программе. Создайте одну таблицу для всех элементов или, возможно, сохраните общие части всех элементов, а другие таблицы ссылаются на нее с дополнительной информацией. Сделайте себе одолжение и ознакомьтесь с правилами нормализации базы данных.

Как правило, таблицы в вашей базе данных должны быть исправлены так же, как и классы в вашей C ++ программе.

Answer 3

Если это просто сериализация, то есть одноразовое сохранение на диск и затем одноразовое восстановление с диска, вы можете использовать JSON (список рекомендованных библиотек C ++ ).

Просто сериализовать структуру данных:

[
  {'id':1,'details':'test','items':{'abc':'hello','def':'world','ghi':'90001'}},
  ...
]

Если вы хотите сохранить несколько байтов, вы можете опустить клавиши id, details и items и вместо этого сохранить список: (в случае, если это узкое место):

[
  [1,'test', {'abc':'hello','def':'world','ghi':'90001'}],
  ...
]

Answer 4

Почему бы просто не сохранить внешний ключ в таблице предметов?

Create Table ItemsVK (ID integer primary key, ItemID integer, Key Text, value Text)