Есть задача:
Легкая база данных, предназначенная на данный момент для хранения документов произвольного формата, но должна быть потенциально расширяема для хранения произвольных данных.
Хранилище данных — скорее всего, out of process, поддерживающее транзакции, пригодное для одновременной работы нескольких клиентов (нескольких запросов). Возможно, для распределенной системы. ACID, короче говоря. Оптимизация в первую очередь под рендеринг документов, во вторую — под изменение. Для текстовых документов — под поиск... Но это я забегаю вперед. Необходимость стабильности приводит к необходимости работы с физической файловой системой. Объемы хранимых данных — до нескольких насыщенных документов размером до 2000-5000 страниц одновременно.

Документ получается путем импорта, экспорта набора форматов (XML, DOC, RTF, PDF, DWG, и их будет еще), конвертеры принимают на вход файлы и должны сохранять в эту БД и, соответственно, в обратную сторону для экпорта.

Проблема номер раз:
Выбор структуры документа. Для форматов типа PDF, DWG сама собой напрашивается иерархическая БД, не такая ограниченная, как в ARX, но для текстовых лучше поступить как MS с Word'ом, используя наборы "text range". Вопрос — возможно ли в одну упряжку впрячь осла и трепетную лань, или лучше сразу вести разработку в двух (больше?) разных направлениях?

Реализация хранилища данных. Для структурного хранилища желательно избежать накладных расходов типа обработки XML, так что формат — бинарный или ASN или что-придет-в-голову-еще... Для хранилища с "диапазонами текста" остро необходимо решить проблемы с рендерингом большей части документа при расчете позиции текста далеко от его начала.

Сравнительно большие объемы данных потребуют какой-то реализации системы подкачки?

Распределенность потребует какого-то языка запросов?

И, может быть, я упустил что-то еще?

Тема абсолютно новая для меня, поэтом жду помощи от знающих людей.

Хм, можно тоже самое, но только, что ли более структурированнее.

Что за задача? Выбрать архитектуру + одну или несколько баз данных под ваш проект?

Или разработать собственную систему?

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

F>Хм, можно тоже самое, но только, что ли более структурированнее.
Пока нельзя. Сам не знаю.

F>Что за задача? Выбрать архитектуру + одну или несколько баз данных под ваш проект?
Задача — написание фреймворка для комплекта программ, работающих с документами. Часть программ уже есть, но нет фреймфорка, теперь возникла проблема унификации.

F>Или разработать собственную систему?
В худшем случае. Пока — оценить требования, представить себе архитектуру и выбрать пути решения. Возможно, покупки части логики приложения.

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

Итак, как понял:

Цель: Создать фреймворк
С чем работает: с документами
Какие бывают документы:
формат:

1. произвольного формата
   // это что такое? Возможность гибкого описания общего формата загружаемого документа, либо контроль за конкретными типами документов (cпец. хмл, спец. текстовой с заданным форматом). Вы собираетесь для документов определять что-либо кроме MIME .
   
   
2. текстовые документы
   
3. XML
   
4. DOC/RTF
   
5. PDF
   итд

объем:
большие, для DOC документов до 2000-5000 страниц
//так? а как для остальных, XML.

Какие операции необходимо поддерживать:
загрузка документа в систему (импорт)
// нагрузка на загрузку (объемы загружаемых данных/ед. времени)

выгрузка документов из системы (экспорт)
// куда? В приложение или нет.

рендеринг
// что это? Какие требования

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

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


Дополнительные вопросы:
данные строгой финансовой отчетности? повышенная стабильность данных?

поддержка транзакций

работа нескольких клиентов
// несколько или по 1000 в секунду?

большие объемы документов

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

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

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

F>Цель: Создать фреймворк

