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

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

AVK> Что может потребоваться прикладному программисту поменять на уровне операций движка с данными?
Упорядочить физическое хранение объектов по какому-либо из индексов для ускорения доступа, но это не первой необходимости конструкция.
Те же index include...

AVK>Выхлоп тот же, что и в случае index includes юкона.
Так и сделать это в виде того же index include, просто дать возможность включать в индекс дополнительные поля с данными и хранить их вместе с индексом.

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

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

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

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

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

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

При сложных запросах он будет нечитаем:

SQL

SELECT id, name FROM people WHERE name <> 'Mamut' AND city_id=1 ORDER BY name DESC

------
XML pseudo
<statement>
  <select>
    <fields>
        <field name="id" table="people">
        <field name="name" table="people">
    </fields>
    <constraints>
        <notequal>
            <field name="name" value="Mamut">
        </notequal>
        <equal>
            <field name="city_id" value="1">
        </equal>
    </constraints>
    <order>
        <field name="name" value="desc">
    </order>
  </select>
</statement>
------

Какой-нить функциональный язык pseudo (на основе Erlang + Mnesia):

Q = query [E.name, E.id || E <- table(people), E.name != 'Mamut', E.city_id = 1]

Вот чтобы я приветствовал — это язык запросов вроде list comprehensions, но мало для каких языков это будет возможно...

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

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

+1 Это если это для решения задачи важнее, то несомненно плюсов от граничения: «В каждой таблице есть Guid-первичный ключ» очень много. В подобном аспекте более чем разумное требование.

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

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

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

Как предполагается хранить описание таблиц? Что это в понятии разрабатываемой БД? Набор колонок, или описание типа-объекта строки? Видимо второе…

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

AVK>>>Хотелось бы обсудить как могла бы выглядеть современная настольная СУБД
AB>>Как MS-Access, только с триггерами
AVK>Этой каки я уже накушался, больше не надо. И нафига настольной БД триггеры?

Триггеры для того, чтобы пользователь мог редактировать данные в режиме таблицы как из самой Access, так и чтобы вынести часть логики из приложения. Можно и без них, но иногда хочется маленького счастья — внес проплату прямо ручками и в режиме таблицы, а она автоматически раскидалась по счетам, например. А так как записей всего 100-200 тыс — это не сильно заметно.

По поводу каки. Интеграция с другими продуктами офиса, наличие драйвера в стандартном MDAC, автоматическое обновление с WindowsUpdate, наличие оболочки почти на каждой машине, выбор команды RSDN... Как там было у Джоэля? "Большинство функций-таки работают"

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

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

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

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

Несколько инстанцев -- это о чем?

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

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

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

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

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

Какой там апдейт если Jet из MDAC уже черт знает когда выкинули и его нужно отдельно скачивать

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

GZ>>Даже если у тебя разрешено иметь несколько инстансов, или у тебя MDI приложение?
E>Несколько инстанцев -- это о чем?
А то, что у меня пользователи требуют возможность открытие нескольких инстансов одновременно. И под разными логинами.

E>MDI приложение -- это все равно одно приложение. Внутри приложения доступ к БД можно через обычные средства синхронизации делать.
Что значит "обычные средства синхронизации".

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

E>И кстати, у меня лично такая политика (одна транзакция в один момент времени) в многопоточных приложениях вполне себе прокатывает. Может со временем и не будет хватать, нопока хватает.
В случае если у тебя транзакция начинается вместе с открытием формы?

AndrewVK wrote:
> 1) Анализ кода лямбды на предмет обнаружения понимаемых условий. В
> частности в примере несложно понять как использовать индекс по Name
> 2) Введение двух форм методов — один с лямбдой, другой с параметрами,
> описывающими работу с индексом.
Кстати, вспомнил вот еще такой подход для нестандартных решений.

В одном проекте надо было сохранять большой и достаточно сложный граф
объектов. Этот граф постоянно пополнялся, но старые объекты изменялись
редко.

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

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

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

>> неудобного.
C>А я вот так не считаю.

Ну ОК. Тогда мои вопросы не для тебя.

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

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

>> Зачем однопользовательской БД открывать файл из разных программ?
C>У меня в одном проекте файл БД — это документ, который открывается
C>программой.

Классно. Но я ведь не про твой проект спрашиваю.

>> частности я уже не могу использовать в запросе compile-time технологии.
C>Тогда вам точно Boost.RTL поможет — он в compile-time строит план
C>запроса с помощью expression templates

Это уже не суть важно. Я ведь не про реализацию спрашиваю.

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



C> Например, вы не задумывались как Outlook сортирует письма, строит дерево тредов или
C>делает поиск в ящиках с сотнями тысяч писем?

И? Ты хочешь сказать что без текстового языка запросов эту задачу не решить?

