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

AVK>>О совместимости с индексами на диске ты подумал?

_FR>Ага, так индексам быть?

Без них совсем никак.

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

WR>Нужны не триггеры а хуки. Нужно чтобы я в одном приложении мог пасти на изменения, определённую ветку данных (как папку в файловой системе) сделанные в другом приложении. Т.е. нужен калбэк-интерфейс.

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

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

AVK>>В п.3 несколько более жесткое требование.
GZ>Да тоже самое. Синтетика всегда делается одного типа для унификации.

Я то с тобой, пожалуй, соглашусь. Но мне встречались товарищи, с тобой несогласные категорически.

GZ>В случае, если нужно синхронизироваться в архитектуре datacenter, то нужно по крайней мере поддерживать идентификацию принятую на сервере. (вопрос уже как, это второй. Можно и через таблицу соответсвий.)

Тока с сабжем это немного общего имеет.

AVK>>Т.е ОО-БД?
GZ>Ну если пока это не обсуждать, то в XQuery и в LINQ(DLINQ) есть подгрузки графов(для Linq см. Including).

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

AVK>>lINQ это не текстовый язык запросов, это языковая конструкция.
GZ>Не цепляйся за слова. Главное смысл.

Вот за смысл я как раз и цепляюсь. Ты постоянно пытаешься трактовать LINQ как еще один текстовый язык запросов, а это совсем не так.

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

А делаем ли? Типизированная БД <> ООБД. А ты постоянно скатываешься на последнюю.

GZ> Вообще курсоры как таковые малоинтересны. В случае многопользовательской системы, курсор это достаточно сложная функциональность, которая уберегает возвращаемые данные от изменений пользователями. У нас, как я понял, такой задачи на горизонте не стоит. Легче оперировать выборками, и получать объекты которые уже можно спокойно обрабатывать.

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

GZ> А вот далее, с навигационным доступом со скачкой по ссылкам, можно наделать делов.

Навигационный доступ в пределах курсора (навигация абсолютно плоская). Внешние ссылки это уже другой курсор.

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

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

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

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

Ничто не мешает сделать многопользовательский доступ, но на уровнем удаленных методов. В большинстве случаев этого достаточно.
AVK>>>3) Описание метаданных
S>> Наверное это за надстройкой. БД должна давать минимум функций, а прикладной код делать объектную надстройку.

AVK>Т.е. данные внутри БД описываются системой типов самой БД, а прикладной код должен самостоятельно выполнять конверсию? И что мы выигрываем при этом?

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

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

Я смотрю на такую БД с точки зреня 1С, Паруса , акзапты. А так и ДБФ выше крыши.

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

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

GZ>> Зависит от того, является ли база данных самостоятельной для desktop приложения, или же использоваться как кэш для smart client или datacenter.
AVK>А зачем для кеша какая то особенная БД?
Минимум она должна держать идентификацию совместимую с основным сервером идентификацию.

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

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

_FR>>Ну я, нарпимер, для "задач работы с БД" от разграничения прав уже уже отказались. Когда IDataReader необходим?
AVK>Всегда, когда не подходит DataSet. А неподходит он, когда у нас есть собственная ОО-модель данных. Ты BLToolkit смотрел?

Понял. Я вначале не так понял задачи, которые должен решать движок БД — казалось, что в неё планируется включить поддержку бизнес-объектов, а это не так, как выяснилось. И отлично. Теперь уверен, что курсоров хватит.

AVK>>>Я такого нигде не писал. Я всего лишь говорил что данные (строки) типизированы. О каких объектах с логикой может идти речь, если мы, скажем, выполняем операцию join (ты разве не предлагал LINQ использовать )? Откуда вобще вылезли какие то объекты с логикой?
_FR>>Например, в моём типе может быть описано вычисляемое свойство?
AVK>А нафига оно? Считать это вобщем то не задача БД. Можно и отдельно посчитать, можно и в самом объекте, только к БД это не имеет никакого отношения.

Старая дуратская привычка поделиться логикой с БД Не прав.

AVK>Ну вроде того.

_FR>>Выходит, что пользователю такой СУБД, надо будет:
…
AVK>пп.2 и 3 выходят за рамки данного обсуждения. Но может быть по всякому. Можно например результат п.1 скинуть в массив и сразу отобразить в гриде.

Ага. Это понятно.

_FR>>Мне бы очень помогло, опиши ты как бизнес-объекты связыватся со структурой БД?
AVK>Не в этой ветке

В такой постановке — да. Тогда, покажи пример класса, описывающего таблицу? Вернее, описывающего строку таблицы. Интересует вот что.
Каждое свойство класса, описывающего таблицу, помеченно каким-либо аттрибутом — это "колонка" таблицы. Имеет-ли смысл держать в таком классе другие свойства? Какие? Может, это и не класс вовсе, а интерфейс\абстрактный класс с декларацией свойств?