• Embedded database.
  
  1. Out of process, базируясь на .Net remoting.
     
  2. Иерархическая структура объектов. Основное направление отношений — дерево, с дополнительными перекрестными логическими ссылками между объектами.
     
  3. Транзакции и все их свойства. Необходимость грязного чтения для рендерера (ниже).
     
  4. Долговечность данных. Энергонезависимый носитель. Жесткий диск в частном случае.
     
  5. Прокси-объекты, запрет прямого доступа к данным. Желательно — персистентность данных с логикой приложения.
     
  6. Многопоточность

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

События. Обратные вызовы из БД в приложение при косвенном изменении объектов.

Логика приложения (логика клиентов, бизнес-логика). В зависимости от типа документа, меняется набор объектов, меняется логическое их взаимодействие друг на друга. Реализация на уровне подключаемых библиотек.

Система импорта/экспорта документа из файлов на диске в различных форматах. Реализуется конвертерами, которые принимают на вход файл и преобразуют его в систему объектов (линия, круг, абзац, видео-клип), сохраняя эти объекты в базе данных. И в противоположную сторону для экспорта соответственно.
F>Какие бывают документы:
F>

произвольного формата
F>// это что такое? Возможность гибкого описания общего формата загружаемого документа, либо контроль за конкретными типами документов (cпец. хмл, спец. текстовой с заданным форматом). Вы собираетесь для документов определять что-либо кроме MIME .
Пока стоит необходимость импорта/экспорта в этот "универсальный документ" данных из файлов .doc, .rtf, .pdf, .dwg, .xml, в самом ближайшем будущем список может расшириться. Из файлов выдираются ВСЕ объекты, которые известны нашим разработчикам. Затем эти объекты группируются между собой в определенную структуру (пример — распознавание PDF) и записываются в БД.

Для каждой отдельной версии каждого формата файла существует схема документа, который получается и него путем импорта. Ну, может быть, кроме .xml.

F>объем:
F>большие, для DOC документов до 2000-5000 страниц
F>//так? а как для остальных, XML.
Без разницы. Однажды импортированный документ из .doc файла объемом в 5000 страниц и размером в 300 Мб может быть затем экпортирован в любой другой формат. В случае с PDF — количество объектов в 1.000.000 — 2.000.000 (1500 страниц по 1000 объектов в среднем каждая) — совершенно штатная и реальная ситуация. Соответственно файл .pdf в этом случае весит ~50-100 Мб, документ в БД может занимать до 500 Мб (некий "распакованный" вид документа, с объектами которого быстро и просто работать).

F>Какие операции необходимо поддерживать:
F>загрузка документа в систему (импорт)
F>// нагрузка на загрузку (объемы загружаемых данных/ед. времени)
Любые в разумных пределах. Определяется конвертерами файлов, БД не должна стать узким местом. Не ниже 10-20 Мб/сек, точно. Возможно, в дальнейшем требования изменятся.

F>выгрузка документов из системы (экспорт)
F>// куда? В приложение или нет.
В файлы. Приложение работает непостредственно с документом(документами), хранящимся в базе данных.

F>рендеринг
F>// что это? Какие требования
Расчет дополнительных характеристик объектов, не хранящихся в базе данных. Например, отрисовка документа на экране. Или перерасчет физических размеров документа (в пикселях, в страницах...) при изменении одного из объектов.

F>изменение документа
F>//совсем произвольный или можно заранее указать, что может изменяться.
Указать — нельзя. Текстовый редактор, одно из применений этого фреймворка. Графический — другое.

F>полнотекстовой поиск
F>//ого, и он часто будет проходить. По каким параментрам.
Нет. Сравнительно редко. Это ручная операция, только по инициативе пользователя, в худшем случае — единицы раз в секунду.

F>данные строгой финансовой отчетности? повышенная стабильность данных?
Стабильность на уровне: выключили питание машины — включили, вернулось все, кроме незавершенных транзакций.

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

