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

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

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

Что озвучивать? Я не уверен что это обязательно нужно. Просто напоминаю чего мы лишаемся в случае обеспечения serializable read путем блокировок.

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

Ну и? Кто эти чекины анализирует и на что они влияют? Нельзя выполнить запись в зачекаутенный объект? Или что то иное?

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

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

А как быть если данных > 2Г?

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

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

Ну потому что это не код рабочего проекта, а пример. А так конечно да, IEnumerable<T> он реализовать должен, для этого там Т собственно и есть.

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

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

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

ещё добавлю, что я уверен в перспективности такого подхода к эволюции подобных систем. а их довольно много.

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

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

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

Я думал, что лог, это когда сначала записываем в лог транзакции, а затем в файл БД.

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

AVK>Какого объекта? Откуда у вас все время какие то объекты вылазят?

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

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

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

Достичь этого можно, например, двумя способами:
— write ahead log для изменения relocation table. Здесь все понятно;
— две копии relocation table с контрольными суммами и метками времени. При фиксации транзакции изменяешь обе с увеличением метки времени. При сбое и восстановлении считываешь обе -- если они с корректными контрольными суммами, то актуальное значение в той, у которой метка времени больше.

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

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

AVK>Ну и? Кто эти чекины анализирует и на что они влияют? Нельзя выполнить запись в зачекаутенный объект? Или что то иное?

Да, нельзя выполнить запись и нельзя удалить. Я же написал. Изменять его может только тот, кто отчекаутил.
Причем, что хорошо, эти метки checkout-а можно прямо в БД записывать.

В той ООБД (вот не помню, кажется POET) checkout-ы использовались для действительно длительных операций (больше нескольких дней).

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

AVK>А как быть если данных > 2Г?

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

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

AB>>Триггеры для того, чтобы пользователь мог редактировать данные в режиме таблицы как из самой Access
AVK>Я правильно понимаю, что настольная БД должна, по твоему, редактироваться из Access?

Нет. Просто мне бывает частенько нужно обработать массив данных и забыть о нем. Вот тут подобные способы редактирования начинают рулить ибо данные приходят в каком попало виде — тексты, Excel, dbf и т.д.

Так же, бывает, что хватает и самого аксеса как оболочки для для всех манипуляций с данными, когда не требуется всяких красявостей. Мы же говорим о настольной БД?

AB>> Можно и без них, но иногда хочется маленького счастья — внес проплату прямо ручками и в режиме таблицы, а она автоматически раскидалась по счетам, например. А так как записей всего 100-200 тыс — это не сильно заметно.
AVK>Ну и чего тут сложного? Поскольку у нас in process, то просто подвешиваемся на какое нибудь событие или делаем где нибудь в объекте виртуальный метод.

Ничего. Кроме того, что у тебя под рукой может не быть среды и ты находишься в тьмутаракани у клиента, а ему захотелось сделать к-л финт ушами. По этому, хотелось бы вынести наибольшую часть логики в БД и иметь возможность редактировать ее из внешней, по отношению к приложению, среды. Так что ни о каком in process тут даже и речи не идет (по крайней мере, я 10 раз подумаю, прежде чем подпишусь на in process движок, и, скорее всего, откажусь даже в жертву ресурсам).

AB>>По поводу каки. Интеграция с другими продуктами офиса,
AVK>Интеграцию можно производить на разных уровнях, не обязательно на уровне БД.

Можно, но если эта возможность уже есть и есть именно на этом уровне и ей можно воспользоваться, то почему бы и нет?

AB>> наличие драйвера в стандартном MDAC,
AVK>В случае JET отсутствуют начиная с версии 2.6

Я отстал от жизни.

AB>> автоматическое обновление с WindowsUpdate,
AVK>Отсутствует

Хм. Имелось ввиду обновление компонентов офиса. Или и это теперь отсутствует? Я просто не в курсе — я настроил обновление раз в сутки и забыл о нем.