Имеет ли смысл строить иерархию таких классов\интерфейсов для обозначения таблиц со схожей структурой?

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

E>Да здесь то же самое. Представь, что в ссылки в индексах хранят не прямой адрес страницы, а ее идентификатор. А по идентификатору через специальную relocation table ты находишь адрес. Тогда, при необходимости перезаписи страницы БД (индекс это или страница с объектами/строками/туплами), ты просто записываешь страницу в новое место и правишь ссылку на нее в memory-relocation-table. При фиксации транзакции сбрасываешь memory-relocation-table на диск. И все. Сложность только в атомарности изменения relocation table.

При этом учитывашь что у тебя получается очень высокая дефрагментация БД. Не знаю как сейчас, но раньше Interbase работал по такому принципу.

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

_FR>Нет, этим должен сервер приложений занимаеться. Не дело базе данных клиентов оповещать.

Спасибо за ответ.

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

GZ>>В случае, если нужно синхронизироваться в архитектуре datacenter, то нужно по крайней мере поддерживать идентификацию принятую на сервере. (вопрос уже как, это второй. Можно и через таблицу соответсвий.)
AVK>Тока с сабжем это немного общего имеет.
Ну вот. Ограничиваем применимость сабжа?

AVK>>>lINQ это не текстовый язык запросов, это языковая конструкция.
GZ>>Не цепляйся за слова. Главное смысл.
AVK>Вот за смысл я как раз и цепляюсь. Ты постоянно пытаешься трактовать LINQ как еще один текстовый язык запросов, а это совсем не так.
Возьми espresso, и у тебя есть тектовой язык запросов. Немного лучше HQL и немного хуже XQuery. Смысл то у них, одинаковый.(а я говорю именно о запросах которые еще не обработаны препроцессором в функциональный вид).

AVK>>>Они взаимозаменяемы. Если есть один, то другой может быть реализован ввиде библиотеки.
GZ>>Если ты имеешь ввиду курсоры, то да. Это один механизм. Если мы делаем переходы по ссылкам, то это уже другая песня.
AVK>А делаем ли? Типизированная БД <> ООБД. А ты постоянно скатываешься на последнюю.
Уж очень мне хочется. Наболело. Повторю. Lazy Load в условиях локальной базы данных операция дешевая. Хочешь еще большей дешевизны при массовых операциях, пользуй запросы.
А на OODB(хоть это и моя больная тема) я еще не скатывался.


AVK>Опять ты думаешь в терминах ОО. База совсем не обязана создавать выборки каждый раз. Если нам нужно простопроанализировать данные, а не куда нибудь показать, поднимать сразу все в память никому не нужно, достаочно просто по данным пробежаться.
Сделай запрос с делегатом, который будет обеспечивать все изменения и все подсчеты которые тебе нужны. Сделай так, чтобы БД предоставила все необходимые данные для этого, и синхронизировала состояния между памятью и диском.
Поясню последний пункт. Если мы делаем изменение с объектом, то это изменение должно отражаться на той же сущности(не важно, назови ее tuple, объект или entity), что и находится в памяти. И точно также именно эта сущность должна предоставляться в процессе запроса, и точно также именно по этой сущности должны работать операции фильтрации и сортировки. Что будет дальше с этими объектами, неважно. Если в них не было изменений, то их вообще можно навесить на WeakReference или потерять.

Зачем keyset? Зачем курсоры? Мы можем дать пользователю единую феню и не мучить его не особо нужным функционалом.

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

E>>Ну а как назвать то, что ты будешь в своей БД хранить?

AVK>Данные.

Ну вот считай, что твои данные я называю объектом.

AVK>Вот и хотелось бы без конкретики, а то непонятно. У тебя в голове есть какая то модель, а вот в моей она отсутствует, поэтому иногда я не могу понять о чем идет речь.

EMBEDDED OBJECT ORIENTED DATABASE SYSTEMS FOR JAVA AND CSHARP -- смотреть раздел Shadow transaction mechanism.

AVK>Я же тебе объяснил — перезапись страницы значительно дешевле чем правка ссылок в нескольких страницах. Что же касается отдельной таблицы пересчета адресов то это пустой расход памяти и диска, раздувание файла БД, лишняя косвенность и еще одна возможность для сбоев.

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

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

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

AVK> Оптимистичные транзакции, это когда пишем в лог, потом пишем в БД, а если откатываемся, то делаем над БД обратные операции.
Это называется Write Ahead Logging.