F>работа нескольких клиентов
F>// несколько или по 1000 в секунду?
Пока думается — не 1000. На одной физической машине: В штатном однопользовательском режиме — до 4-5 обращений одновременно. В многопользовательском режиме — 20 или больше одновременных обращений. При работе в сети (пока реальные требования к этому режиму непонятны) — до 20 пользователей, значит 100-150 одновременных обращений. Последнее — один большой вопрос.

F>большие объемы документов
Большие. Никто не требует загрузить в память (хотя...) каталог документов на диске общим весом в 2 терабайта, но файлы до 500 Мб по крайней мере не должны ронять базу данных.

F>распределенность
F>// чего? Приложение должно быть установлено в нескольких местах, или просто репликация на уровне базы
Сейчас — серверный процесс (служба Windows NT ?), клиентский процесс работает с документом в базе данных. Или — сейчас же — 5-6 клиентских приложений (5-6 открытых окон с разными докуемнтами). В перспетиве простенькая система учета документов с удаленным редактированием/версиями, хотелось бы использовать этот фреймворк и для нее.

A.

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


F>>Цель: Создать фреймворк
A>

A>
• Embedded database.
  A>
  
  A>
  1. Out of process, базируясь на .Net remoting.
     A>
  2. Иерархическая структура объектов. Основное направление отношений — дерево, с дополнительными перекрестными логическими ссылками между объектами.
     A>
  3. Транзакции и все их свойства. Необходимость грязного чтения для рендерера (ниже).
     A>
  4. Долговечность данных. Энергонезависимый носитель. Жесткий диск в частном случае.
     A>
  5. Прокси-объекты, запрет прямого доступа к данным. Желательно — персистентность данных с логикой приложения.
     A>
  6. Многопоточность
     A>

Что такое Embedded? Вы говорите, о базе, внедренной на стороне клиента(с вашим приложением)? Или нет?


A>

Логика базы даных. Реализация как минимум триггеров, очередей сообщений и хранимых функций.
Вот я до сих пор не понимаю. Вы что, собственную базу пишете, что их надо разрабатывать? Еще могу представить, что вам нужны какие-либо высокоуровневые триггеры (завязанные на к-л объекты), но остальное зачем реализовывать? Берите Cache, если уж совсем все настолько иерархическое и необходима поддержка ОО на уровне внутреннего языка базы.

A>

События. Обратные вызовы из БД в приложение при косвенном изменении объектов.
Сорри, это вообще возможно?
Т,е чтобы серверный код (при изменении некоторой записи\объекта на сервере) сделал вызов кода приложения(объекта приложения, которое связанно с этими изменными данными), причем серверный код и код приложения, находятся совсем в разных адресн. пространствах (на разных машинах)?
Мне кажется, либо приложение будет иметь некоторый listener, принимающий оповещения от остального мира (мини-сервер), либо переодически должно будет опрашивать серв. код. Однако в последнем случае, RealTime (или что-то сравнимое) вы не получите, либо потеряете в быстродействии кода приложения, IMHO. Возможно не прав . Либо....
Кстати у вас язык приложения и сервеный — один (net)?

A>

Логика приложения (логика клиентов, бизнес-логика). В зависимости от типа документа, меняется набор объектов, меняется логическое их взаимодействие друг на друга. Реализация на уровне подключаемых библиотек.

Т.е для каждого типа документа у вас подключается библиотека, содержащая объекты, которые распознают "известные" конструкции выбранного типа (например, paragraph в word?).

A>

Система импорта/экспорта документа из файлов на диске в различных форматах. Реализуется конвертерами, которые принимают на вход файл и преобразуют его в систему объектов (линия, круг, абзац, видео-клип), сохраняя эти объекты в базе данных. И в противоположную сторону для экспорта соответственно.
A>
F>>Какие бывают документы:
F>>

