AndrewVK wrote:
> Если не достаточно тех рамок, что я описал, то пусть, для примера, это
> будет почтовый клиент.
Замечательно, я как раз писал backend для Outlook'а

>> > 3) Можно ли обойтись без транзакций вовсе или вынести их из движка БД на
>> > уровень библиотеки?
> C>Лучше не надо. Транзакции замечательно на уровне БД живут,
> Не так уж и замечательно.
В той же FB — вполне нормально.

> C> и прикладные транзакции очень удобно делать поверх транзакций в БД.
> А зачем нам две механики транзакций, если можно обойтись одной?
Я имею в виду, что транзакции в приложении являются "обертками" для
транзакций в БД.

Здравствуйте, Merle, Вы писали:

AVK>>О первичных ключах:
AVK>>1) Допустимо ли требование обязательного наличия первичного ключа?
M>Первичного ключа в смысле уникальности? Да, я думаю вполне...

И в смысле упрожения механики FK.

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

А бенефиты от этого какие?

AVK>>Что должно быть расширяемо в сабже?
M>В каком смысле расширяемости?

В любом. Что может потребоваться прикладному программисту поменять на уровне операций движка с данными?

AVK>>2) Достаточно ли самого простого варианта, или нужна возможность подкрузки в кейсет части данных?
M>С частью данных возни много, а выхлоп непонятен...

Выхлоп тот же, что и в случае index includes юкона.

AVK>>2) Допустим ли (и возможен ли?) полный отказ от нетипизированных данных (нетипизированных на уровне строки) при работе с БД?
M>Теоретически да, опять-таки интересно было бы посмотреть.

Ну если осаваться в рамках реляционной модели, то проблем вроде бы неразрешимых нет.

Здравствуйте, eao197, Вы писали:

E>Не совсем по тому списку вопросов, который ты привел...

no problem

E>О ключах, индексах и прочем. Если индексов нет, то для некоторых задач это может быть поначалу некритично. Например, при старте загружается все содержимое БД, затем все содержимое перезаписывается.

Нереально. Слишком большие ограничения.

E>Но, даже если по началу кажется, что для задачи не нужно информацию индексировать, то затем обязательно оказывается, что информацию в БД нужно упорядочивать. Причем обычно по некольким критериям, т.е. по нескольким разным индексам. Так что, если БД будет подерживать индексы сама, не заставляя пользователя делать это самостоятельно, то это удобно.

Что значит поддерживать сама?

E> А у приложения появляется шанс в дальнейшем безболезненно переползти на настоящую РСУБД.

Не интересно. Требование совместимости (даже частичной) резко отсекает огромный пласт возможных решений. Настолько огромный, что в итоге вряд ли получится что то, заметно отличающееся от современных СУБД.

E>Что касается метаданных (например, описания схемы данных), то оно имеет смысл, если БД будет поддерживать автоматическую миграцию данных при смене схемы.

Метаданные в любом случае имеют смысл, иначе непонятно от чего будет плясать сам движек.

E> Если такая миграция делается вручную, то особой пользы от метаданных нет. Если же метаданные используются, то желательно иметь контроль за соответствием схемы данных в БД и в программе. Для релационных данных это не столь серьезный вопрос, но если БД позволит хранить объектную информацию, то такой контроль серьезно помогает.

Тут все очень мутно. Для начала попробуй ответить на вопрос: в какой момент БД становится нереляционной?

E>О деплойменте. На этапе разработки хотелось бы просто подключить к себе какую-нибудь либу (несколько) и все. На этапе использования -- иметь возможность создавать и удалять БД на лету. А так же проверять существование БД.

О, именно о том как это сделать я и спрашивал.

E>Вроде основные моменты перечислил. Надеюсь, помог.

Спасибо.

E>

---

E>А тебе зачем?

Пока что чисто исследовательский интерес.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, migel, Вы писали:

AVK>>>>>3) Описание метаданных
M>>>>1. DDL — чтобы иметь текстовые определения БД

AVK>>>А зачем?
M>>ДЛя поддержки разработки да и для автоматического развертывания на основе только текстовых файлов.
AVK>А зачем?
Ежели напирать на объектность то тогда не зачем.

AVK>>>Как определять факт несоответствия?
M>>Можно ввести пометочки в заголовке файлов БД на предмет соотвествия схемы. Но в общем да схемы мужно запихать в сам файл данных а общую схему БД строить как совокупность всех схем описанных в файлах данных — Но тут получается логически самое простое решение — иметь один файл на БД и не париться.