AB>> наличие оболочки почти на каждой машине,
AVK>Для десктопа не критично.

Не критично, но это соломка на нештатные ситуации, которая греет душу.

AB>> выбор команды RSDN...
AVK>Чего???

Janus.

З.Ы. Я не буду доказывать, что Access — это круто. Это просто мой выбор, проверенный моим временем, моим опытом и почти адекватный моим задачам для настольных БД.

Не так давно посмотрел на SQLite в связке с Trac. Попробуйте экспортировать базу в текстовый дамп и импортировать ее обратно. В итоге вся вики-разметка, базирующаяся на количестве пустых строк, съезжает. Может, движок и хороший, но романтический момент упущен.

До этого смотрел на Advantage — просто много ненужных мне наворотов, хотя достойно внимания.

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

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

Зачем там изоляция? Зачем язык запросов?

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

Какие желания и потребности могут привести к подобным требованиям? По пунктам, плиз.

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

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

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

Не, я не про планирование, я про compile time checks типов. А планирование нет, скорее всего ничерта не даст.

C>Уточню, база сообщений Outlook'а — это фактически целая БД с
C>транзакциями, языком запросов и сортировки.

Ну МС может себе это позволить

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

Для этого не нужен полноценный язык запросов. И, в любом случае, это может быть отдельный компонент, потому что такой язык нужен далеко не всегда.

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

Но не всегда эту задачу нужно вобще решать.

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

Ну значит я плохо описал то, что требуется.

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

_FR>

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); });
_FR>

Чувствуешь насколько все запутаннее стало? А если нужно сортировать понескольким полям, да еще и с разным направлением?

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

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); });
_FR>

_FR>

Можно так, а можно и так:

.OrderBy<string>(delegate(TestClass src)
  { return src.Name; },
  StringComparer.OrdinalIgnoreCase)

Вот такой вот рояль в кустах

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

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

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

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

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

AVK>>>На практике именно буква I самая заковыристая.
GZ>>I очень заковыристая, в случае если у тебя модель данных и объектная модель не слишком совпадают. Фактически, уровень оптимистических транзакций вполне должно хватить за глаза.

AVK>Она всегда заковыристая. Я, в свое время, много с этим намаялся. Там чисто логические проблемы, которые до сих пор универсально не решены нигде.
+1. Правда я не видел достойных механизмов (кроме своих конечно).

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

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

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

AVK>Когда то давно, когда PC только появлялись, было такое явление как настольные СУБД. Потом их практически вытеснили SQL-сервера, и если они и есть где, то это в основном развитие старых продуктов.
AVK>SQL-сервера это конечно здорово, однако по прежнему есть ряд применений, для которых их навороты не нужны, равно как не нужен оверхед, связанный с многопользовательским доступом и сложное администрирование.

Ничего плохого во многопользовательском доступе нет. Учитывая, что приложение может выступать как снрвер приложений.
AVK>Хотелось бы обсудить как могла бы выглядеть современная настольная СУБД с учетом сужения класса решаемых задач и использования новых технологий и подходов. Более конкретный список вопросов:
AVK>1) in process или out of process?
Однозначно in process но с поддержкой транзакций, версионности

AVK>2) Физическая структура хранения на диске — алгоритмы, разбиение на файлы etc
Все тоже самое. Хранение в одном файле предпочтительней
AVK>3) Описание метаданных
Наверное это за надстройкой. БД должна давать минимум функций, а прикладной код делать объектную надстройку.
AVK>4) Способ формирования запросов
По мне и навигационного доступа вполне достаточно, во всяком случае в 1С я их практически не использую ни в каких вариантах.
AVK>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом
БД отвечает за запись чтение, транзакции, блокировки итд. Прикладной код за все остальное.
Вполне достаточно, для решения большинства задач.

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

_FR>>Это я понимаю. Но IDataReader, например, как часто ты используешь?
AVK>Часто. Значительно чаще чем DataSet.
_FR>> Для каких задач?
AVK>Для задач работы с БД.

