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

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

AVK>Не зависит. При оптимистических транзакциях мы обязаны скидывать лог на диск, иначе при сбоях мы не сможем обеспечить откат (лог потерян, а изменения внесены).

---

К слову о транзакциях и write ahead log-ах.

Кстати, Андрей, ты в курсе, что есть еще один механизм обеспечения транзакционности, без лога? Это когда новые значения объектов при изменении в транзакции записываются на новое место. Если в течении транзакции они обновляются, то обновляются уже на новом месте. Фиксация транзакции заключается в изменении ссылки на значение объекта (ссылка на старое расположение ссылкой на новое расположение). В таком подходе главный фокус -- это обеспечить атомарность изменения ссылок не измененные транзакцией объекты. Зато при фиксации транзакции нет надобности писать объекты дважды. И восстановление после сбоя так же тривиальное -- достаточно восстановить таблицу ссылок.

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

AVK>>А бенефиты от этого какие?
M>Отсутствие необходимости создавать эти индексы явно.

Не уверен что это допустимо. Потому как некоторые индексы могут быть очень большими по размеру. И tradeof между скоростью поиска и скоростью модификации никто не отменял.

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

Построение нового индекса в таком варианте будет очень долгой операцией.

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

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

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

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

E>Ну дык!

Ну вот и получиться sql-сервер.

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

R>IMHO вот тут как раз очень бы пригодился XML с прозрачной схемой, пригодной для рекурсивных подзапросов. Затраты на парсинг окупаются богатством тулз для конверсии и преобразования запросов.

А зачем эти тулзы нужны?

R> Появляется возможность автоматизированной динамической генерации запросов без синтаксического анализа кода.

Тут вобще не понял. Зачем для генерации запросов синтаксический анализ?

R> Например, для реализации row-level security достаточно добавить один или несколько узлов <and/> в элемент /select/where.

row level security в настольной БД???

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

По поводу миграции я уже высказывался.

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

Просто LINQ. DLINQ намертов подвязан на ADO.NET.

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

Очень даже неплохо подходит.

AndrewVK wrote:
> Я имею ввиду собственно то, что под этим обычно стандартно понимают.
> Оптимистичные транзакции, это когда пишем в лог, потом пишем в БД, а
> если откатываемся, то делаем над БД обратные операции. Пессимистичные,
> это когда лог и новые версии накапливаем в памяти, а при коммите вносим
> изменения в БД.
Вообще-то, оптимистическими и пессимистическими бывают _блокировки_.

При оптимистической блокировке мы читаем данные из базы и запоминаем их
версию. Затем мы используем данные (в частности меняем их). При коммите
происходит блокировка БД, потом проверяется версия наших данных и тех
что в БД. При несовпадении версий — кидаем исключение. При совпадении —
инкрементируем версию в БД и разблокируем ее.

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

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

ЗЫ: в частности, MAPI требует оптимистических блокировок.

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

AVK>Не на объектность, на типизированность. Это вобщем то не одно и то же. А объектность? Ну разве что аналоги триггеров через объекты зацепить.
Намекаеш на туплесы(мултепсы ).

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

AVK>Верная мысль

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

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

M>>В каком виде? если мы договорились до того что мтаданные лежат в самой БД для проверки целостности то в каком виде эти метаданные должны лежать в модуле эту БД использующем?

AVK>В том же самом, очевидно
Я понял что из "того же материала" только не понял из какого
или мы должны держать с собой пустую БД с метаданными или мы имеем возможность иметь метаданные без БД давай решать.

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

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

В п.3 несколько более жесткое требование.

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

Тип задачи — настольная однопользовательская БД.

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

Пока речь шла только о типизации. Про объектность это еще надо обсуждать.

GZ>Ключ может быть синтетическим хешем. В этом случае это у тебя будет прямой доступ. Ну и есно декларативные запросы подгружающие графы.

Т.е ОО-БД?

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

Тебе не кажется что это выходит за рамки БД, особенно настольной?

GZ> Как я уже упоминал, типа LINQ или XQuery

lINQ это не текстовый язык запросов, это языковая конструкция.

AVK>>2) Что лучше — выборки или навигационный способ(курсоры).
GZ>Все вместе.

Они взаимозаменяемы. Если есть один, то другой может быть реализован ввиде библиотеки.

AVK>>2) Допустим ли (и возможен ли?) полный отказ от нетипизированных данных (нетипизированных на уровне строки) при работе с БД?
GZ>Зависит от объема данных.

Ты, мне кажется, опять начинаешь путать ООБД и типизированные запросы.

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

_FR>А не оптимальнее-ли будет сделать OrderBy на основании int Comparison<T>(T left, T right) или IComparer<T>?

Попробуй подумать. Что будет в качестве T в приведенном запросе?

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