>> Это не ответ. Что касаемо FBEmbed, то это неудобная для десктопных задач БД.
C>Мой опыт показывает обратное.

А мой нет.

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

А как насчет типизированного доступа к данным?

C>Ну вот, сначала вы говорите про легковесность, а потом жалуетесь на
C>отсутствие версионности.

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

>> Да да. То то я гляжу, что древний и убогий JET в янусе работает быстрее
>> новомодного MSSQL 2005.
C>Может забудем про JET вообще как про ошибку истории?

Можно конечно. Но ведь быстрее же

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

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

Я правильно понимаю, что настольная БД должна, по твоему, редактироваться из Access?

AB>, так и чтобы вынести часть логики из приложения.

in process БД это уже часть приложения, так что никуда ты ничего не вынесешь. Если же речь о слоях абстракции, то это можно сделать и без триггеров.

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

Ну и чего тут сложного? Поскольку у нас in process, то просто подвешиваемся на какое нибудь событие или делаем где нибудь в объекте виртуальный метод.

AB>По поводу каки. Интеграция с другими продуктами офиса,

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

AB> наличие драйвера в стандартном MDAC,

В случае JET отсутствуют начиная с версии 2.6

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

Отсутствует

AB> наличие оболочки почти на каждой машине,

Для десктопа не критично.

AB> выбор команды RSDN...

Чего???

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

AVK>>А зачем?
M>Ежели напирать на объектность то тогда не зачем.

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

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

Верная мысль

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

Зачем? При пессимистичной транзакции сброс происходит когда откат уже не возможен.

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

В том же самом, очевидно

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

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

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

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

E>>Несколько инстанцев -- это о чем?
GZ>А то, что у меня пользователи требуют возможность открытие нескольких инстансов одновременно. И под разными логинами.

Мы сейчас про настольную (неявно подразумевается встроенная) БД говорим, или про серверную-многопользовательскую?
Если мы про встраиваемую, то под несколькими инстансами можно понимать и вот это:

// Первый инстанс.
some_cool_db_t first_db( "my_cool_db.dat" );
// А вот и второй.
some_cool_db_t second_db( "my_cool_db.dat" ); // Опаньки! :)

в такой ситуации first_db и second_db могут просто не понимать, что они лезут к одному физическому файлу.

У меня можно сделать вот так:

/* Примечание: в реальном коде все это сдабривается std::auto_ptr-ами! */

// Этот объект физически выполняет все действия над БД.
oess_1::db::site::localhost_t * localhost = oess_1::db::site::create_db_localhost();
// Этот объект должен знать, с какой физической БД мы работаем.
// Физически БД будет открыта при первом реальном обращении к ней.
localhost->db_describe(
  // Этот псевдоним будет использоваться в дальнейшем. Он позволяет абстрагироваться от конкретных имен.
  "my_database",
  // Это физическое имя БД.
  "~/my_cool_app/dat/default",
  // Конфигурационный файл с описаниями параметров БД.
  "~/my_cool_app/dat/default.cfg",
  // Открываем в read-write режиме.
  false,
  // Разрешаем автоматическое восстановление БД в случае сбоя.
  true );

// А вот через такой объект будет вестись прикладная работа.
oess_1::db::cln::db_t * first_db = oess_1::db::cln::create_std_db(
  // Вот так устанавливается связь между объектом localhost и first_db.
  oess_1::db::site::create_std_localhost_connector( *localhost ) );

// Подключаемся к БД и начинаем работать с ней.
// Именно в этот момент localhost начнет работать с файлами БД.
first_db->attach( "my_database" );

// А вот так создается второе подключение к той же БД.
oess_1::db::cln::db_t * second_db = oess_1::db::cln::create_std_db(
  // Вот так устанавливается связь между объектом localhost и first_db.
  oess_1::db::site::create_std_localhost_connector( *localhost ) );
second_db->attach( "my_database" );

Я думаю, что ты про такие инстансы говорил?

E>>MDI приложение -- это все равно одно приложение. Внутри приложения доступ к БД можно через обычные средства синхронизации делать.
GZ>Что значит "обычные средства синхронизации".

Если брать C++, то mutex-ы и condition variables. Если Java, то synchonized-секции.

GZ>В случае если у тебя транзакция начинается вместе с открытием формы?

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

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

C>А кто говорил, что будет просто.

Я говорил. Потому что отказ от I одна из основных идей данного обсуждения.

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

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

Она всегда заковыристая. Я, в свое время, много с этим намаялся. Там чисто логические проблемы, которые до сих пор универсально не решены нигде.

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

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

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

_FR>+1 Это если это для решения задачи важнее,

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

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

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

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

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

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

_FR>Как предполагается хранить описание таблиц?

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

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

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

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

C>Transaction *trans=db->begin_transaction();

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

Ну и? Что я должен был увидеть?

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

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

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