Ну я, нарпимер, для "задач работы с БД" от разграничения прав уже уже отказались. Когда IDataReader необходим?

_FR>> С XmlReader — немного другое. Он один позволяет пробегать по совершенно различным сущностям — он деревообразный,
AVK>Нет, он плоский. Потому что бежит по плоскому файлу.
_FR>> по нему осуществляется доступ к объектам разных типов.
AVK>Это не играет никакой роли.

Он пробегает по неплоским данным. По данным с различной структурой. Вот, например FileStream. Зачем он был бы нужен, имей я возможность в парамтрах OpenFile(…) указать, что мне из него нужно прочитать?

Хотя я, кажется, понял о чём ты. Пусть мне надо закачать данные из базы в свои структуры. Лучше бежать по обдному объекту базы, создавать у себя свою копию и переходить к следующему объекту базы, вместо того, чтоб из базы поулчить с три короба, создать свои три короба, надеятся, что память, выделенная под первые скоро освободиться Тогда ты прав, но при я таком подходе… (*)

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

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

Например, в моём типе может быть описано вычисляемое свойство? Скорее, если понял общую идею, место такому свойству не в сборке базы данных, а в бизнес-объектах, (*) которые к объектам, которыми описывается структура БД, никакого отношения не имеет? Верно?

Выходит, что пользователю такой СУБД, надо будет:

1. Описать объекты структуры таблиц в БД.
   
2. Описать бизнес-объекты и правила маппинга их на объекты из п.1.
   
3. При осуществлении выборок из бизнес-объектов, те, в свою очередь, осуществляют выборку из объектов п.1

Последний пункт мне не нравится.

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

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

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

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

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

Здравствуйте, AndrewVK, Вы писали:
…
AVK>Можно так, а можно и так:

AVK>.OrderBy<string>(delegate(TestClass src)
AVK>  { return src.Name; },
AVK>  StringComparer.OrdinalIgnoreCase)

AVK>Вот такой вот рояль в кустах

Да, если будет индекс, + параметр IComparer<T>, то, ИМХО, просто здорово.
Но, в твоём варианте, не будет составных индексов, так?

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

AB>Нет. Просто мне бывает частенько нужно обработать массив данных и забыть о нем. Вот тут подобные способы редактирования начинают рулить ибо данные приходят в каком попало виде — тексты, Excel, dbf и т.д.

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

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

Клиент, логика в БД ... Мы по прежнему о однопользовательской встроенной БД говорим?

AB> Так что ни о каком in process тут даже и речи не идет (по крайней мере, я 10 раз подумаю, прежде чем подпишусь на in process движок, и, скорее всего, откажусь даже в жертву ресурсам).

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

AVK>>Интеграцию можно производить на разных уровнях, не обязательно на уровне БД.

AB>Можно, но если эта возможность уже есть и есть именно на этом уровне и ей можно воспользоваться, то почему бы и нет?

Нет ее. Это ты ее предлагаешь реализовать.

AB>>> автоматическое обновление с WindowsUpdate,
AVK>>Отсутствует

AB>Хм. Имелось ввиду обновление компонентов офиса. Или и это теперь отсутствует? Я просто не в курсе — я настроил обновление раз в сутки и забыл о нем.

Не у всех есть офис, да еще и с автообновлением.

AB>>> выбор команды RSDN...
AVK>>Чего???

AB>Janus.

И что ты мне хочешь про него рассказать?

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

Ну вот а для нас он оказался не полностью адекватен. Поэтому хочется лучшего, а не того же самого.

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

E> Я думал, что лог, это когда сначала записываем в лог транзакции, а затем в файл БД.

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

AVK>>Какого объекта? Откуда у вас все время какие то объекты вылазят?

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

Данные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AVK>Тип задачи — настольная однопользовательская БД.
AVK>>>О расширяемости:
AVK>>>Что должно быть расширяемо в сабже?
GZ>>Есть ли у тебя наследование?
AVK>Пока речь шла только о типизации. Про объектность это еще надо обсуждать.