произвольного формата
F>>// это что такое? Возможность гибкого описания общего формата загружаемого документа, либо контроль за конкретными типами документов (cпец. хмл, спец. текстовой с заданным форматом). Вы собираетесь для документов определять что-либо кроме MIME .
A>Пока стоит необходимость импорта/экспорта в этот "универсальный документ" данных из файлов .doc, .rtf, .pdf, .dwg, .xml, в самом ближайшем будущем список может расшириться. Из файлов выдираются ВСЕ объекты, которые известны нашим разработчикам. Затем эти объекты группируются между собой в определенную структуру (пример — распознавание PDF) и записываются в БД.


Можно о требованиях "к дополнительными перекрестными логическими ссылками между объектами".

A>Для каждой отдельной версии каждого формата файла существует схема документа, который получается и него путем импорта. Ну, может быть, кроме .xml.

Не понял, какая может быть схема у doc, если для вас например, важны лишь paragraph{}.

F>>объем:
F>>большие, для DOC документов до 2000-5000 страниц
F>>//так? а как для остальных, XML.
A>Без разницы. Однажды импортированный документ из .doc файла объемом в 5000 страниц и размером в 300 Мб может быть затем экпортирован в любой другой формат. В случае с PDF — количество объектов в 1.000.000 — 2.000.000 (1500 страниц по 1000 объектов в среднем каждая) — совершенно штатная и реальная ситуация. Соответственно файл .pdf в этом случае весит ~50-100 Мб, документ в БД может занимать до 500 Мб (некий "распакованный" вид документа, с объектами которого быстро и просто работать).

Еще один вопрос, ты здесь говоришь о импорте документа из одного формата в другой.
1) Не слишком ли тяжелая задача?
2) Для вас ведь важны лишь некоторые "интересные для вас сущности документа", для которых у вас будут и созданны объекты, но что тогда про остальную информацию. Ведь, чтобы корректно отобразить 1ф на 2-ой нужно знать ВСЕ о обоих форматах и их приведении


F>>рендеринг
F>>// что это? Какие требования
A>Расчет дополнительных характеристик объектов, не хранящихся в базе данных. Например, отрисовка документа на экране. Или перерасчет физических размеров документа (в пикселях, в страницах...) при изменении одного из объектов.

Это можно вывести в отдельный Service Layer, или при рендеринге может понадобиться расчитать ПРОИЗВОЛЬНЫЕ доп. хар. объектов документа.

[scipped]
промышл. б.д эти вещи поддерживают.

F>>распределенность
F>>// чего? Приложение должно быть установлено в нескольких местах, или просто репликация на уровне базы
A>Сейчас — серверный процесс (служба Windows NT ?), клиентский процесс работает с документом в базе данных. Или — сейчас же — 5-6 клиентских приложений (5-6 открытых окон с разными документами). В перспетиве простенькая система учета документов с удаленным редактированием/версиями, хотелось бы использовать этот фреймворк и для нее.

Значит версионность тоже надо?

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

F>Что такое Embedded? Вы говорите, о базе, внедренной на стороне клиента(с вашим приложением)? Или нет?
Эээ... Embedded database — база данных, внедренная в приложение, какие еще могут быть трактовки?
Т.е. в НЕ использование сторонних коммерческих продуктов типа MS SQL Server, Cache и т.п. Внедрение на стороне клиента имеет смысл обсуждать только для нераспределенной системы?
Скажем так, основное требование — small footprint. Внедренность — это уже вытекающее свойство, возможно согласиться не на модуль, внедряемый в наше приложение, а на отдельно-стоящую программу (отдельный процесс, отдельные настройки и все связанное..), если эта база будет ну очень уж легкой. Типа там SOD2, иже с ним, только не такой сырой.
Вообще, продукт поставляется в виде пакета объемом до 20-30 Мб. Ну зачем же с ним тащить Cache, который 153 метра в инсталляторе весит...

F>Вот я до сих пор не понимаю. Вы что, собственную базу пишете, что их надо разрабатывать?
Гм. я же написал вроде как.

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