C>Делали так — в первый раз сериализовали граф целиком (обычной
C>сериализацией), а в дальнейшем записывали только команды изменения
C>(добавить объект в коллекцию/изменить поле объекта/и т.п.). При загрузке
C>сначала читали весь граф, а потом запускали команды изменения (мы
C>назвали этот процесс "reweaving"). Когда объем команд превышал
C>определенный предел — перезаписывали граф полностью.

Я в курсе такого подхода. Но это не БД.

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

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

Лишний повод включить фантазию

GZ> Зависит от того, является ли база данных самостоятельной для desktop приложения, или же использоваться как кэш для smart client или datacenter.

А зачем для кеша какая то особенная БД?

AVK>>2) Физическая структура хранения на диске — алгоритмы, разбиение на файлы etc
GZ>Файл один. Это был и остался лучший способ, поскольку существуют оптимизации по месту хранения(типа пытаемся читать как можно последовательней).

На физическое расположение файла на диске все равно прикладная программа не влияет.

AVK>>3) Описание метаданных
GZ>Должно поддерживать нахождение идентификацию объекта.

Какого объекта?

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

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

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

Нет.

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

У LINQ (как его тут любят поминать ) есть два варианта запросов — декларативный и функциональный. Luke Hoban говорит, что функциональный понятнее, хоть и не похож внешне на SQL.

AndrewVK wrote:
> А нужна ли изоляция транзакций? Нужен ли универсальный язык запросов?
Зависит от задачи. В персональном дневнике — может и не нужно. В
хранилище почтовых сообщений — нужно с большой вероятностью.

> Нужен ли тот или иной вид выполнения кода внутри БД?
Вот это как раз скорее всего не нужно.

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

> C>У меня в одном проекте файл БД — это документ, который открывается
> C>программой.
> Классно. Но я ведь не про твой проект спрашиваю.
Я просто приводил use-case, когда это может быть нужно.

> C>Тогда вам точно Boost.RTL поможет — он в compile-time строит план
> C>запроса с помощью expression templates
> Это уже не суть важно. Я ведь не про реализацию спрашиваю.
Стоит посмотреть даст ли compile-time планирование какие-то существенные
преимущества — может проще при старте программы скомпилировать все
SQL-запросы.

>> > C>К нему еще написал планировщик и бэкэнд на FireBird.
>> > Здорово. Осталось выяснить зачем это все нужно однопользовательской БД.
> C>По очень простой причине — так как нужна БД.
Уточню, база сообщений Outlook'а — это фактически целая БД с
транзакциями, языком запросов и сортировки.

> И? Ты хочешь сказать что без текстового языка запросов эту задачу не решить?
Все равно нужен механизм _настриваемых_ запросов (то есть я могу выбрать
сортировку по custom-ной колонке "ДатаДляМенеджера" и по колонке "Статус").

Чистым compile-time'ом не обойдешься, нужно делать хотя бы что-то типа
ICriteria. А написать транслятор [x]QL в дерево критерия — задача не
очень сложная.

>> > 1) DDL не содержит команд получения информации о метаданных
> C>Ну DDL+получение метаданных.
> А как насчет типизированного доступа к данным?
С этом сложнее.

> C>Ну вот, сначала вы говорите про легковесность, а потом жалуетесь на
> C>отсутствие версионности.
> А я говорю про легковесность? Я говорю лишь про выкидывание ненужного
> для десктопа функционала. Реструктуризация для него пожалуй даже нужнее
> чем для клиент-сервера.
Просто я не вижу лишнего в функциональность БД.

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

AVK>Тогда другая проблема — невозможность длинных транзакций. Возьмем почтовый клиент — предположим мы в процессе редактирования сообщения начали транзакцию. В этот момент сетевой блок получил новые письма. Так вот — ему придется курить пока мы не закроем окно редактирования.

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

Кстати о длительных транзакциях. Если в ней будет изменяться всего один объект (письмо в почтовой программе), то возможен еще один подход. Транзакции кратковременные, но вот объекты можно специально помечать как временно изъятые (по-моему, в какой-то ООСУБД это дело называлось check out). Т.е., перед началом редактирования письма ты делаешь его checkout. В этот момент никто не может его изменить или удалить. Затем ты фиксируешь его новое значение и выполняешь возврат (checkin). Такие долговременные блокировки своего рода.

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

E>>Ну дык!

AVK>Ну вот и получиться sql-сервер.

AFAIK, в BerkeleyDB делается так: весь кэш и все данные открытой БД размещаются в разделяемой памяти. Процессы, которые с ней работают, используют обычную синхронизацию для доступа к этой памяти. Достаточно просто и этой схеме до SQL сервера еще расти и расти.

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

AVK>using System;
AVK>using System.Collections.Generic;

AVK>namespace Rsdn.JanaDB
AVK>{
AVK>    public class Cursor<T>
AVK>    {
AVK>    //…
AVK>    }
AVK>}

Почему курсор не IEnumerable<T>?

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

_FR>>А зачем они могут понадобится такие? Перебор элементов (подсчёт агрегатов) и фильтрацию можно осуществить в запросе, если язык позволяет.

