Здравствуйте, AndrewVK, Вы писали:
AVK>Сразу оговорюсь, если это непонятно из исходного поста — речь об однопользовательской БД. Иначе получится yet another SQL server.
ОК
M>>Варианты M>>1. Один файл но большой — M>> преимущества: простота распространения M>> недостатки: все намешано в кучу, появляються длинные Seek при чтении поиске данных что ни есть гуд. AVK>Привод головок у винта все равно один, так что много файлов от длинных сиков не спасают.
M>>2. Много файловая БД M>> а) один файл на таблицу M>> б) один файл на все данные M>> С индексами тоже самое M>> преимущества: можно оптимизировать файлы на предмет подгонки размера страницы под конкретные данные — меньше оверхеда на пустоту, M>> недостатки: Проблемы с поддержкой кучи файлов, больше используемыъ объектов ядра
AVK>Самое непонятное — что делать если какой то файл потерялся?
Антракт негодяи В случае одного файла БД он испортиться может — тогда уж кранты всему. В случае утери индекса все лечиться перестроением оного. В общем для однопользовательской БД мне кажеться это не актуально.
AVK>>>3) Описание метаданных M>>1. DDL — чтобы иметь текстовые определения БД
AVK>А зачем?
ДЛя поддержки разработки да и для автоматического развертывания на основе только текстовых файлов.
M>>2. Метаданные в формате БД храняться в самой схеме данных БД или же лежат отдельно — как вариант отдельным файлом — описателем БД. AVK>Как определять факт несоответствия?
Можно ввести пометочки в заголовке файлов БД на предмет соотвествия схемы. Но в общем да схемы мужно запихать в сам файл данных а общую схему БД строить как совокупность всех схем описанных в файлах данных — Но тут получается логически самое простое решение — иметь один файл на БД и не париться.
AVK>>>4) Способ формирования запросов M>>SQL или объектные запросы можно вообще обойтись без запросов если делать сетевую БД
AVK>А зачем SQL?
Для поддержки сторонних тулзов — а ля Генераторы отчетов и прочей братии им без SQL будет худо.... Хотя ежели нам отчеты не уперлись можем и забить а сделать только навигационный доступ.
AVK>>>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом M>>ACID поддержка транзакционности как минимум с возможностью отката в случае чего.
AVK>Зачем, если БД однопользовательская?
Свет выключают иногда AVK>>>6) Алгоримты деплоймента M>>копирование по месту
AVK>А реструктуризация?
Во про слона то я и забыл.
Значит реструктуризация без отдельных метаданных получается странной. Не разворачивать же вторую БД параллельно только для вычитки метаданных. Или разворачивать ?
AndrewVK wrote: > M>ACID поддержка транзакционности как минимум с возможностью отката в > случае чего. > Зачем, если БД однопользовательская?
Начали мы сохранять изменения — а тут кот выдернул шнур питания (у нас
настольная БД). Вот тут-то транзакционность с ACID очень даже пригодится.
AndrewVK wrote: > О транзакциях: > 1) Оптимистичные или пессимистичные?
Зависит от потребностей и возможностей.
> 2) Нужны ли вложенные транзакции?
Обычно нет.
> 3) Можно ли обойтись без транзакций вовсе или вынести их из движка БД на > уровень библиотеки?
Лучше не надо. Транзакции замечательно на уровне БД живут, и прикладные
транзакции очень удобно делать поверх транзакций в БД.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вопрос как раз в согласованности. Какого уровня констрейнты должны быть?
Мммм.. В первую очередь, естественно, согласованность данных и индексов
Возможно не имеет смысл делать констрейнты типа FK, но уникальность гарантировать надо, причем жестко увязать это с наличием индекса..
Вводить наличие хитрых Check-констрейнтов, тоже пожалуй не стоит, не первой необходимости конструкция.
Поддержка транзакционности, естественно...
Здравствуйте, AndrewVK, Вы писали:
AVK>О первичных ключах: AVK>1) Допустимо ли требование обязательного наличия первичного ключа?
Первичного ключа в смысле уникальности? Да, я думаю вполне...
AVK>2) Допустимо ли требование несоставного первичного ключа?
Да.
AVK>3) Допустимо ли требование первичного ключа определенного типа?
Ну, можно, пожалуй ограничиться первыми двумя трабованиями.
С другой стороны, можно потребовать наличия индекса на любом поле по которому производится фильтрация и вообще создавать эти индексы на автомате при первом запросе, если подходящих не обнаружилось.
AVK>О расширяемости: AVK>Что должно быть расширяемо в сабже?
В каком смысле расширяемости?
AVK>О keysets: AVK>2) Достаточно ли самого простого варианта, или нужна возможность подкрузки в кейсет части данных?
С частью данных возни много, а выхлоп непонятен... Можно разрешить грузить только данные из индексов и целиком объект.
AVK>О запросах подробнее: AVK>1) Необходим ли SQL или любой другой текстовый декларативный язык запросов?
Вот от этого хотелось бы избавиться в противном случае есть embedded SQL сервера и непонятно зачем делать что-то еще.
AVK>О метаданных: AVK>1) Допустим ли отказ от специфичных для БД метаданных в пользу метаданных, встроенных в платформу?
Допустим, собственно с этим и было бы интересно поиграться.
AVK>2) Допустим ли (и возможен ли?) полный отказ от нетипизированных данных (нетипизированных на уровне строки) при работе с БД?
Теоретически да, опять-таки интересно было бы посмотреть.
AVK>3) Должны ли типы хранится в БД вместе с данными?
Да.
AVK>О деплойменте: AVK>Нужна ли поддержка автоматической реструктуризации данных при смене типов, встроенная в движек?
В идеале да. Иначе очень большие проблемы при разработке.
AVK>Какие еще аспекты БД было бы интересно рассмотреть с точки зрения описанной задачи?
Где вести логгирование, как обеспечивать отказоустойчивость...
Сложный вопрос с большим предисловием.
Примем на время тот факт, что используем курсоры и функциональный стиль запросов. Примерный внешний вид интерфейса будет таким:
1) Объект, представляющий БД:
namespace Rsdn.JanaDB
{
/// <summary>
/// База данных.
/// </summary>public class JanaDatabase
{
private readonly string _filePath;
/// <summary>
/// Инициализирует экземпляр.
/// </summary>public JanaDatabase(string filePath)
{
_filePath = filePath;
throw new NotImplementedException();
}
/// <summary>
/// Возвращает таблицу, соответствующую переданному типу.
/// </summary>public Cursor<T> From<T>() where T : IKeyedObject
{...}
}
}
Метод From возвращает курсор на всю БД.
IKeyedObject, указанный у ограничении, просто говорит о том что у типа таблицы есть первичный ключ:
using System;
using System.Collections.Generic;
namespace Rsdn.JanaDB
{
/// <summary>
/// Содержит результат выборки.
/// </summary>public class Cursor<T>
{
/// <summary>
/// Выполняет операцию проекции.
/// </summary>
/// <typeparam name="D">тип результата</typeparam>
/// <param name="projection">операция проекции</param>public Cursor<D> Select<D>(Projection<T, D> projection)
{...}
/// <summary>
/// Выполняет операцию фильтрации.
/// </summary>public Cursor<T> Where(Filter<T> filter)
{...}
/// <summary>
/// Выполняет сортировку.
/// </summary>public Cursor<T> OrderBy<K>(KeySelector<K, T> keySelector)
{...}
/// <summary>
/// Выполняет группировку.
/// </summary>public IEnumerable<Grouping<K, T>> GroupBy<K>(KeySelector<K, T> keySelector)
{...}
}
}
Описания делегатов приводить не буду, думаю и так все понятно.
В контексте данного вопроса интересуют методы where и orderby. Что они делают, надеюсь, понятно. Вопрос в том как.
Пример запроса:
public class TestClass : KeyedObjectBase
{
private string _name;
private string _description;
public TestClass(Guid primaryKey) : base(primaryKey)
{
}
public string Name
{
get { return _name; }
set { _name = value; }
}
public string Description
{
get { return _description; }
set { _description = value; }
}
}
public class NameTuple
{
private string _name;
public NameTuple(string name)
{
_name = name;
}
public string Name
{
get { return _name; }
}
}
...
JanaDatabase db = new JanaDatabase("");
db
.From<TestClass>()
.Where(delegate(TestClass src)
{ return src.Name != ""; })
.OrderBy<string>(delegate(TestClass src)
{ return src.Name;})
.Select<NameTuple>(delegate(TestClass src)
{ return new NameTuple(src.Name); });
Конкретизирую вопрос: если у нас нет индексов все замечательно — реализация упомянутых методов будет тривиальна. А вот если они есть, то возникает вопрос как и на каком основании их использовать. Навскидку вижу два варианта:
1) Анализ кода лямбды на предмет обнаружения понимаемых условий. В частности в примере несложно понять как использовать индекс по Name
2) Введение двух форм методов — один с лямбдой, другой с параметрами, описывающими работу с индексом.
Первый вариант удобнее для использования, но сложнее в реализации и чреват непредсказуемыми эффектами, второй значительно стабильнее, но запутывает код и усложняет добавление индексов для оптимизации. Какой вариант предпочтительнее? Или может существует третий вариант?
Здравствуйте, Cyberax, Вы писали:
C>Начали мы сохранять изменения — а тут кот выдернул шнур питания (у нас C>настольная БД). Вот тут-то транзакционность с ACID очень даже пригодится.
Тут не ACID, тут A. И, в отличии от больших БД, здесь можно ограничиться только Redo Only логом.
I здесь не нужно, в силу того, что БД однопользовательская, D здесь тоже обеспечит аккуртная реализация логгирования, C — это отдельная тема для обсуждения, не думаю что весь набор больших БД здесь сильно необходим...
Здравствуйте, AndrewVK, Вы писали:
AVK>1) Оптимистичные или пессимистичные?
А какая разница, если БД однопользовательская?
AVK>2) Нужны ли вложенные транзакции?
Нет.
AVK>3) Можно ли обойтись без транзакций вовсе или вынести их из движка БД на уровень библиотеки?
Нет, Атомарность изменений и устойчивость, пусть лучше БД обеспечивает.
Здравствуйте, Cyberax, Вы писали:
>> Это оно и есть. Совсем не интересно. Это обычный SQL сервер. C>(Yaffil и IB — не совсем одно и тоже, ну да ладно).
поясню — в оригинальном FB не было embedded версии, зато она была в дятле. После слияния дятла и FB мы и получили современную FBEmbed.
C>Вопрос: а почему настольные БД должны отличаться от обычных БД?
Я уже ответил на него. Слишком многов них для настольных БД ненужного, неудобного.
C> Конечно, за исключением вопросов администрирования и т.п.
А зачем их исключать. Особенно если раскрыть т.п. поподробнее?
>> А зачем доступ к десктопной базе нескольких процессов? Собственно >> отсуствие онного есть одна из предпосылок отличий проектных решений от >> классического SQL-сервера. C>Например, открыть один и тот же файл из разных программ.
Зачем однопользовательской БД открывать файл из разных программ?
>> SQL и LINQ это две очень большие разницы. C>И что? Еще раз говорю — нет смысла что-то новое изобретать.
А я и не говорю про изобретение нового.
>> сложный оптимизатор. Это, помимо объема работы, еще и лишний оверхед. C>Парсер и интерпретатор — это несерьезно, в общем объеме кода это будет C>совсем немного. Сверхкрутой планировщик тоже не нужен.
Это серьезно, потому что там вылазит целый ряд проблем и ограничений. В частности я уже не могу использовать в запросе compile-time технологии.
C>К нему еще написал планировщик и бэкэнд на FireBird.
Здорово. Осталось выяснить зачем это все нужно однопользовательской БД.
>> А что конкретно лучше всего подойдет из старого? C>Небольшая удобная БД.
Это не ответ. Что касаемо FBEmbed, то это неудобная для десктопных задач БД.
>> Блин, еще раз. Есть некая система Х — ей нужно создать/обновить >> *структуру* БД XY, ей потребной. Весь вопрос в том как это сделать. C>Обычные DDL: "INSERT COLUMN INTO ..." и т.п. В сложных случаях — создать C> новую базу и перезагрузить специальной программой миграции.
Практика показывает что:
1) DDL не содержит команд получения информации о метаданных
2) DDL для реструктуризации весьма неудобна
3) В DDL нет никакой поддержки типизации и версионности, а также автоматического контроля структуры БД и структуры данных программы.
>> C>SQLite имеет SQL-движок размером в несколько сотен килобайт, в FireBird >> C>около мегабайта. >> И что? C>То что мифические затраты на SQL далеко не так уж и велики.
Да да. То то я гляжу, что древний и убогий JET в янусе работает быстрее новомодного MSSQL 2005.
C>Кстати, если вас так волнует скорость, то можно делать вот так: C>
//Определяем колонки
C>BOOST_RTL_DEFINE_COLUMN(std::string, Name);
C>BOOST_RTL_DEFINE_COLUMN(bool, IsMale);
C>BOOST_RTL_DEFINE_COLUMN(gregorian::date, BirthDate);
C>//Список полей таблицы
C>typedef boost::mpl::vector3<Name,IsMale,BirthDate> fld_list;
C>//Список полей для построения индексов
C>typedef boost::mpl::vector3<Name,BirthDate> idx_list;
C>//Информация о таблице включает в себя список полей и индексов
C>struct People : table_info<fld_list,idx_list>{};
C>expr_type epxr=select((m_people),
C> col<0, People::Name>() == "Thor The Mighty" &&
C> col<0, People::IsMale>() == true &&
C> col<0, People::BirthDate>() < gregorian::date("1/1/1910")
C> ;
C>selection(expr,table);
C>
Здравствуйте, Merle, Вы писали:
M>Вводить наличие хитрых Check-констрейнтов, тоже пожалуй не стоит, не первой необходимости конструкция.
Лучше их втаскивать из прикладной программы. Почему, кстати, текстовый язык запросов мне не кажется оптимальной идеей.
M>Поддержка транзакционности, естественно...
Здравствуйте, migel, Вы писали:
AVK>>>>3) Описание метаданных M>>>1. DDL — чтобы иметь текстовые определения БД
AVK>>А зачем? M>ДЛя поддержки разработки да и для автоматического развертывания на основе только текстовых файлов.
А зачем?
AVK>>Как определять факт несоответствия? M>Можно ввести пометочки в заголовке файлов БД на предмет соотвествия схемы. Но в общем да схемы мужно запихать в сам файл данных а общую схему БД строить как совокупность всех схем описанных в файлах данных — Но тут получается логически самое простое решение — иметь один файл на БД и не париться.
А теперь как это совместить с только типизированным доступом?
AVK>>А зачем SQL? M>Для поддержки сторонних тулзов — а ля Генераторы отчетов и прочей братии им без SQL будет худо.... Хотя ежели нам отчеты не уперлись можем и забить а сделать только навигационный доступ.
Понятно, опять совместимость со старым кодом.
AVK>>>>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом M>>>ACID поддержка транзакционности как минимум с возможностью отката в случае чего.
AVK>>Зачем, если БД однопользовательская? M>Свет выключают иногда
А если транзакции пессимистичные?
M>Значит реструктуризация без отдельных метаданных получается странной. Не разворачивать же вторую БД параллельно только для вычитки метаданных. Или разворачивать ?
А как тебе такой вариант:
1) БД содержит метаданные, которые актуальны для тех данных, которые она содержит.
2) В программе своя версия метаданных.
3) При попытке использовать более свежую версию метаданных БД выполняет реструктуризацию (в процессе которой в том числе обновляет метаданные и у себя унутре).
Не совсем по тому списку вопросов, который ты привел... Из собственного опыта разработки и использования собственной же системы хранения (я называю ее восстановочной БД). Может пригодятся.
О ключах, индексах и прочем. Если индексов нет, то для некоторых задач это может быть поначалу некритично. Например, при старте загружается все содержимое БД, затем все содержимое перезаписывается. Но идентификация объектов в БД все равно какая-то нужна, если потребуется производить операции над отдельными объектами. Бывает удобно, если этот OID генерирует сама БД. Причем еще удобнее, если этот OID не повторяется затем удалении/создании объектов. По моему, для OID самое важное -- знать его размер (чтобы он не плавал в диапазоне от нескольких байт до килобайт в зависимости от времени суток ). Так что GUID в качестве OID вполне допустим, имхо.
Но, даже если по началу кажется, что для задачи не нужно информацию индексировать, то затем обязательно оказывается, что информацию в БД нужно упорядочивать. Причем обычно по некольким критериям, т.е. по нескольким разным индексам. Так что, если БД будет подерживать индексы сама, не заставляя пользователя делать это самостоятельно, то это удобно. Будут ли эти индексы храниться на диске или перестраиваться в ОП при каждом открытии БД -- не столь важно. Хотя, апетиты у пользователей растут и если в БД будет со временем несколько сотен тысяч объектов или даже миллионы, то вариант с ОП будет не самым лучшим.
Что касается запросов, то, мне в большинстве случаев хватало несколько индексов по разным критериям с выполнением простейших операций -- найти по ключу, найти нижнюю/верхнюю границу диапазона. Если появляется необходимость в каких-то запросах (а-ля SQL), то... Лично я бы задумался о том, чтобы взять БД посерьезнее Но если уж делать какой-то язык запросов, то в духе SQL (например, сильно упрощенный/урезанный SQL), т.к. порог вхождения меньше. А у приложения появляется шанс в дальнейшем безболезненно переползти на настоящую РСУБД.
Что касается метаданных (например, описания схемы данных), то оно имеет смысл, если БД будет поддерживать автоматическую миграцию данных при смене схемы. Если такая миграция делается вручную, то особой пользы от метаданных нет. Если же метаданные используются, то желательно иметь контроль за соответствием схемы данных в БД и в программе. Для релационных данных это не столь серьезный вопрос, но если БД позволит хранить объектную информацию, то такой контроль серьезно помогает.
А автоматическая миграция данных при смене схемы -- это удобно. Я бы предпочел иметь эту возможность в БД.
О деплойменте. На этапе разработки хотелось бы просто подключить к себе какую-нибудь либу (несколько) и все. На этапе использования -- иметь возможность создавать и удалять БД на лету. А так же проверять существование БД. У меня обычно сценарий такой: приложение стартует, узнает из конфига, где должна быть восстановочная база, проверяет ее существование. Если базы нет, то создает новую и работает без участия пользователя.
Еще важный момент. БД должна иметь возможности самовосстановления после сбоя. Желательно корректного Опционально, перед восстановлением хорошо было бы сохранять поврежденные файлы отдельно. Чтобы, если восстановление завершиться неудачно, их можно было отослать разработчику БД с требованием исправить баги и восстановить-таки данные.
Так же важно, чтобы БД была самодефрагментируемой. Чтобы при работе с ней она не разросталась до невероятных размеров, если в ней в отдельный момент времени хранится не много объектов. Не скажу, что мне хотелось бы, чтобы БД при удалении объектов ужималась в размерах, но вот чтобы эффективно использовала уже освободившиеся места -- это важно.
Вроде основные моменты перечислил. Надеюсь, помог.
А тебе зачем?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Merle, Вы писали:
M>Тут не ACID, тут A. И, в отличии от больших БД, здесь можно ограничиться только Redo Only логом.
А если транзакции пессимистические, то лог вобще можно на диск не скидывать.
M>I здесь не нужно, в силу того, что БД однопользовательская,
+1
M> D здесь тоже обеспечит аккуртная реализация логгирования, C — это отдельная тема для обсуждения, не думаю что весь набор больших БД здесь сильно необходим...
Здравствуйте, Cyberax, Вы писали:
>> О транзакциях: >> 1) Оптимистичные или пессимистичные? C>Зависит от потребностей и возможностей.
Если не достаточно тех рамок, что я описал, то пусть, для примера, это будет почтовый клиент.
>> 3) Можно ли обойтись без транзакций вовсе или вынести их из движка БД на >> уровень библиотеки? C>Лучше не надо. Транзакции замечательно на уровне БД живут,
Не так уж и замечательно.
C> и прикладные транзакции очень удобно делать поверх транзакций в БД.
А зачем нам две механики транзакций, если можно обойтись одной?
Здравствуйте, Merle, Вы писали:
AVK>>1) Оптимистичные или пессимистичные? M>А какая разница, если БД однопользовательская?
Разница в необходимости скидывать на диск лог.
AVK>>3) Можно ли обойтись без транзакций вовсе или вынести их из движка БД на уровень библиотеки? M>Нет, Атомарность изменений и устойчивость, пусть лучше БД обеспечивает.
Так БД в in process варианте у нас ничуть не отличается от прикладного кода. Ладно, перефразирую вопрос — имеет ли смысл делать транзакции подстраиваемыми под конкретную задачу или жестко вшивать их в движек БД?
AndrewVK wrote: > C>Вопрос: а почему настольные БД должны отличаться от обычных БД? > Я уже ответил на него. Слишком многов них для настольных БД ненужного, > неудобного.
А я вот так не считаю.
> C> Конечно, за исключением вопросов администрирования и т.п. > А зачем их исключать. Особенно если раскрыть т.п. поподробнее?
Я имею в виду, что обычные методы и инструменты администрирования БД не
нужны для настольных. То есть бэкапы логов транзакций, например, обычно
не нужны (как и сами логи).
> C>Например, открыть один и тот же файл из разных программ. > Зачем однопользовательской БД открывать файл из разных программ?
У меня в одном проекте файл БД — это документ, который открывается
программой.
> C>Парсер и интерпретатор — это несерьезно, в общем объеме кода это будет > C>совсем немного. Сверхкрутой планировщик тоже не нужен. > Это серьезно, потому что там вылазит целый ряд проблем и ограничений. В > частности я уже не могу использовать в запросе compile-time технологии.
Тогда вам точно Boost.RTL поможет — он в compile-time строит план
запроса с помощью expression templates
> C>К нему еще написал планировщик и бэкэнд на FireBird. > Здорово. Осталось выяснить зачем это все нужно однопользовательской БД.
По очень простой причине — так как нужна БД. Например, вы не
задумывались как Outlook сортирует письма, строит дерево тредов или
делает поиск в ящиках с сотнями тысяч писем?
>> > А что конкретно лучше всего подойдет из старого? > C>Небольшая удобная БД. > Это не ответ. Что касаемо FBEmbed, то это неудобная для десктопных задач БД.
Мой опыт показывает обратное.
> C>Обычные DDL: "INSERT COLUMN INTO ..." и т.п. В сложных случаях — создать > C> новую базу и перезагрузить специальной программой миграции. > Практика показывает что: > 1) DDL не содержит команд получения информации о метаданных
Ну DDL+получение метаданных.
> 2) DDL для реструктуризации весьма неудобна > 3) В DDL нет никакой поддержки типизации и версионности, а также > автоматического контроля структуры БД и структуры данных программы.
Ну вот, сначала вы говорите про легковесность, а потом жалуетесь на
отсутствие версионности.
> C>То что мифические затраты на SQL далеко не так уж и велики. > Да да. То то я гляжу, что древний и убогий JET в янусе работает быстрее > новомодного MSSQL 2005.
Может забудем про JET вообще как про ошибку истории?
> Ужасно.
Зато оооооочень быстро
Здравствуйте, AndrewVK, Вы писали:
_FR>>… ИМХО, недопустимо, поскольку влечёт за собой перепроектирование готовой уже схемы данных или привязку создаваемой вновь к способу хранения. AVK>Я сейчас не хочу обсуждать совместимость со старым кодом. Интересно именно проектирование from scratch.
Пускай, всё равно, получается очень ограниченно. Например, исключает возможность естественных ключей… Хотя и они зачастую не пользуются популярностью… В ощем, не вижу, где не хвантило бы Guid PrimaryKey. Только то, что схема не получается универсальной
_FR>> + сохранение выражений в функциональном стиле в читаемый текст и восстановление из него. AVK>А это зачем?
Что бы запросы можно было сохранить, например, в файле конфигурации… Но там же можно хранить указание сборки\класса\метода. Согласен, отметаем.
AVK>>>2) Что лучше — выборки или навигационный способ(курсоры). _FR>>Выборки. AVK>Почему? _FR>>Без курсоров в АДО.НЕТ можно ж обходиться. AVK>Ну и что? В первых СУБД наоборот, были только курсоры и не было выборок, и тоже вроде как обходились.
Курсоры дадут возможность узнать количество записей сразу? Смысл серверных курсов какой в настольной БД? Если уж база "настольная", то пускай будет наиболее простой — попросил->получил набор. Не вижу преимущества курсора. Или просто не знаю
AVK>>>3) Должны ли типы хранится в БД вместе с данными? _FR>>Что за типы? пользовательские? От них вообще не страшно отказаться, имхо. AVK>Типы строк, а не колонок.
Тогда не понимаю
AVK>>>Какие еще аспекты БД было бы интересно рассмотреть с точки зрения описанной задачи? _FR>>Разграничение прав AVK>Для настольной однопользовательской БД???
Правильно! Отключить
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, AndrewVK, Вы писали:
AVK>Хотелось бы обсудить как могла бы выглядеть современная настольная СУБД с учетом сужения класса решаемых задач и использования новых технологий и подходов.
Все равно получается вопрос неконкретный. Зависит от того, является ли база данных самостоятельной для desktop приложения, или же использоваться как кэш для smart client или datacenter. Это те применения которые сразу приходят в голову. AVK>Более конкретный список вопросов: AVK>1) in process или out of process?
in process. Существует возможность у каждого приложения держать свою БД независимо. AVK>2) Физическая структура хранения на диске — алгоритмы, разбиение на файлы etc
Файл один. Это был и остался лучший способ, поскольку существуют оптимизации по месту хранения(типа пытаемся читать как можно последовательней). AVK>3) Описание метаданных
Должно поддерживать нахождение идентификацию объекта. AVK>4) Способ формирования запросов
Декларативный, навигационный. В принципе LINQ или XQuery декларативщина + Lazy Loading навигационный. В локальной базе данных Lazy Loading не является зазорным, и слишком дорогим. AVK>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом
Только контроль данных на БД. Остальное прикладное, или на основе поставляемых библиотек. AVK>6) Алгоримты деплоймента
Должна поддерживаться версионефикация.
Merle wrote: > C>Начали мы сохранять изменения — а тут кот выдернул шнур питания (у нас > C>настольная БД). Вот тут-то транзакционность с ACID очень даже пригодится. > Тут не ACID, тут A. И, в отличии от больших БД, здесь можно ограничиться > только Redo Only логом. > I здесь не нужно, в силу того, что БД однопользовательская, D здесь тоже > обеспечит аккуртная реализация логгирования, C — это отдельная тема для > обсуждения, не думаю что весь набор больших БД здесь сильно необходим...
Как вывод — не нужна только буква "I" ("A" нужна, "C" нужна частично,
"D" нужна по определению). В общем-то, согласен, хотя лично мне это было
очень полезно.
Например, я открываю письмо на редактирование — запускается транзакция.
При редактировании данные в этой транзакции изменяются, но я могу
переключиться на старое сообщение и посмотреть его исходный вариант.
Транзакции. Must have. Однозначно. Если еще и вложенные, то вообще замечательно.
Доступ к БД из разных приложений одновременно. Хотелось бы иметь, таки. Хотя бы в режиме: один может и читать и писать, а остальные хотя бы читать. Объясню почему: иногда какая-то программа крутиться постоянно, остановить ее нет возможности. Но вот глянуть, чтоже у него внутри базы твориться бывает необходимо. Обычно это связано с сохранением в БД ошибочных данных или с ошибочной обработкой корректных данных. Если есть возможность проверить данные в базе, не останавливая приложение, которое работает как-то странно, это очень удобно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
В случае одного файла БД он испортиться может — тогда уж кранты всему. В случае утери индекса все лечиться перестроением оного. В общем для однопользовательской БД мне кажеться это не актуально.
Мы уже победили, просто это еще не так заметно...