Целью является выпустить продукт, а не написать БД. Если первое потребует второе, куда ж деваться... Если нет, я оставшееся время прогуляю в ближайшем ресторане
F>Берите Cache, если уж совсем все настолько иерархическое и необходима поддержка ОО на уровне внутреннего языка базы.
Уже взял. Как взял, так и отдал — не та весовая категория.

A>>

События. Обратные вызовы из БД в приложение при косвенном изменении объектов.
F>Сорри, это вообще возможно?
Ага. Вообще о выделени отдельного звена "логики приложения" заставляет говорить только применение этого фреймворка в нескольких разных продуктах. Иначе бы вообще все было как хед-энд-шолдерс, в одном флаконе.

F>Мне кажется, либо приложение будет иметь некоторый listener, принимающий оповещения от остального мира (мини-сервер), либо переодически должно будет опрашивать серв. код. Однако в последнем случае, RealTime (или что-то сравнимое) вы не получите, либо потеряете в быстродействии кода приложения, IMHO. Возможно не прав . Либо....
...либо что-то другое. Согласен на 100%, только рано еще это обсуждать. Может и не будет листенера, если купим что-то стороннее, а там это уже будет реализовано.
F>Кстати у вас язык приложения и сервеный — один (net)?
Есть наследие в виде одной C++ программы, в ней уже есть "база данных", состоящая из коллекций, но следующая версия ее будет писаться на C#. Т.е. какое-то внимание совместимости с win32 уделить придется, но это далеко не самый главный фактор.

F>Т.е для каждого типа документа у вас подключается библиотека, содержащая объекты, которые распознают "известные" конструкции выбранного типа (например, paragraph в word?).
В точечности так.
Ну, пусть не параграф, его-то как раз имеет смысл определить на общем уровне, чем писать раз за разом для разных форматов...

F>Можно о требованиях "к дополнительными перекрестными логическими ссылками между объектами".
Конечно, можно. Оглавление на первой странице документа в том же ворде.

A>>Для каждой отдельной версии каждого формата файла существует схема документа, который получается и него путем импорта. Ну, может быть, кроме .xml.
F>Не понял, какая может быть схема у doc, если для вас например, важны лишь paragraph{}.
Этого я не говорил Важно все. Параграф, линий, заголовок, жирность, колонтитул, все что найдем.

F>Еще один вопрос, ты здесь говоришь о импорте документа из одного формата в другой.
F>1) Не слишком ли тяжелая задача?
Не я ее ставил.
F>2) Для вас ведь важны лишь некоторые "интересные для вас сущности документа", для которых у вас будут и созданны объекты, но что тогда про остальную информацию. Ведь, чтобы корректно отобразить 1ф на 2-ой нужно знать ВСЕ о обоих форматах и их приведении
В идеале — да. Но это уже вопрос RoundTrip'ов. Импортировал, экспортировал, сравнил 2 файла побайтно, совпало... Такой задачи никто не ставил, заказчик прекрасно понимает, что в таком случае придется говорить об утопии и стоимость решения задачи стремится к бесконечности. К тому же, вероятность 100% совместимости 2 разных форматов — тоже вилами на воде...

F>>>рендеринг
F>Это можно вывести в отдельный Service Layer, или при рендеринге может понадобиться расчитать ПРОИЗВОЛЬНЫЕ доп. хар. объектов документа.
Можно. Пока так и думаем сделать, реализовав некоторый кэш в этом "слое". Есть, правда, проблемы с попадаемостью кэша и еще по мелочам, но это все чисто технические проблемы.

F>[scipped]
F>промышл. б.д эти вещи поддерживают.
Точно. Вот только сколько они добавят к стоимости продукта?

F>Значит версионность тоже надо?
На этот вопрос я пока ответить не готов. Маячит на горизонте еще один проект, отошлем заказчику предложение по архитектуре и посмотрим, имеет ли смысл говорить об общем решении. Пока версионнности не надо.