AVK> Пессимистичные, это когда лог и новые версии накапливаем в памяти, а при коммите вносим изменения в БД.
Если я правильно помню, то этот режим называется No Redo/No Undo Logging, но это надо смотреть...

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


E> Это когда новые значения объектов при изменении в транзакции записываются на новое место. Если в течении транзакции они обновляются, то обновляются уже на новом месте. Фиксация транзакции заключается в изменении ссылки на значение объекта (ссылка на старое расположение ссылкой на новое расположение).
Эта техника называется Shadow Copying, если я правильно помню, применялась в System/R и других приличных местах до знаменитой работы Мохана по ARIES в которой он доказал эффективность WAL в сочетании с Undo/Redo...

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

[skip, как путь ведущий в никуда]

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

Вопрос идет в контексте Janus?

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

AVK>О первичных ключах:
AVK>1) Допустимо ли требование обязательного наличия первичного ключа?
AVK>2) Допустимо ли требование несоставного первичного ключа?
AVK>3) Допустимо ли требование первичного ключа определенного типа?
AVK>4) Допустимо ли требование первичного ключа типа GUID?
Я — за принудительно введенный GUID.
Доп. расходов не так уж и много, зато минимум проблем для автоматических алгоритмов репликации/мерджа и прочих вещей, полезных для встроенных СУБД.
Опять же упрощается реализация FK; заодно появляется возможность отказаться от произвольных JOIN и заставить джониться только по FK.
AVK>О расширяемости:
AVK>Что должно быть расширяемо в сабже?

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

AVK>О запросах подробнее:
AVK>1) Необходим ли SQL или любой другой текстовый декларативный язык запросов?
Все зависит от того, что будет клиентом этой СУБД. Если Pure .Net — то 100% Linq, и никаких гвоздей. Если что-то более кроссплатформенное — то текстовые запросы.
AVK>2) Что лучше — выборки или навигационный способ(курсоры).
Лучше, наверное, все же выборки. Они позволяют лучше масштабировать производительность: при изменении статистики декларативный движок может сменить план запроса. Навигационный план запроса, оптимизированный девелопером для случая "товаров много больше, чем заказов", станет узким местом через полгода эксплуатации.
AVK>3) Что лучше — декларативный sql-like синтаксис или функциональный стиль?
А можно попонятнее?
AVK>О метаданных:
AVK>1) Допустим ли отказ от специфичных для БД метаданных в пользу метаданных, встроенных в платформу?
Наверное, да.
AVK>2) Допустим ли (и возможен ли?) полный отказ от нетипизированных данных (нетипизированных на уровне строки) при работе с БД?
Имеется в виду отказ от byte[]? Нет, недопустим.
AVK>3) Должны ли типы хранится в БД вместе с данными?
Да, крайне желательно.
AVK>О деплойменте:
AVK>Нужна ли поддержка автоматической реструктуризации данных при смене типов, встроенная в движек?
Крайне желательно иметь хорошие возможности реструктуризации. Причем я бы начал с реструктуризации копированием вместо реструктуризации "по месту". Т.е. при запуске приложение обнаруживает устаревшую версию БД, создает новую пустую БД новой версии и выполняет импорт из старой в новую. Затем старая версия дропается. Исходя из этого, я думаю, что в движок должны быть встроены средства, облегчающие такой импорт — т.е. simple yet powerful data transfer toolset. Надо помнить о том, что миграция версий структуры бывает не только когда мы запускаем новое приложение над его же старым файлом — это может быть копирование из БД другого пользователя, етк.

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

Вопросы бэкапа тоже стоило бы рассмотреть. Ну, и, собственно, всё.

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

AB>Ничего. Кроме того, что у тебя под рукой может не быть среды и ты находишься в тьмутаракани у клиента, а ему захотелось сделать к-л финт ушами.
Угу, а если завтра война?

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

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

S>Я — за принудительно введенный GUID.
S>Доп. расходов не так уж и много, зато минимум проблем для автоматических алгоритмов репликации/мерджа и прочих вещей, полезных для встроенных СУБД.
S>Опять же упрощается реализация FK; заодно появляется возможность отказаться от произвольных JOIN и заставить джониться только по FK.
А если еще добавить ссылку в объекте на родителя то получиться почти сетевая модель

хъ
AVK>>1) Допустим ли отказ от специфичных для БД метаданных в пользу метаданных, встроенных в платформу?
S>Наверное, да.
Для .NET only хранилища по моему тоже.

AVK>>2) Допустим ли (и возможен ли?) полный отказ от нетипизированных данных (нетипизированных на уровне строки) при работе с БД?
S>Имеется в виду отказ от byte[]? Нет, недопустим.
+

