Когда то давно, когда PC только появлялись, было такое явление как настольные СУБД. Потом их практически вытеснили SQL-сервера, и если они и есть где, то это в основном развитие старых продуктов.
SQL-сервера это конечно здорово, однако по прежнему есть ряд применений, для которых их навороты не нужны, равно как не нужен оверхед, связанный с многопользовательским доступом и сложное администрирование.
Хотелось бы обсудить как могла бы выглядеть современная настольная СУБД с учетом сужения класса решаемых задач и использования новых технологий и подходов. Более конкретный список вопросов:
1) in process или out of process?
2) Физическая структура хранения на диске — алгоритмы, разбиение на файлы etc
3) Описание метаданных
4) Способ формирования запросов
5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом
6) Алгоримты деплоймента
AndrewVK wrote: > Хотелось бы обсудить как могла бы выглядеть современная настольная СУБД > с учетом сужения класса решаемых задач и использования новых технологий > и подходов.
Как FireBird
> 1) in process или out of process?
Оба варианта.
> 2) Физическая структура хранения на диске — алгоритмы, разбиение на > файлы etc
Один файл на базу.
> 3) Описание метаданных > 4) Способ формирования запросов
Как обычно.
> 5) Контроль на уровне БД. Вобще разграничение функций между движком БД и > прикладным кодом
Как обычно.
> 6) Алгоримты деплоймента
Скопировать файлы базы и dll-ки драйвера (для inproc).
А вообще, все должно быть как можно проще и легковеснее.
Здравствуйте, Max404.NET, Вы писали:
MN>а чем msde(2005express) не устраивает?
однако по прежнему есть ряд применений, для которых их навороты не нужны, равно как не нужен оверхед, связанный с многопользовательским доступом и сложное администрирование
Здравствуйте, AndrewVK, Вы писали:
AVK>2) Физическая структура хранения на диске — алгоритмы, разбиение на файлы etc
Индексы B+ Tree, возможно со своими оптимизациями. Один файл на базу хотя возможно более хитрые варианты, тут надо от задачи плясать.
AVK>4) Способ формирования запросов
Не SQL, наверное Linq лучший вариант, чтобы с точки зрения разработчика на обычном ЯП все было прозрачно...
AVK>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом
БД должна брать на себя заботу по бакапу, восстановлению, и слежению за согласованностью внутри себя, все остальное запота прикладного кода.
Здравствуйте, Merle, Вы писали:
AVK>>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом M>БД должна брать на себя заботу по бакапу, восстановлению, и слежению за согласованностью внутри себя, все остальное запота прикладного кода.
Вопрос как раз в согласованности. Какого уровня констрейнты должны быть?
Здравствуйте, Cyberax, Вы писали:
C>AndrewVK wrote: >> Хотелось бы обсудить как могла бы выглядеть современная настольная СУБД >> с учетом сужения класса решаемых задач и использования новых технологий >> и подходов. C>Как FireBird
>> 1) in process или out of process? C>Оба варианта.
По моему лучше InProc — меньше оверхеда на взаимодействие с сервером. Очень не часто встречается одновременное юзание десктопной БД разными клиентами . А для однопользовательских вещей лишние тормоза ни к чему. >> 2) Физическая структура хранения на диске — алгоритмы, разбиение на >> файлы etc C>Один файл на базу.
Не факт.
>> 3) Описание метаданных >> 4) Способ формирования запросов C>Как обычно.
Как обычно у кого?
>> 5) Контроль на уровне БД. Вобще разграничение функций между движком БД и >> прикладным кодом C>Как обычно.
Опять же у кого?
>> 6) Алгоримты деплоймента C>Скопировать файлы базы и dll-ки драйвера (для inproc).
C>А вообще, все должно быть как можно проще и легковеснее.
AndrewVK wrote: >> > с учетом сужения класса решаемых задач и использования новых технологий >> > и подходов. > C>Как FireBird > Ты имеешь ввиду наследство Yaffil? Это совсем не то.
Нет, я имею в виду FireBird Embedded — это несколько DLLок общим объемом
в пару мегабайт. Представляют собой версию FireBird (наследник
InterBase) без сетевого стека.
http://firebird.sourceforge.net/
>> > 1) in process или out of process? > C>Оба варианта. > Аргументы?
In-proc если к базе должен иметь доступ только один процесс
одновременно. В противном случае — outproc.
>> > 2) Физическая структура хранения на диске — алгоритмы, разбиение на >> > файлы etc > C>Один файл на базу. > Аргументы?
Проще администрирование.
> C>Как обычно. > SQL?
SQL, Linq, навигационный доступ. Не вижу причин делать что-то отличное
от обычных БД.
>> > 5) Контроль на уровне БД. Вобще разграничение функций между движком БД и >> > прикладным кодом > C>Как обычно. > Нету никакого как обычно. В разных решениях по разному.
Имею в виду, что нет смысла изобретать что-то новое.
>> > 6) Алгоримты деплоймента > C>Скопировать файлы базы и dll-ки драйвера (для inproc). > Алгоритм деплоймента прикладных БД в двтжек, а не деплоймент самого движка.
Так я и говорю про деплоймент баз — в строке соединения просто
прописывается путь до файла БД. Соответственно, для деплоймента базы
просто нужно положить куда-нибудь файл.
> C>А вообще, все должно быть как можно проще и легковеснее. > И при этом ты советуешь SQL, out of process и DDL. Нестыковочка выходит.
А что, SQL уже подразумевает SQL Server?
SQLite имеет SQL-движок размером в несколько сотен килобайт, в FireBird
около мегабайта. Кстати, даже в Outlook'е есть реализация SQL-подобного
языка запросов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Когда то давно, когда PC только появлялись, было такое явление как настольные СУБД. Потом их практически вытеснили SQL-сервера, и если они и есть где, то это в основном развитие старых продуктов. AVK>SQL-сервера это конечно здорово, однако по прежнему есть ряд применений, для которых их навороты не нужны, равно как не нужен оверхед, связанный с многопользовательским доступом и сложное администрирование. AVK>Хотелось бы обсудить как могла бы выглядеть современная настольная СУБД с учетом сужения класса решаемых задач и использования новых технологий и подходов. Более конкретный список вопросов: AVK>1) in process или out of process?
Для однопользовательской INPROC для многопользовательской outproc, хотя так как все ограничено одним хостом можно обойтись только inproc с SHARED объектами разграничения доступа. AVK>2) Физическая структура хранения на диске — алгоритмы, разбиение на файлы etc
Варианты
1. Один файл но большой —
преимущества: простота распространения
недостатки: все намешано в кучу, появляються длинные Seek при чтении поиске данных что ни есть гуд.
2. Много файловая БД
а) один файл на таблицу
б) один файл на все данные
С индексами тоже самое
преимущества: можно оптимизировать файлы на предмет подгонки размера страницы под конкретные данные — меньше оверхеда на пустоту,
недостатки: Проблемы с поддержкой кучи файлов, больше используемыъ объектов ядра
Способ организации файла зависит от того по какому пути пойдем, правда в любом случае мимо B+ деревьев не пройдем, да и страничная организация данных тоже никуда не денеться. AVK>3) Описание метаданных
1. DDL — чтобы иметь текстовые определения БД
2. Метаданные в формате БД храняться в самой схеме данных БД или же лежат отдельно — как вариант отдельным файлом — описателем БД.
Зависит от того что мы хотим получить. AVK>4) Способ формирования запросов
SQL или объектные запросы можно вообще обойтись без запросов если делать сетевую БД AVK>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом
ACID поддержка транзакционности как минимум с возможностью отката в случае чего. AVK>6) Алгоримты деплоймента
копирование по месту
О первичных ключах:
1) Допустимо ли требование обязательного наличия первичного ключа?
2) Допустимо ли требование несоставного первичного ключа?
3) Допустимо ли требование первичного ключа определенного типа?
4) Допустимо ли требование первичного ключа типа GUID?
О расширяемости:
Что должно быть расширяемо в сабже?
О keysets:
1) Допустимо ли встраивание этой механики в движек БД.
2) Достаточно ли самого простого варианта, или нужна возможность подкрузки в кейсет части данных?
3) Нужна ли многостадийная загрузка или подгрузка в 2 стадии — кейсет и остальные данные? Или может еще какой вариант?
О запросах подробнее:
1) Необходим ли SQL или любой другой текстовый декларативный язык запросов?
2) Что лучше — выборки или навигационный способ(курсоры).
3) Что лучше — декларативный sql-like синтаксис или функциональный стиль?
О метаданных:
1) Допустим ли отказ от специфичных для БД метаданных в пользу метаданных, встроенных в платформу?
2) Допустим ли (и возможен ли?) полный отказ от нетипизированных данных (нетипизированных на уровне строки) при работе с БД?
3) Должны ли типы хранится в БД вместе с данными?
О деплойменте:
Нужна ли поддержка автоматической реструктуризации данных при смене типов, встроенная в движек?
Какие еще аспекты БД было бы интересно рассмотреть с точки зрения описанной задачи?
Здравствуйте, Merle, Вы писали:
AVK>>2) Физическая структура хранения на диске — алгоритмы, разбиение на файлы etc M>Индексы B+ Tree, возможно со своими оптимизациями. Один файл на базу хотя возможно более хитрые варианты, тут надо от задачи плясать.
Не уверен, что это хорошее требование к «настольным» СУБД, поскольку очень усложняет xcopy — распространение, а от такой СУБД очень хотелось бы такой возможности — для простоты распространения и развёртывания, для удобства переноса, … то есть для устранения сложных администраторских действий.
AVK>>4) Способ формирования запросов M>Не SQL, наверное Linq лучший вариант, чтобы с точки зрения разработчика на обычном ЯП все было прозрачно...
+1
AVK>>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом M>БД должна брать на себя заботу по бакапу, восстановлению, и слежению за согласованностью внутри себя, все остальное запота прикладного кода.
Остальное: это что имеется в виду
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Cyberax, Вы писали:
>> Ты имеешь ввиду наследство Yaffil? Это совсем не то. C>Нет, я имею в виду FireBird Embedded
Это оно и есть. Совсем не интересно. Это обычный SQL сервер.
>> Аргументы? C>In-proc если к базе должен иметь доступ только один процесс C>одновременно. В противном случае — outproc.
А зачем доступ к десктопной базе нескольких процессов? Собственно отсуствие онного есть одна из предпосылок отличий проектных решений от классического SQL-сервера.
>> C>Как обычно. >> SQL? C>SQL, Linq,
SQL и LINQ это две очень большие разницы.
C> навигационный доступ. Не вижу причин делать что-то отличное C>от обычных БД.
Причина простая — для SQL необходим парсер, интерпретатор и очень сложный оптимизатор. Это, помимо объема работы, еще и лишний оверхед.
>>> > 5) Контроль на уровне БД. Вобще разграничение функций между движком БД и >>> > прикладным кодом >> C>Как обычно. >> Нету никакого как обычно. В разных решениях по разному. C>Имею в виду, что нет смысла изобретать что-то новое.
А что конкретно лучше всего подойдет из старого?
>> C>Скопировать файлы базы и dll-ки драйвера (для inproc). >> Алгоритм деплоймента прикладных БД в двтжек, а не деплоймент самого движка. C>Так я и говорю про деплоймент баз — в строке соединения просто C>прописывается путь до файла БД. Соответственно, для деплоймента базы C>просто нужно положить куда-нибудь файл.
Блин, еще раз. Есть некая система Х — ей нужно создать/обновить структуру БД XY, ей потребной. Весь вопрос в том как это сделать.
>> C>А вообще, все должно быть как можно проще и легковеснее. >> И при этом ты советуешь SQL, out of process и DDL. Нестыковочка выходит. C>А что, SQL уже подразумевает SQL Server?
SQL подразумевает немаленькие затраты на его парсинг и интерпретацию.
C>SQLite имеет SQL-движок размером в несколько сотен килобайт, в FireBird C>около мегабайта.
Здравствуйте, Anton Batenev, Вы писали:
AVK>>Хотелось бы обсудить как могла бы выглядеть современная настольная СУБД
AB>Как MS-Access, только с триггерами
Этой каки я уже накушался, больше не надо. И нафига настольной БД триггеры?
Здравствуйте, migel, Вы писали:
M>Для однопользовательской INPROC для многопользовательской outproc, хотя так как все ограничено одним хостом можно обойтись только inproc с SHARED объектами разграничения доступа.
Сразу оговорюсь, если это непонятно из исходного поста — речь об однопользовательской БД. Иначе получится yet another SQL server.
AVK>>2) Физическая структура хранения на диске — алгоритмы, разбиение на файлы etc M>Варианты M>1. Один файл но большой — M> преимущества: простота распространения M> недостатки: все намешано в кучу, появляються длинные Seek при чтении поиске данных что ни есть гуд.
Привод головок у винта все равно один, так что много файлов от длинных сиков не спасают.
M>2. Много файловая БД M> а) один файл на таблицу M> б) один файл на все данные M> С индексами тоже самое M> преимущества: можно оптимизировать файлы на предмет подгонки размера страницы под конкретные данные — меньше оверхеда на пустоту, M> недостатки: Проблемы с поддержкой кучи файлов, больше используемыъ объектов ядра
Самое непонятное — что делать если какой то файл потерялся?
AVK>>3) Описание метаданных M>1. DDL — чтобы иметь текстовые определения БД
А зачем?
M>2. Метаданные в формате БД храняться в самой схеме данных БД или же лежат отдельно — как вариант отдельным файлом — описателем БД.
Как определять факт несоответствия?
AVK>>4) Способ формирования запросов M>SQL или объектные запросы можно вообще обойтись без запросов если делать сетевую БД
А зачем SQL?
AVK>>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом M>ACID поддержка транзакционности как минимум с возможностью отката в случае чего.
Зачем, если БД однопользовательская?
AVK>>6) Алгоримты деплоймента M>копирование по месту
Здравствуйте, AndrewVK, Вы писали:
AVK>О первичных ключах: AVK>1) Допустимо ли требование обязательного наличия первичного ключа? AVK>2) Допустимо ли требование несоставного первичного ключа? AVK>3) Допустимо ли требование первичного ключа определенного типа? AVK>4) Допустимо ли требование первичного ключа типа GUID?
Каждое, по-отдельности, ИМХО, недопустимо, поскольку влечёт за собой перепроектирование готовой уже схемы данных или привязку создаваемой вновь к способу хранения. Я бы сказал, что допустим строгий и ограниченный набор типов данных, если это интересно.
AVK>О запросах подробнее: AVK>1) Необходим ли SQL или любой другой текстовый декларативный язык запросов? AVK>3) Что лучше — декларативный sql-like синтаксис или функциональный стиль?
Можно полностью отказаться от "текстовый декларативный язык запросов", если есть мощный (покрывающий реляционные операции) "функциональный стиль" + сохранение выражений в функциональном стиле в читаемый текст и восстановление из него. Разница в том, что текс получается вторичным и будет использоваться в самых крайних случаях => удобство и читабельность не очень важны.
AVK>2) Что лучше — выборки или навигационный способ(курсоры).
Выборки. Без курсоров в АДО.НЕТ можно ж обходиться.
AVK>О метаданных: AVK>1) Допустим ли отказ от специфичных для БД метаданных в пользу метаданных, встроенных в платформу?
Да.
AVK>2) Допустим ли (и возможен ли?) полный отказ от нетипизированных данных (нетипизированных на уровне строки) при работе с БД?
Да.
AVK>3) Должны ли типы хранится в БД вместе с данными?
Что за типы? пользовательские? От них вообще не страшно отказаться, имхо.
AVK>О деплойменте: AVK>Нужна ли поддержка автоматической реструктуризации данных при смене типов, встроенная в движек?
Какая-то дефолтная не особомудрая — да, что бы можно было не всё самому делать, а где-то изменить то, что уже есть.
AVK>Какие еще аспекты БД было бы интересно рассмотреть с точки зрения описанной задачи?
Разграничение прав
Help will always be given at Hogwarts to those who ask for it.
P.S.
О транзакциях:
1) Оптимистичные или пессимистичные?
2) Нужны ли вложенные транзакции?
3) Можно ли обойтись без транзакций вовсе или вынести их из движка БД на уровень библиотеки?
Здравствуйте, _FRED_, Вы писали:
AVK>>О первичных ключах: AVK>>1) Допустимо ли требование обязательного наличия первичного ключа? AVK>>2) Допустимо ли требование несоставного первичного ключа? AVK>>3) Допустимо ли требование первичного ключа определенного типа? AVK>>4) Допустимо ли требование первичного ключа типа GUID?
_FR>Каждое, по-отдельности, ИМХО, недопустимо, поскольку влечёт за собой перепроектирование готовой уже схемы данных или привязку создаваемой вновь к способу хранения.
Я сейчас не хочу обсуждать совместимость со старым кодом. Интересно именно проектирование from scratch.
_FR>Можно полностью отказаться от "текстовый декларативный язык запросов", если есть мощный (покрывающий реляционные операции) "функциональный стиль"
Есть.
_FR> + сохранение выражений в функциональном стиле в читаемый текст и восстановление из него.
А это зачем?
AVK>>2) Что лучше — выборки или навигационный способ(курсоры).
_FR>Выборки.
Почему?
_FR>Без курсоров в АДО.НЕТ можно ж обходиться.
Ну и что? В первых СУБД наоборот, были только курсоры и не было выборок, и тоже вроде как обходились.
AVK>>3) Должны ли типы хранится в БД вместе с данными?
_FR>Что за типы? пользовательские? От них вообще не страшно отказаться, имхо.
Типы строк, а не колонок.
AVK>>Какие еще аспекты БД было бы интересно рассмотреть с точки зрения описанной задачи?
_FR>Разграничение прав
AndrewVK wrote: >> > Ты имеешь ввиду наследство Yaffil? Это совсем не то. > C>Нет, я имею в виду FireBird Embedded > Это оно и есть. Совсем не интересно. Это обычный SQL сервер.
(Yaffil и IB — не совсем одно и тоже, ну да ладно).
Вопрос: а почему настольные БД должны отличаться от обычных БД? Конечно,
за исключением вопросов администрирования и т.п.
> C>In-proc если к базе должен иметь доступ только один процесс > C>одновременно. В противном случае — outproc. > А зачем доступ к десктопной базе нескольких процессов? Собственно > отсуствие онного есть одна из предпосылок отличий проектных решений от > классического SQL-сервера.
Например, открыть один и тот же файл из разных программ.
>> > C>Как обычно. >> > SQL? > C>SQL, Linq, > SQL и LINQ это две очень большие разницы.
И что? Еще раз говорю — нет смысла что-то новое изобретать.
> C> навигационный доступ. Не вижу причин делать что-то отличное > C>от обычных БД. > Причина простая — для SQL необходим парсер, интерпретатор и очень > сложный оптимизатор. Это, помимо объема работы, еще и лишний оверхед.
Парсер и интерпретатор — это несерьезно, в общем объеме кода это будет
совсем немного. Сверхкрутой планировщик тоже не нужен.
Я лично реализовал нечто подобное — парсер моего языка MQL (MAPI Query
Language), выглядещего примерно так:
RESTRICT(TAGEXISTS(0x1112) AND NOT FUZZY_MATCH(TAG(0x1112),?));
RESTRICT(TAGEXISTS(0x1112) AND NOT TAGVALUE(0x1112)==TAGVALUE(0x1000));
RESTRICT(NOT COMMENT(:cat) AnD NoT( NOT NOT (COMMENT(:dog)))) ;
RESTRICT(NOT COMMENT('1') AND SUBRESTRICT('Test', NOT NOT COMMENT('1')));
К нему еще написал планировщик и бэкэнд на FireBird.
Примерно 200Кб кода на С++.
>> > Нету никакого как обычно. В разных решениях по разному. > C>Имею в виду, что нет смысла изобретать что-то новое. > А что конкретно лучше всего подойдет из старого?
Небольшая удобная БД.
> C>Так я и говорю про деплоймент баз — в строке соединения просто > C>прописывается путь до файла БД. Соответственно, для деплоймента базы > C>просто нужно положить куда-нибудь файл. > Блин, еще раз. Есть некая система Х — ей нужно создать/обновить > *структуру* БД XY, ей потребной. Весь вопрос в том как это сделать.
Обычные DDL: "INSERT COLUMN INTO ..." и т.п. В сложных случаях — создать
новую базу и перезагрузить специальной программой миграции.
>> > C>А вообще, все должно быть как можно проще и легковеснее. >> > И при этом ты советуешь SQL, out of process и DDL. Нестыковочка выходит. > C>А что, SQL уже подразумевает SQL Server? > SQL подразумевает немаленькие затраты на его парсинг и интерпретацию.
Скажите это SQLite'у.
> C>SQLite имеет SQL-движок размером в несколько сотен килобайт, в FireBird > C>около мегабайта. > И что?
То что мифические затраты на SQL далеко не так уж и велики.
Кстати, если вас так волнует скорость, то можно делать вот так:
//Определяем колонки
BOOST_RTL_DEFINE_COLUMN(std::string, Name);
BOOST_RTL_DEFINE_COLUMN(bool, IsMale);
BOOST_RTL_DEFINE_COLUMN(gregorian::date, BirthDate);
//Список полей таблицыtypedef boost::mpl::vector3<Name,IsMale,BirthDate> fld_list;
//Список полей для построения индексовtypedef boost::mpl::vector3<Name,BirthDate> idx_list;
//Информация о таблице включает в себя список полей и индексовstruct People : table_info<fld_list,idx_list>{};
expr_type epxr=select((m_people),
col<0, People::Name>() == "Thor The Mighty" &&
col<0, People::IsMale>() == true &&
col<0, People::BirthDate>() < gregorian::date("1/1/1910")
;
selection(expr,table);
С помощью Boost.Shmem получаем прозрачную persistance на диск. Вчера
попробовал этот трюк — все работало пока не кончилось адресное
пространство (примерно при размере в 1.1Гб).
Одинаковые ошибки необязательно делать каждый раз, достаточно сделать одну, а затем обращаться к ней по мере необходимости из любого места программы.
Мы уже победили, просто это еще не так заметно...
. А для однопользовательских вещей лишние тормоза ни к чему. 