AVK>А теперь как это совместить с только типизированным доступом?
ЭЭЭЭ а давай в БД сразу сборки с объектами положим и будет тогда вообще все автоматично а проверки версионности просто можно свести к проверке MSIL

AVK>>>А зачем SQL?
M>>Для поддержки сторонних тулзов — а ля Генераторы отчетов и прочей братии им без SQL будет худо.... Хотя ежели нам отчеты не уперлись можем и забить а сделать только навигационный доступ.

AVK>Понятно, опять совместимость со старым кодом.
Если не нужно тогда в сад, просто из исходной постановки задачи сее не следовало

AVK>>>>>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом
M>>>>ACID поддержка транзакционности как минимум с возможностью отката в случае чего.

AVK>>>Зачем, если БД однопользовательская?
M>>Свет выключают иногда

AVK>А если транзакции пессимистичные?
А это по барабану все равно защиту на физический сброс страниц в хранилище ставить придеться.

M>>Значит реструктуризация без отдельных метаданных получается странной. Не разворачивать же вторую БД параллельно только для вычитки метаданных. Или разворачивать ?

AVK>А как тебе такой вариант:
AVK>1) БД содержит метаданные, которые актуальны для тех данных, которые она содержит.
AVK>2) В программе своя версия метаданных.
В каком виде? если мы договорились до того что мтаданные лежат в самой БД для проверки целостности то в каком виде эти метаданные должны лежать в модуле эту БД использующем?
AVK>3) При попытке использовать более свежую версию метаданных БД выполняет реструктуризацию (в процессе которой в том числе обновляет метаданные и у себя унутре).

Здравствуйте, AndrewVK, Вы писали:

AVK>JanaDatabase db = new JanaDatabase("");
AVK>db
AVK>    .From<TestClass>()
AVK>    .Where(delegate(TestClass src)
AVK>        { return src.Name != ""; })
AVK>    .OrderBy<string>(delegate(TestClass src)
AVK>        { return src.Name;})
AVK>    .Select<NameTuple>(delegate(TestClass src)
AVK>        { return new NameTuple(src.Name); });

А не оптимальнее-ли будет сделать OrderBy на основании int Comparison<T>(T left, T right) или IComparer<T>? Тогда вложенные OrderBy отпадут и быстрота должна увеличиться.

Здравствуйте, Cyberax, Вы писали:

C>Как вывод — не нужна только буква "I" ("A" нужна, "C" нужна частично,
C>"D" нужна по определению). В общем-то, согласен, хотя лично мне это было
C>очень полезно.

На практике именно буква I самая заковыристая.

C>Например, я открываю письмо на редактирование — запускается транзакция.
C>При редактировании данные в этой транзакции изменяются, но я могу
C>переключиться на старое сообщение и посмотреть его исходный вариант.

ИМХО это уже чисто прикладная логика. Впрочем можно вынести на уровень БД, но тогда нужны вложенные транзакции или хотя бы сейвпоинты.

Здравствуйте, _FRED_, Вы писали:

_FR>Пускай, всё равно, получается очень ограниченно. Например, исключает возможность естественных ключей…

А насколько она востребованна в настольных приложениях? Чем хуже будет ввести для естественного ключа отдельный индекс?

_FR> Хотя и они зачастую не пользуются популярностью… В ощем, не вижу, где не хвантило бы Guid PrimaryKey. Только то, что схема не получается универсальной

Зато получается универсальным целый комплект другой механики, например те же FK (и более сложные виды связей).

_FR>Курсоры дадут возможность узнать количество записей сразу?

Некоторые да. Опять же — никто не мешает добежать до конца и получить выборку.

_FR> Смысл серверных курсов какой в настольной БД?

В настольной БД нет понятия серверных курсоров — они там по определению клиентские.

_FR> Если уж база "настольная", то пускай будет наиболее простой — попросил->получил набор. Не вижу преимущества курсора. Или просто не знаю

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

AVK>>>>3) Должны ли типы хранится в БД вместе с данными?
_FR>>>Что за типы? пользовательские? От них вообще не страшно отказаться, имхо.
AVK>>Типы строк, а не колонок.

_FR>Тогда не понимаю

А что конкретно непонятно?