AVK>>3) Должны ли типы хранится в БД вместе с данными?
S>Да, крайне желательно.
+
AVK>>О деплойменте:
AVK>>Нужна ли поддержка автоматической реструктуризации данных при смене типов, встроенная в движек?
S>Крайне желательно иметь хорошие возможности реструктуризации. Причем я бы начал с реструктуризации копированием вместо реструктуризации "по месту". Т.е. при запуске приложение обнаруживает устаревшую версию БД, создает новую пустую БД новой версии и выполняет импорт из старой в новую. Затем старая версия дропается. Исходя из этого, я думаю, что в движок должны быть встроены средства, облегчающие такой импорт — т.е. simple yet powerful data transfer toolset. Надо помнить о том, что миграция версий структуры бывает не только когда мы запускаем новое приложение над его же старым файлом — это может быть копирование из БД другого пользователя, етк.

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

S>Вопросы бэкапа тоже стоило бы рассмотреть. Ну, и, собственно, всё.
+

AndrewVK wrote:
> Ну и? Что я должен был увидеть?
Прикладной код (редактирование и т.п.) отделен от логики транзакций.
Например, мы можем без всякого изменения кода отредактировать пачку из
10 писем, а потом разом сохранить.

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

AB>Вопрос идет в контексте Janus?

По поводу неадекватности да.

Здравствуйте, 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); });
AVK>[/c#]
AVK>Конкретизирую вопрос: если у нас нет индексов все замечательно — реализация упомянутых методов будет тривиальна. А вот если они есть, то возникает вопрос как и на каком основании их использовать. Навскидку вижу два варианта:
AVK>1) Анализ кода лямбды на предмет обнаружения понимаемых условий. В частности в примере несложно понять как использовать индекс по Name
Речь о том, что все таки нужен вменяемый оптимизатор. В одной руке у него логический план, сформированный именно в виде лямбд. В другой руке — статистика базы (примитивная статистика есть всегда, как минимум в виде Unique и FK Constraints). На выходе именно он должен выдавать план запроса.
Я думаю, более-менее приемлемый оптимизатор не должен весить слишком много. Особенно с учетом однопользовательскости — не надо учитывать риски параллельных изменений.
AVK>2) Введение двух форм методов — один с лямбдой, другой с параметрами, описывающими работу с индексом.
Вторая форма является аналогом хинтов SQL серверов. Она важна для эксплуатации, т.к. именно при ней возникает время и желание подкрутить планы для подъема производительности еще на 1.5%. Для девелопера она зло: во-первых, приходится разбираться с тем, что и как там внутри работает (фактически, переделывая работу оптимизатора), во-вторых, ограничивает маневр оптимизатора.
AVK>Первый вариант удобнее для использования, но сложнее в реализации и чреват непредсказуемыми эффектами, второй значительно стабильнее, но запутывает код и усложняет добавление индексов для оптимизации. Какой вариант предпочтительнее? Или может существует третий вариант?
Да никаких других вариантов нет. Два полюса с промежуточными вариантами, типа "этот джойн надо выполнить первым, а остальные — как хочешь".
Я лично за то, чтобы отказаться от ручного указания хинтов.
Да, кстати, для настольной базы есть хороший шанс, что промежуточные результаты вполне поместятся в памяти. Это означает, что оценка стоимости сильно упрощается — настоящий оптимизатор обязан учитывать перспективы запросов, которые сначала делают full outer join миллиона с миллионом, и только потом выбирают из этого данные. Там все подряд приходится применять — сброс результатов на диск; специальные алгоритмы лукапа по этим результатам и прочая муть.

На самом деле есть еще один принципиальный вопрос: какие типы операторов допустимы?
В полной реляционной модели самые проблемные — это джойны/проекции и группировка.
Агрегатные запросы мало того, что имеют тенденцию плохо оптимизироваться, они еще и усложняют type inference. К примеру, если мы агрегируем тупл (string, int32), вычисляя Max() от второго поля по первому, то тип результирующего тупла — тоже (string, int32). А если Sum, то по-хорошему это должно быть (string, int64), иначе есть риск overflow (это я заодним предположил ограничение на 2^32 строк в любом релейшне).

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

Мораль в том, что надо понять, чего собственно хочется — либо полная реляционная модель (вместе со всеми экзотическими фичами типа non-equality join, джойнов с вычисляемыми полями, агрегатов с окном и прочей экзотикой), либо ограниченная модель, в которой удобно и быстро выполняются некоторые основные операции.

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

AB>>Ничего. Кроме того, что у тебя под рукой может не быть среды и ты находишься в тьмутаракани у клиента, а ему захотелось сделать к-л финт ушами.
V>Угу, а если завтра война?

Война в моем городе случается на много порядков реже, нежели причуды заказчика.