GZ>>Ключ может быть синтетическим хешем. В этом случае это у тебя будет прямой доступ. Ну и есно декларативные запросы подгружающие графы.
AVK>Т.е ОО-БД?
Ну если пока это не обсуждать, то в XQuery и в LINQ(DLINQ) есть подгрузки графов(для Linq см. Including). И оба умеют работать с реляционными базами данных. А штука чрезвычайно удобная(если база данных на таких запросах не подкачает).

AVK>>>1) Необходим ли SQL или любой другой текстовый декларативный язык запросов?
GZ>>Нужен другой. Для поддержки слабоструктурированных данных.
AVK>Тебе не кажется что это выходит за рамки БД, особенно настольной?
Как раз для настольной я думаю и не выходит.В эпоху настольных систем были интересные навигационные реляционные базы данных, типа Clarion и т.п. Чрезвычайно эффективные, особенно учитывая что работали под MSDOS. Выдавили их SQL системы в силу того, что они не обеспечивают совместимость с SQL. 1C, как раз на этом сильно и погорел. Навигация для удаленных систем смертеподобна.

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

AVK>>>2) Что лучше — выборки или навигационный способ(курсоры).
GZ>>Все вместе.
AVK>Они взаимозаменяемы. Если есть один, то другой может быть реализован ввиде библиотеки.
Если ты имеешь ввиду курсоры, то да. Это один механизм. Если мы делаем переходы по ссылкам, то это уже другая песня. Вообще курсоры как таковые малоинтересны. В случае многопользовательской системы, курсор это достаточно сложная функциональность, которая уберегает возвращаемые данные от изменений пользователями. У нас, как я понял, такой задачи на горизонте не стоит. Легче оперировать выборками, и получать объекты которые уже можно спокойно обрабатывать. А вот далее, с навигационным доступом со скачкой по ссылкам, можно наделать делов.

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

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

Всегда, когда не подходит DataSet. А неподходит он, когда у нас есть собственная ОО-модель данных. Ты BLToolkit смотрел?

_FR>Он пробегает по неплоским данным.

Для ридера они плоские. Неплоскость появляется только при интерпретации.

_FR>Хотя я, кажется, понял о чём ты. Пусть мне надо закачать данные из базы в свои структуры. Лучше бежать по обдному объекту базы, создавать у себя свою копию и переходить к следующему объекту базы, вместо того, чтоб из базы поулчить с три короба, создать свои три короба, надеятся, что память, выделенная под первые скоро освободиться

А теперь еще вспомни, что есть предложение (которое ты поддержал) вобще отказаться от нетипизированных хранилищ.

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

_FR>Например, в моём типе может быть описано вычисляемое свойство?

А нафига оно? Считать это вобщем то не задача БД. Можно и отдельно посчитать, можно и в самом объекте, только к БД это не имеет никакого отношения.

_FR> Скорее, если понял общую идею, место такому свойству не в сборке базы данных, а в бизнес-объектах, (*) которые к объектам, которыми описывается структура БД, никакого отношения не имеет? Верно?

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

_FR>Выходит, что пользователю такой СУБД, надо будет:
_FR>

_FR>
1. Описать объекты структуры таблиц в БД.
   _FR>
2. Описать бизнес-объекты и правила маппинга их на объекты из п.1.
   _FR>
3. При осуществлении выборок из бизнес-объектов, те, в свою очередь, осуществляют выборку из объектов п.1
   _FR>

_FR>Последний пункт мне не нравится.

пп.2 и 3 выходят за рамки данного обсуждения. Но может быть по всякому. Можно например результат п.1 скинуть в массив и сразу отобразить в гриде.

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

Не в этой ветке

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

_FR>Да, если будет индекс, + параметр IComparer<T>, то, ИМХО, просто здорово.
_FR>Но, в твоём варианте, не будет составных индексов, так?

Индексы будут, не будет составных OrderBy. Хотя и это можно при желании добавить.