Здравствуйте, Cyberax, Вы писали:

>> C> и прикладные транзакции очень удобно делать поверх транзакций в БД.
>> А зачем нам две механики транзакций, если можно обойтись одной?
C>Я имею в виду, что транзакции в приложении являются "обертками" для
C>транзакций в БД.

Так и я о том же. Зачем лишний слой оберток?

AndrewVK wrote:
> C>Как вывод — не нужна только буква "I" ("A" нужна, "C" нужна частично,
> C>"D" нужна по определению). В общем-то, согласен, хотя лично мне это было
> C>очень полезно.
> На практике именно буква I самая заковыристая.
А кто говорил, что будет просто.

> C>Например, я открываю письмо на редактирование — запускается транзакция.
> C>При редактировании данные в этой транзакции изменяются, но я могу
> C>переключиться на старое сообщение и посмотреть его исходный вариант.
> ИМХО это уже чисто прикладная логика. Впрочем можно вынести на уровень
> БД, но тогда нужны вложенные транзакции или хотя бы сейвпоинты.
Зачем? Достаточно обычных одноуровневых транзакций, но с изоляцией.

AndrewVK wrote:
> C>Я имею в виду, что транзакции в приложении являются "обертками" для
> C>транзакций в БД.
> Так и я о том же. Зачем лишний слой оберток?
Ладно. Возьмем мой пример с письмом — благодаря транзакциям в БД
прикладной код будет очень простым.

В псевдокоде:

Transaction *trans=db->begin_transaction();

Letter *letter=Letter::load_letter(id, trans);
ShowEditWindow(letter);
if (!trans->commit())
    MessageBox("Транзакция провалилась").

Здравствуйте, AndrewVK, Вы писали:

AVK>1) Необходим ли SQL или любой другой текстовый декларативный язык запросов?

IMHO вот тут как раз очень бы пригодился XML с прозрачной схемой, пригодной для рекурсивных подзапросов. Затраты на парсинг окупаются богатством тулз для конверсии и преобразования запросов. Появляется возможность автоматизированной динамической генерации запросов без синтаксического анализа кода. Например, для реализации row-level security достаточно добавить один или несколько узлов <and/> в элемент /select/where.

Далее, при необходимости миграции на более "взрослую" СУБД достаточно написать слой для XSLT-трансляции таких запросов в SQL для конкретной БД.

Но и DLinq бы тоже не помешал как более легкий уровень

AVK>3) Что лучше — декларативный sql-like синтаксис или функциональный стиль?
А нужна ли здесь функциональщина?

Здравствуйте, eao197, Вы писали:

E>Доступ к БД из разных приложений одновременно. Хотелось бы иметь, таки.

Это зацепит за собой целый грузовик проблем (особенно меня пугает необходимость параллельных транзакций) и в результате мы придем к теперешним SQL-серверам. Поэтому предлагаю искуственно ввести ограничение на однопользовательский режим.

E> Хотя бы в режиме: один может и читать и писать, а остальные хотя бы читать.

Если I = Read Commited (для полной гарантии отсутствия snapshot too old), то вполне возможно. Но! Возникает вопрос межпроцессной коммуникации, сериализации, протоколов обмена, а обеспечение типизированного доступа усложняется. Мне кажется, это лучше сделать ввиде отдельного, независимого от движка БД слоя, используемого только при необходимости.

E> Объясню почему: иногда какая-то программа крутиться постоянно, остановить ее нет возможности. Но вот глянуть, чтоже у него внутри базы твориться бывает необходимо. Обычно это связано с сохранением в БД ошибочных данных или с ошибочной обработкой корректных данных.

Но в десктопных приложениях очень часто используется кеш в памяти (прикладной!). Если ты напрямую влезешь в БД, то автоматом пролетишь мимо него. Тебе не кажется, что подобные запросы должны проходить все равно через прикладной слой?

Здравствуйте, AndrewVK, Вы писали:

AVK>Хотелось бы обсудить как могла бы выглядеть современная настольная СУБД с учетом сужения класса решаемых задач и использования новых технологий и подходов.

Это что-то типа: db4o?

AVK> Более конкретный список вопросов:
AVK>1) in process или out of process?
in process — зачем нам лишний оверхед

AVK>2) Физическая структура хранения на диске — алгоритмы, разбиение на файлы etc
У меня пока 50 на 50 "один файл" против "много файлов"

