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

Гмммм, ни одной реплики за сутки. Что, никто не занимался что-ли? Или кто занимался, сюда не ходят??? :-)

Ага, нету, нету там определения что такое встраиваемая СУБД... Насколько я знаю, жесткого определения этого понятия вообще нет. Можно так сформулировать, например: встраиваемая СУБД - это то, что не поставляется в виде отдельного продукта (может быть поставка в виде набора библиотек); не требует отдельного процесса установки; не требует внешнего администрирования и длительной ручной заточки; обладает такими чертами СУБД как поддержка многопользовательского режима работы и обеспечения ссылочной и транзакционнной целостности.

Чтобы еще понятнее стало, сравним с MSSQL, вспомним, что для его установки надо:
1. IBM-PC compatible computer; (об этом обычно и не вспоминают даже)
2. OS Windows; (не забудем здесь про процесс инсталляции и лицензии на ОС)
3. MSSQL; (опять же не забудем здесь про процесс инсталляции и лицензии уже на MSSQL)
4. Администратор MSSQL

Меня интересует информация о продуктах с подобными характеристиками встраиваемых систем. Вернее, опыт испоьзования чего-то подобного. Просто информации в Интернете довольно много, но она весьма однобока - там в основном расхваливаются достоинства систем, и ни слова - о недостатках.

Пример - тот же IB. Если сходим сюда: http://www.ibase.ru/devinfo/dontdoit.htm , то увидим замечательную фразу в п.2. - "Не надо выбирать на клиента большие обьемы данных - человек все равно не в состоянии просмотреть 100 000 записей". Хоршая фраза, правильная, мне нравится. А что делать, если клиент - это другой процесс и запрос на получения 10^5-10^6 записей для него явление обычное? А что если таких процессов несколько?

А теперь представьте что получится, если был выбран IB, а подобного рода подводные камни были неизвестны. Где-то на этапе тестирования на рельных данных запросто может вылезти такой недостаток функциональности. Дальше развитие событий додумайте сами.

2 All
Я не претендую на полноту описания того, что же такое встраиваемая СУБД. Кто может это сделать лучше - сделайте, я только за.

А сформулированный набор требований описывает больше то, что мне нужно в данный момент. Поскольку сей набор перекликается с тем, что в принципе должно быть в развитой встраиваемой СУБД, то вполне возможно одна из таких СУБД может послужить основой для решения частной задачи. Поэтому и интересна любая относящаяся к делу информация.

Да, кстати, вот еще один пункт, который можно добавить:
5. Не требует отдельного лицензирования; лицензия на готовый продукт, использующий встроенную СУБД, включает в себя и лицензию на саму СУБД.


2 Дед Маздай
Ответ: не знаю. Смотря что хочется понимать под встроенными СУБД.

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

Пример, кстати, неявно ограничен использованием ОС Windows & PC. Если продается что-то более нетривиальное, нежели бухгалтерская программа, это может стать проблемой.

Так, стоп, не надо все в одну кучу валить. Давайте мухи - отдельно, котлеты - отдельно.

Сначала определимся - что куда встраивается???... Я так понимаю существует по крайней мере две интерпретации "встроенности":
1. Софт (какой-то) встроен в железо (какое-то).
2. Софт (какой-то) встроен в другой софт.
Меня интересовал второй случай - когда можно взять готовый кусок (СУБД типа Raima DM) и обернуть его чем-то ещё. Чем - уже не так принципиально, т.к. в любом случае создавать "с нуля" собственную СУБД долго, сложно, затратно и ненадежно.

В дискуссию в духе: является ли такая-то ОС встраиваемой или нет я вступать во-первых, не хочу, а во-вторых, предметом (информацией о Windows XP Embedded и Windows CE) не владею. Так что польза от умозрительных заключений будет весьма сомнительна. :-)


PS. Чтобы запускаться с CD надо иметь CD-ROM. Какой смысл менять HDD на CD-ROM?

MSDE не устраивает тем, что это MS, из чего автоматически следует два слова - PC (Intel) и Windows. А хочется иметь кросс-платформенность хотя бы на множестве (Windows+основные разновидности Unix)+(те аппаратные платформы, на которых они работают).

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

Так в чем принципиальность-то, я что-то не понял???...

Да, кстати... Я тут покопался в теории того, каким требованиям должна отвечать развитая СУБД и в общем-то пришел к выводу, что собственную СУБД "с нуля" писать - это скорее всего не "проще". По соотношению время/цена разработки/итоговое качество такая СУБД скорее всего будет хуже существующих известных систем, хотя, возможно, будет надежной и обладать необходимой функциональностью. Если спонсор решит что надо - сделаем, только это будет либо долго, либо дорого.

>А для чего такой БД КРОССПЛАТФОРМЕННОСТЬ?

Ответ: надо. Если хотите более формально, есть такое жесткое условие в требованиях. Если хотите более неформально - ваши 95% относятся к сегменту рынка, который занимает отнюдь не 100% всего существующего рынка => есть спрос и на другие продукты => возникают вопросы о создании таких приложений.

>Какие клиентские приложения могут работать кроссплатформенно?
Любые написанные с этой целью на Java. Если же следовать только вашей "логике", то и сам язык Java, например не нужен был вообще - все равно "все" работают на MS, что из-за 5% огород городить???...

От дальнейшей дискуссии в духе "ваши проблемы надуманы, давайте дружно перейдем на продукты MS" я с вашего позволения уклоняюсь.

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

>Нехороший ты человек. Угрюмый.
Да не, это болею я просто, а так я белый и пушистый...

>Причём тут маш. коды? В них писать трудно.
Каюсь, с машинными кодами я маленько поспешил, это не следущий, это через один шаг. Следующим должен был быть ассемблер для РС. Скорость - ууу!!!... Сложности - по барабану, настоящие пацаны не бояцца, когда трудно. Микрософт опять же не нужен. ДОС ( MS DOS), правда, сейчас неизвестно где остался, но и это - не проблема, напряжем маркетинг, пусть костьми лягут, но отыщут заветные коробочки, стряхнут с них пыль и выдадут за последнее слово техники. Лозунг им придумаем в духе: "Назад, к мэйнфреймам!!!" А что, круто, как у настоящих пацанов получится.. :-Р

PS. Краденые базы на сидюках не покупал - не нужно было.

Что-то разговор в сторону от темы пошел... Давайте-ка я его обратно направлю.

Касательно определения того, что же все-таки за зверь такой - встраиваемая СУБД, я, маленько порывшись, нашел следующее описание:

What Is an Embedded DBMS?

AN EMBEDDED DBMS is one that may be embedded entirely within a software tool or application, requiring no direct user interaction or administration. Such a DBMS delivers capabilities that are necessary for any tool or application that is complex, flexible in its operation, and entirely self-contained. At this early stage, there appear to be two types of embedded DBMSs. One is that which provides the tool or application with a means of manipulating table-oriented data (such as conventional business data) within itself, either to provide a self-contained business function that interacts with a wider external database environment, or to provide occasionally connected remote access to enterprise data. The other is to provide an efficient yet reliable and recoverable means of storing and retrieving data that is complex and highly individuated either in structure or form and bound to functional components of the application or tool. The former case is covered by embedded relational or object-relational DBMS (RDBMS) products, while the latter calls for an embedded object DBMS (ODBMS).

Driving the increasing need for embedded databases is continued growth of the packaged applications market, distributed (particularly mobile) computing, and Java-based applications. The packaged applications market is seeing an increasing need for tools and applications with complex data management capabilities that are simple to understand and manage. Additionally, the increase in distributed, mobile computing has engendered the demand for increasingly functional portable devices needing local data storage for autonomous, disconnected operation. These mobile products have similar, if not more rigorous, requirements than packaged applications and are fueling opportunities for embedded databases. Lastly, as the use of Java continues to expand, particularly towards the low-end, it drives the need for local persistent storage for both Java programs and data. Applications in these areas require high-performance, small-footprint, tunable, self-managing, embedded databases.

Source:
http://www.progress.com/profiles/1999_05/guestview.htm

>работает и работает хорошо

1.1. Какой именно программный продукт?
1.2. Для каких именно задач?
(CD с ворованными базами в расчет принимать не хочу - не верю, что там была особая разработка; скорее всего написали на скорую руку лишь бы как-то шевелилось и ни анализом, ни архитектурой, ни дизайном никто особо не занимался. О сопровождении я уже не говорю, да и режим их использования - однопользовательский read-only)

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

В моем конкретном случае прежде чем сказать, подходит что-то или нет надо получить очень четкие (и достоверные) ответы еще на такие вопросы:

2. Существует ли поддержка многопользовательского режим доступа и работы на различных платформах? Насколько это все надежно?

3. Насколько сложно (затратно, ненадежно) подключать непредусмотренные изначальной конструкцией вещи? Например, передавать данные в новом формате?

4. Есть ли поддержка транзакций и на каком уровне? Насколько надежно работет?

5. Восстановление после сбоев? Уровень поддержки (после мягких или после жестких тоже)?

6. Список известных багов и пропущенной функциональности?

7. Условия лицензии при дальнейшем распространении?

8. Тех. поддержка в дальнейшем и ее условия? (В частности исправление выявленных багов, сроки и качество этих исправлений)

И все это усугубляется тем, что в секторе встраиваемых СУБД нет чего-то явно выраженного, как Oracle или MSSQL, раз; народу, который бы имел успешный опыт работы с подобными системами, очень мало, два; более ли менее достоверной информации тоже негусто - три; на сайтах коммерческих СУБД больше красивые коробочки рисуют и говорят, что вот именно они сделают вам райскую жизнь; в OpenSource-ах наоборот - списки отсутствующей функциональности и непофикшеных багов впечатляют, четыре... Альтернатива - написание собственной СУБД, но эта задача похоже не по зубам для разумного соотношения сроки/стоимость/функциональность/качество, пять.

Вот блин и решаешь головоломку, а вы тут FoxPro под DOS, мл...

Ага, по IB/FB я тоже подумал. Один момент правда смущает - тут:
http://www.ibase.ru/devinfo/dontdoit.htm описано чего не надо делать с IB/FB, в т.ч.:

2. Не надо выбирать на клиента большие обьемы данных
Человек все равно не в состоянии просмотреть 100 000 записей :-)

Этот момент может порушить все, т.к. собственно база планируется небольшая (не более 10^7 записей), а вот зачитка информации из нее - регулярная и весьма интенсивная - выборка в объемом в 10^4-10^5 записей будет явлением обычным. Я так потихоньку прихожу к мысли, что придется сначала выбрать несколько вариантов более ли менее подходящих, а потом основательно тестировать.

Кстати, предложения не ограничиваются IB/FB, тут периодически еще слово Raima (RDM) возникает - но у меня лично опыт работы с Raima равен нулю, ничего не могу сказать. То, что будет что-то незнакомое - не смущает, разобраться не проблема и время на это дают, но вот хотелось бы как-то априорно выяснить, что там есть, и что того, что есть, хватит для конкретного проекта. А с десятком систем - увы и ах - основательно познакомиться не получится по понятным причинам.

А подумать??? ;-)

Задачу-то представить очень просто. Стоит только забыть о том, что клиент - это обязательно человек, который эту пачку данных будет вручную просматривать. Например, система такого рода:

1. Основной сервер - место, где хранится информация. Периодически она в нем обновляется, меняется, что-то с ней происходит, короче. Иногда эти процессы обработки интенсивны, иногда нет. Объем информации - до 10^7 строк. (хорошо хоть это известно, с террабайтами связываться не надо ;-)

N штук вспомогательных серверов, на которых хранятся полные копии одной или нескольких БД с основного сервера. Периодически они синхронизируются с основным сервером. Вот вам и массовая зачитка получилась. Что-то типа систем с репликацией данных.

Так что с представлением проблем нет, имеют место быть проблемы с методологией решения.

PS. Обратите, пожалуйста, внимание - я не говорю, что у нас именно такая проблема, (хотя отдельные ее черты имеют место быть) просто задача регулярного чтения весьма насущная.

>А дальше?

*терпеливо разъясняет*

А про то что дальше происходит, уже было написано - происходит синхронизация (односторонняя, что несколько упрощает дело). Читаем с основного, пишем на вспомогательный. В момент синхронизации как раз и происходит массовая выборка (вплоть до полного копирования всей базы) записей.

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

Хотя идея реализации timesamp для последующего snapshot-а кажется заманчивой, но я думаю в ней тоже есть масса неочевидных вещей - придется поддерживать временную алгоритмами и представлениями, база распухнет пропорциональисторию, RDBMS насколько я знаю встроенных средств для этого не имеют, придется городить огород с собственными но количеству хранимых временных состояний и т.д. и т.п. Одни часовые пояса чего стоить будут. Сложность вырастет значительно (и количество ошибок тоже), а вот выгода - лишь уменьшение сетевого траффика и нагрузки на центральный сервер, что в общем-то неактуально.


PS. Ссылок про репликацию подкинуть или яндексом уже сами умеем пользоваться? А то могу научить, недорого.
;-)

Чего-то глюкнуло при отправке, последний абзац в предыдущей реплике следует читать так:

Хотя идея реализации timesamp для последующего snapshot-а кажется заманчивой, но я думаю в ней тоже есть масса неочевидных вещей - придется поддерживать временную историю, RDBMS насколько я знаю встроенных средств для этого не имеют, придется городить огород с собственными алгоритмами и представлениями, база распухнет пропорционально количеству хранимых временных состояний и т.д. и т.п. Одни часовые пояса чего стоить будут. Сложность вырастет значительно (и количество ошибок тоже), а вот выгода - лишь уменьшение сетевого траффика и нагрузки на центральный сервер, что в общем-то неактуально.

>Господин СиРунер, говорите точно - скока вешать? \r
Говорю точно - скока надо, столько и вешать, чего ж тут непонятного-то??? ;-)\r
\r
Репликация сама по себе не нужна - нужна возможность регулярной зачитки большого количества данных (от 50 до 100% всего объема) из относительно небольшой базы. Данные - структурированные, но структура распихивается по плоским таблицам. Специфика данных, объем и режим их обработки более ли менее известен, возможны лишь небольшие вариации. \r
\r
На данный момент это все реализовано в MSSQL. По ряду причин хочется уйти от MSSQL. Куда уйти - на данный момент неясно. Либо на другую СУБД, которая может работать на Unix и Windows, либо использовать что-то из встраиваемых систем, либо написать собственную систему, которая будет реализовывать необходимую функциональность. Каждый из вариантов имеет свои плюсы и минусы.\r
\r
Брать готовую СУБД - это самое простое, на первый взгляд. Но только на первый - непонятно что брать, как это будет работать, с какими непредусмотренными ограничениями столкнемся (пример - тут: ). Плюс этот подход не позволяет что-то кардинально улучшить в архитектуре системы, заменим одну гайку на другую, добавим кроссплатформенность (неизвестно еще какую) и сколько-то неизвестных проблем. А гайка останется гайкой, хотя этот вариант пожалуй наименее рискованный.\r
\r
Второй подход - использовать встраиваемую СУБД - очень привлекателен тем, что можно с одной стороны использовать уже готовую функциональность в части многопользовательского режима доступа и управления транзакциями, а с другой - в оболочке дописать то, чего не хватает в самой встроенной СУБД. Но риски тут выше - если про "полноценные" СУБД можно найти более ли менее вменяемую информацию, то встраиваемые - это темный лес пока; как это все будет стыковаться с остальными частями системы - тоже непонятно; насколько много придется дописывать - неизвестно.\r
\r
Ну и третий - написать все "с нуля". Можно сделать все, что надо, но после изучения того, что должно быть в более ли менее приличной СУБД и как это все должно быть сделано, я пришел к выводу что этот вариант скорее всего - не наш. Слишком много усилий и слишком непредсказуемый результат. Хотя если существенно покоцать требования к системе, оставив примитивные механизмы контороля - то и такую штуку можно сваять. СУБД это правда язык не повернется назвать. \r
\r
\r
Вот такая блин штука - пироги с котятами - ты их ешь, а они мяукают. ;-)\r
\r
Хотя это я вам уже отфильтрованную информацию выдаю, про ту кашу, что мне на уши падает, я скромно умолчу. Да и если бы мне все было понятно - набо было бы что-то спрашивать вообще??? ;-)

Ух ты, как в предыдущей реплике засинело-то все. А я-то хотел всего-навсего ссылку прописать:\r
\r
/topic/18184