AVK>В запросе нужно будет поднять все и сразу в память. Ну как бы тебе объяснить на пальцах — представляешь разницу между XmlDocument и XmlReader, или между DataSet и IDataReader? Вот первый это выборка, а второй — курсор.

Это я понимаю. Но IDataReader, например, как часто ты используешь? Для каких задач? С XmlReader — немного другое. Он один позволяет пробегать по совершенно различным сущностям — он деревообразный, по нему осуществляется доступ к объектам разных типов. К реляционной моделе, ИМХО, когда результаты выборки — объекты одной и той же структуры, такой необходимости в нём нет.

_FR>> Зачем ещё может понадобится курсор на клиенте, кроме как для того, что бы пробежать его до конца?

AVK>Для того чтобы пробежать до конца не нужно все данные сразу держать в памяти. Как правило в программе уже есть прикладные структуры данных (DAL). В случае выборки сначала мы формируем выборку, а затем копируем ее в объекты DAL. Курсор позволит заливать данные из БД в эти объекты сразу, без промежуточных буферов.

Ага, а мне показалось, что предлагается, что СУБД уже будет хранилищем объектов с логикой, (аналог ICollection<>) и спор ведётся о том, не заменить-ли ICollection<> на IEnumerable<>…

_FR>>Как предполагается хранить описание таблиц?
AVK>Например ввиде .NET сборок.

Вернее, класс в сборке, помеченный, например, каким-нить аттрибутом, определяет таблицу?

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

E>Кстати, Андрей, ты в курсе, что есть еще один механизм обеспечения транзакционности, без лога? Это когда новые значения объектов при изменении в транзакции записываются на новое место.

Новые значения объектов в отдельном месте это и есть лог.

E> Если в течении транзакции они обновляются, то обновляются уже на новом месте. Фиксация транзакции заключается в изменении ссылки на значение объекта

Какого объекта? Откуда у вас все время какие то объекты вылазят? Ты имеешь ввиду создание копий страниц В+ дерева и коррекция ссылок в родительском узле и соседях? Думаю за счет сиков это будет медленнее чем просто переписать страницу поверх. И не забывай об индексах.

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

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

С целостностью там все в порядке — все равно ведь сброс на диск атомарен. Там проблема с учетом изменений в той же транзакции, но при наличии кеша страниц она довольно просто решаема.

AVK>>В том же самом, очевидно
M>Я понял что из "того же материала" только не понял из какого
M>или мы должны держать с собой пустую БД с метаданными или мы имеем возможность иметь метаданные без БД давай решать.

Метаданные ввиде CLR-типов без БД.

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

_FR>>А не оптимальнее-ли будет сделать OrderBy на основании int Comparison<T>(T left, T right) или IComparer<T>?

AVK>Попробуй подумать. Что будет в качестве T в приведенном запросе?

AVK>JanaDatabase db = new JanaDatabase("");
AVK>db
AVK>    .From<TestClass>()
AVK>    .Where(delegate(TestClass src)
AVK>        { return src.Name != ""; })
AVK>    .OrderBy<TestClass>(delegate(TestClass left, TestClass right)
AVK>        { return StringComparer.OrdinalIgnoreCase.Compare(left.Name, right.Name); })
AVK>    .Select<NameTuple>(delegate(TestClass src)
AVK>        { return new NameTuple(src.Name); });

Как, кстати, в твоём варианте, сделать сортировку без учёта регистра? Вот так:

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.ToUpper();})
AVK>    .Select<NameTuple>(delegate(TestClass src)
AVK>        { return new NameTuple(src.Name); });

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

_FR>>А не оптимальнее-ли будет сделать OrderBy на основании int Comparison<T>(T left, T right) или IComparer<T>?
AVK>Попробуй подумать. Что будет в качестве T в приведенном запросе?

То, что указано во From<> и Where<>.

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

_FR>Это я понимаю. Но IDataReader, например, как часто ты используешь?

Часто. Значительно чаще чем DataSet.

_FR> Для каких задач?

Для задач работы с БД.

_FR> С XmlReader — немного другое. Он один позволяет пробегать по совершенно различным сущностям — он деревообразный,

Нет, он плоский. Потому что бежит по плоскому файлу.

_FR> по нему осуществляется доступ к объектам разных типов.

Это не играет никакой роли.

_FR>Ага, а мне показалось, что предлагается, что СУБД уже будет хранилищем объектов с логикой,

Я такого нигде не писал. Я всего лишь говорил что данные (строки) типизированы. О каких объектах с логикой может идти речь, если мы, скажем, выполняем операцию join (ты разве не предлагал LINQ использовать )? Откуда вобще вылезли какие то объекты с логикой?

AVK>>Например ввиде .NET сборок.

_FR>Вернее, класс в сборке, помеченный, например, каким-нить аттрибутом, определяет таблицу?

Например так.