AVK>3) Описание метаданных
Схема в которой описывается структура по которой можно построить или изменить существующую схему базы. Держать отдельно, скармливать API движка который будет производить все манипуляции. Возможно предусмотреть какую то версионность для схемы.

AVK>4) Способ формирования запросов
Думаю что то linq подобное будет в самый раз.

AVK>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом
API для бекапа, восстановления, возможно сжатие/оптимизации базы.

AVK>6) Алгоримты деплоймента
xcopy с приложением

Здравствуйте, AndrewVK, Вы писали:

E>>Но, даже если по началу кажется, что для задачи не нужно информацию индексировать, то затем обязательно оказывается, что информацию в БД нужно упорядочивать. Причем обычно по некольким критериям, т.е. по нескольким разным индексам. Так что, если БД будет подерживать индексы сама, не заставляя пользователя делать это самостоятельно, то это удобно.

AVK>Что значит поддерживать сама?

Ну вот у меня есть понятие slice (раздела) и возможность итерирования по элементам slice. Но индексирования объектов в slice на уровне БД нет. Когда требуется индексирование программист должен объявить в программе объект slice_image (своеобразный proxy для доступа к содержимому slice), а для каждого индекса -- объект slice_index. Каждый slice_index связывается со своим критерием сортировки и с исходным slice_image. Далее пользователь работает со slice_index-ами. Удаление объекта через какой-нибудь slice_index автоматически приводит к удалению объекта из БД, из slice_image и всех остальных slice_index. Соответственно, при добавлении объекта в slice_image, объект добавляется в БД и в каждый из slice_index-ов.

Самое большое неудобство в том, что все эти slice_image и slice_index-ы нужно делать в программе вручную. Было бы более удобно, если бы я мог просто сказать БД: дай мне объект с таким-то ключем из такого-то индекса (без всяких slice_image и slice_index). Ну или чтобы все slice_image и slice_index-ы создавались автоматом при открытии БД.

E>>Что касается метаданных (например, описания схемы данных), то оно имеет смысл, если БД будет поддерживать автоматическую миграцию данных при смене схемы.

AVK>Метаданные в любом случае имеют смысл, иначе непонятно от чего будет плясать сам движек.

Метаданные нужны, но есть разница между метаданными в программе (которые программа сама может формировать, используюя возможности рефлексии или метапрограммирования) и метаданными на диске рядом с БД.

E>> Если такая миграция делается вручную, то особой пользы от метаданных нет. Если же метаданные используются, то желательно иметь контроль за соответствием схемы данных в БД и в программе. Для релационных данных это не столь серьезный вопрос, но если БД позволит хранить объектную информацию, то такой контроль серьезно помогает.

AVK>Тут все очень мутно. Для начала попробуй ответить на вопрос: в какой момент БД становится нереляционной?

Как только мы позволяем иметь внутри объекта атрибут, который сам является объектом. Еще хуже, если этот атрибут является агрегатом объектов. Например:

class file_content_t
  {
    std::string m_file_name;
    date_time_t m_mtime;
    date_time_t m_ctime;
    std::string m_content;
    ...
  };

class archive_t
  {
    std::list< file_content_t > m_files;
    ...
  };

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

E>>О деплойменте. На этапе разработки хотелось бы просто подключить к себе какую-нибудь либу (несколько) и все. На этапе использования -- иметь возможность создавать и удалять БД на лету. А так же проверять существование БД.

AVK>О, именно о том как это сделать я и спрашивал.

Так а чего сложного?
Если БД хранится в одном файле -- то проверяешь его наличие. Затем пытаешься открыть БД и проверить ее целостность. Если все нормально -- БД есть.
Если БД состоит из нескольких файлов -- это это чуть более сложный случай предыдущего варианта.

Здравствуйте, AndrewVK, Вы писали:

AVK>На каком уровне?
На уровне атомарности нескольких операций, ну и гарантии того, что если данные до диска доехали, то они там и останутся...
И отката в случае нарушения констрейнта, само-собой..

Здравствуйте, AndrewVK, Вы писали:

AVK>А если транзакции пессимистические
Это и есть Redo Only лог.. Если я правильно понял что ты имеешь ввиду под пессимистическими транзакциями....

AVK>, то лог вобще можно на диск не скидывать.
Кажется в этом случае есть опастность, что если что-то навернется именно во время записи, то восставновиться уже не получится, хотя есть схема No Redo/No Undo, которая примерно так и работает...

Здравствуйте, AndrewVK, Вы писали:

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

AVK> Ладно, перефразирую вопрос — имеет ли смысл делать транзакции подстраиваемыми под конкретную задачу или жестко вшивать их в движек БД?
Лучше жестко вшить, меньше возни с каждой конкретной задачей. В отсутствии конкурентного доступа основная задача транзакций — это обеспечить грамотный откат и устойчивость, а в этом вполне можно положиться на универсальный движек...

Здравствуйте, AndrewVK, Вы писали:

E>>Доступ к БД из разных приложений одновременно. Хотелось бы иметь, таки.

AVK>Это зацепит за собой целый грузовик проблем (особенно меня пугает необходимость параллельных транзакций) и в результате мы придем к теперешним SQL-серверам.

А можно сделать совсем просто: одна транзакция на БД в один момент времени. Кто начал -- тот работает. Остальные ждут своей очереди. Не устраивает -- вперед к SQL-серверам.

AVK>Но! Возникает вопрос межпроцессной коммуникации, сериализации, протоколов обмена, а обеспечение типизированного доступа усложняется.

Ну дык!

E>> Объясню почему: иногда какая-то программа крутиться постоянно, остановить ее нет возможности. Но вот глянуть, чтоже у него внутри базы твориться бывает необходимо. Обычно это связано с сохранением в БД ошибочных данных или с ошибочной обработкой корректных данных.

AVK>Но в десктопных приложениях очень часто используется кеш в памяти (прикладной!). Если ты напрямую влезешь в БД, то автоматом пролетишь мимо него. Тебе не кажется, что подобные запросы должны проходить все равно через прикладной слой?

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

Здравствуйте, AndrewVK, Вы писали:

AVK>О первичных ключах:
AVK>1) Допустимо ли требование обязательного наличия первичного ключа?
AVK>2) Допустимо ли требование несоставного первичного ключа?
AVK>3) Допустимо ли требование первичного ключа определенного типа?
Лучше сразу спросить, нужен ли синтетический ключ. IMHO нужен, для однозначной идентификации объекта в памяти и его состояния на диске.

AVK>4) Допустимо ли требование первичного ключа типа GUID?
Зависит от типа задачи. Я, например, люблю GUID.

AVK>О расширяемости:
AVK>Что должно быть расширяемо в сабже?
Есть ли у тебя наследование?


AVK>О keysets:
AVK>1) Допустимо ли встраивание этой механики в движек БД.
Только так.
AVK>2) Достаточно ли самого простого варианта, или нужна возможность подкрузки в кейсет части данных?
По условиям.
AVK>3) Нужна ли многостадийная загрузка или подгрузка в 2 стадии — кейсет и остальные данные? Или может еще какой вариант?
Ключ может быть синтетическим хешем. В этом случае это у тебя будет прямой доступ. Ну и есно декларативные запросы подгружающие графы.


AVK>О запросах подробнее:
AVK>1) Необходим ли SQL или любой другой текстовый декларативный язык запросов?
Нужен другой. Для поддержки слабоструктурированных данных. Как я уже упоминал, типа LINQ или XQuery
AVK>2) Что лучше — выборки или навигационный способ(курсоры).
Все вместе.
AVK>3) Что лучше — декларативный sql-like синтаксис или функциональный стиль?
Первый легче использовать, второй легче делать.

AVK>О метаданных:
AVK>1) Допустим ли отказ от специфичных для БД метаданных в пользу метаданных, встроенных в платформу?
Почему бы и нет.
AVK>2) Допустим ли (и возможен ли?) полный отказ от нетипизированных данных (нетипизированных на уровне строки) при работе с БД?
Зависит от объема данных.
AVK>3) Должны ли типы хранится в БД вместе с данными?
Почему бы нет.

AVK>О деплойменте:
AVK>Нужна ли поддержка автоматической реструктуризации данных при смене типов, встроенная в движек?
Ага. Обязательно. Многие отказы от нестандартных БД происходили именно из-за сложности версионификации.

Здравствуйте, AndrewVK, Вы писали:

E>>А тебе зачем?

AVK>Пока что чисто исследовательский интерес.

А ты сюда не заглядывал: http://www.garret.ru/~knizhnik/databases.html
Попробуй с Константином Книжником пообщаться. Он давно такими вещами занимается.