Page 1 of 15

настройки в sqlite

Posted: Fri 18 Mar, 2011 17:31
by t-rex
играюсь тут с переходом хранения настроек в sqlite. так как в sql я довольно слаб нужна помощь.

для начала, говорим только об настройках плагинов - т.е. древовидная структара с values любого типа.

значит, вот что я смог сделать для описания таблиц (по общей идеи zg):

Code: Select all

pragma foreign_keys = ON;
create table if not exists plugin_keys(id INTEGER PRIMARY KEY ASC, parent_id INTEGER, name TEXT NOT NULL, FOREIGN KEY(parent_id) REFERENCES plugin_keys(id) ON UPDATE CASCADE ON DELETE CASCADE);
create unique index if not exists plugin_keys_i1 on plugin_keys(parent_id,name);
create table if not exists plugin_values(id INTEGER PRIMARY KEY ASC, key_id INTEGER, name TEXT NOT NULL, type INTEGER NOT NULL, value BLOB, FOREIGN KEY(key_id) REFERENCES plugin_keys(id) ON UPDATE CASCADE ON DELETE CASCADE);
create unique index if not exists plugin_values_i1 on plugin_values(key_id,name);
для plugin_keys, id корня == NULL
для plugin_values, type это скажем 0-int64, 1-string, 2-binary

тут типа всё нормально, не? нужен ли вообще id для plugin_values?

теперь надо понять как правильно делать insert, delete и т.п., кто тут у нас sql (sqlite) спец?

например, как правильно "обновлять" существующий value? если у values всё таки есть id, должен ли он изменятся при replace или нет?

Примечание модератора
Смежная тема: FAR 3: (со)хранение конфигурации (настроек, истории, сеанса)

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 17:45
by HaRT
А действительно ли нужна древовидная структура именно в БД?
Не достаточно ли будет её эмулировать названиями вида Level1.Level2.Level3.OptionName?

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 17:52
by zg
HaRT wrote:А действительно ли нужна древовидная структура именно в БД?
Не достаточно ли будет её эмулировать названиями вида Level1.Level2.Level3.OptionName?
а зачем эти проблемы с разбиением строк? опять же кто-то в имени точку заюзает.

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 17:56
by t-rex
небольшая поправка,
create table if not exists plugin_values(id INTEGER PRIMARY KEY ASC, key_id INTEGER NOT NULL, name TEXT NOT NULL, type INTEGER NOT NULL, value BLOB, FOREIGN KEY(key_id) REFERENCES plugin_keys(id) ON UPDATE CASCADE ON DELETE CASCADE);

чтоб нельзя было создавать values в корне.

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 17:57
by zg
t-rex wrote:например, как правильно "обновлять" существующий value? если у values всё таки есть id, должен ли он изменятся при replace или нет?
нет.

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 18:02
by chupakabra
играюсь тут с переходом хранения настроек в sqlite
Может лучше текстовый файл использовать? Чтобы было проще смотреть/редактировать?

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 18:04
by HaRT
zg wrote:а зачем эти проблемы с разбиением строк? опять же кто-то в имени точку заюзает.
На мой взгляд, древовидная структура здесь неоправданно усложнит структуру базы и SQL-запросов. Или предполагается иметь во многих ключах десятки тысяч значений?

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 18:08
by ctapmex
нужен ли вообще id для plugin_values?
а это зависит от того, что будет хранить фар в памяти для быстрого доступа
либо по id быстро и однозначно найдем/удалим/проапдейтим, либо все это придется делать ищя по имени и key_id. а это уже медленнее. но объем данных небольшой, может существенно и не сыграет роли.

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 18:19
by t-rex
тут конечно надо ещё понять как это всё будет работать с несколькими копиями фара

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 18:30
by zg
HaRT wrote:
zg wrote:а зачем эти проблемы с разбиением строк? опять же кто-то в имени точку заюзает.
На мой взгляд, древовидная структура здесь неоправданно усложнит структуру базы и SQL-запросов.
тот же SCTL_SUBKEY очень легко ложится на древовидную структуру. даже в памяти ничего хранить не надо. вообще root во всем сеттингс апи это plugin_keys.id. а вот со строками придётся возится. тот же енум и удаление будут тяжелее чем в варианте с деревом. плюс расход памяти на поддержку SCTL_SUBKEY.

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 18:36
by NightRoman
t-rex wrote:тут конечно надо ещё понять как это всё будет работать с несколькими копиями фара
Я не спец, но википедия говорит, что читать могут несколько пользователей сразу, а писать только один в данный момент. Конфликтов почти никогда быть не должно, ибо запись будет обычно в результате каких-то действий юзера происходить, а он в данный момент только с одной копией Фара и работает.

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 18:39
by ctapmex
t-rex wrote:тут конечно надо ещё понять как это всё будет работать с несколькими копиями фара
да скорее всего так же, как и с реестром. при коротких транзакциях на апдейт, блокировок не должно возникнуть.

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 18:40
by ctapmex
HaRT wrote:На мой взгляд, древовидная структура здесь неоправданно усложнит структуру базы и SQL-запросов. Или предполагается иметь во многих ключах десятки тысяч значений?
усложнит правку руками на прямую. или поиск глазами по таблице. а так древовидная структура для базы данных оптимальна

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 21:32
by Max Rusov
t-rex wrote:играюсь тут с переходом хранения настроек в sqlite
Умеретьневстать. Только от реестра избавляться начали - новая напасть...

Re: настройки в sqlite

Posted: Fri 18 Mar, 2011 21:41
by Skirda
Max Rusov wrote:
t-rex wrote:играюсь тут с переходом хранения настроек в sqlite
Умеретьневстать. Только от реестра избавляться начали - новая напасть...
А почему нет?
Все рядом. Не более 500 кг прибавки к весу.
А ви таки придлагаете хмл? Таки это те же грабли, только вид с боку.

Я в интриге :popcorn: