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

>Причём тут маш. коды? В них писать трудно.
Каюсь, с машинными кодами я маленько поспешил, это не следущий, это через один шаг. Следующим должен был быть ассемблер для РС. Скорость - ууу!!!... Сложности - по барабану, настоящие пацаны не бояцца, когда трудно. Микрософт опять же не нужен. ДОС ( 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