Dmitry Arefievromaroлокальную БД для внесения заказов с последующей выгрузкой в основную БД.
А какая "основная БД" ? Если у нее найдутся встраиваемые родственники, то
они кандидаты номер один, в условиях фактического отсутствия технических
требований ...

SQLite можно и как основную использовать, тогда перенос данных тривиален - с помощью attach database. До 100 гиг БД прекрасно работает, больше не пробовал, надобности нет.

romaroСпасибо за помощь. Решено работать с SQLite через ADO.NET, чтобы при необходимости не возникло трудности при переходе на более продвинутую встраиваемую СУБД.

Вы думаете, что в ближайшем времени такую напишут? :-)

White OwlMBGromaroСпасибо за помощь. Решено работать с SQLite через ADO.NET, чтобы при необходимости не возникло трудности при переходе на более продвинутую встраиваемую СУБД.

Вы думаете, что в ближайшем времени такую напишут? :-)Давно уже есть. SQL Anywhere называется.
Самая навороченная и удобная СУБД, с самым умным диалектом SQL. Может работать как в режиме встроенной базы так и в режиме нормального сервера. К ней можно ходить откуда угодно, хоть из ADO.NET, хоть из ODBC хоть через TDS. Минимальные требования к администрированию.
Единственный "минус" - за нее денег хотят, хоть и не больших, но все же денег.

http://www.sql.ru/faq/faq_topic.aspx?fid=411

Посмотрел.
1. Во-первых, исходников нет, и как к ней модули писать?
2. На винмобайл почему-то формат хранения другой, как уж они там рекомендуют базы переносить, непонятно (к примеру, в системе мерчендайзинга у меня эскулайт базы копируются с сервера на кпк и наоборот).
3. Про ADO.NET ничего не знаю, с ODBC когда-то сталкивался, когда приходилось с виндой работать - производительность аховая и никаких расширений SQL не поддерживается, про TDS не в курсе. А вот сделать биндинг для своего языка нельзя и это плохо.
4. В движок напихано много такого, что далеко не всем нужно, а выкинуть нельзя - см. пункт 1. Лучше набор модулей, которые можно вкомпилировать при сборке движка СУБД или загрузить динамически. Далеко не на всех устройствах есть много дискового пространства и большой объем ОЗУ (например, железки типа 133 МГц проц и 8 Мб ПЗУ плюс 32 Мб ОЗУ бывают многозадачными серверами - там можно дебиан запустить, веб-сервер или сервер приложений и эскулайт с базой на флэшке в несколько гиг или более).
5. Невозможно сделать сборку со своими параметрами (размер дисковой страницы, буферы и проч.) - см. пункт 1.
6. Про оптимизатор запросов явное преувеличение - во всех СУБД приходится смотреть планы выполнения, не существует СУБД, которая абсолютно любой запрос выполнит "оптимально" (в кавычках потому, что критерии оптимальности зависят от задачи) - исскуственного интеллекта с телепатическими способностями пока не придумали :-) В эскулайт оптимизатор не умеет "много гитик", но зато логика его работы строго детерминирована и не требует бубна для отладки.
7. Это не встраиваемая СУБД, а клиент-серверная "с возможностью...". Встраиваемые СУБД должны иметь возможность сборки для урезанными возможностями для поддержки различных архитектур ( как пример, iPhone использует эскулайт).

И так далее...

Вот поддержка OLAP функций может быть плюсом, в эскулайте нет такого. Все или почти все остальное есть или в движке эскулайт или в виде модулей. Насчет репликации вопрос интересный, поскольку rsync для эскулайт базы никто не отменял, а мгновенные снапшоты современные ФС делать умеют (для репликации мастер-слэйв достаточно read-only снимка); если же файловая репликация почему-либо не устраивает, для эскулайта можно воспользоваться дополнительными модулями.

Далее, насчет клиент-серверной реализации - см.
http://sqlitedbms.sourceforge.net/index.htm
Как видите, на основе хорошего движка можно сделать сильно "фичастую" реализацию - но это далеко не всем и не всегда нужно.

Как резюме - если вы "близко знакомы" с каким-то отдельным решением, из этого не следует, что оно лучшее.

White Owl
1. Исходники нафиг не нужны, если сам движок править не будешь. А кто ж даст править коммерческий движок? А модули писать к ней просто на самом деле, документация очень полная и все что надо там расписано. Впрочем лично я дальше тестового модуля не пошел - не нужно.

Почему нельзя править для себя честно купленный коммерческий движок? Машины ведь тюнингуют, и это считается абсолютно законным.

White Owl
2. Другой формат хранения существует "по историческим причинам". На Blackberry я ставил полноценный локальный сервер - все прекрасно работало.

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

White Owl
3. Ну тут вы извините, того... пальцем в небо. Во первых, ODBC не обязано поддерживать расширений, оно просто отдает команду на сервер и тот уже с ней работает. Так что тут никаких проблем нет абсолютно. TDS - поддерживается по историческим причинам, я его упомянул только потому что этот транспорт многим серверам знаком. А биндинг для своего языка сделать - проще простого. Впрочем, чаще всего с SA используется простой ODBC - все летает.

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

White Owl
4. А что выкидывать надо, простите? Я понимаю что это царапает душу любителя исходников (сам такой), но вот давай для примера: что ты выкинул из движка SQLite?


В основном добавлял :-) Например, поправил код инициализации, чтобы добавленные мной расширения загружались автоматически, убрал некоторые ограничения (скажем, сейчас запрещено создавать виды, обращающиеся к таблицам приаттаченных баз, а мне это нужно). Поскольку эскулайт собирается как движок плюс набор расширений, можно на этапе компиляции указать только необходимые расширения. Вот кусок rules deb-пакета из моего репозитория:


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

White Owl
5. Возможно. Только не сборку а базу. Когда базу инициализируешь можешь указывать любой желаемый размер страницы, а когда запускаешь сервер указываешь сколько памяти сожрать под кеши. Можно даже всю имеющуюся отдать :)

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

White Owl
6. :) Нет, не преувеличение. Оптимизатор там действительно самый умный на сегодняшний день из всех СУБД.

Человеческую речь распознает? Если нет, принципиального отличия от оптимизатора других СУБД не вижу :-)

White Owl
7. Если сервер может стартануть автоматом при попытке подключиться к нему и полностью выключиться после ухода последнего коннекта - на мой взгляд это вполне себе встраиваемая СУБД :)
И кстати на iPhone оно тоже встает без проблем :)

"Нужна мне эта самодеятельность" (с). Встраиваемые СУБД можно встроить в приложение - то есть скомпилировать вместе с кодом приложения. То, о чем говорите вы, это нечто совсем иное. И более того, встраиваемая СУБД должна иметь лицензию BSD, Public Domain или близкую к ним, иначе нельзя будет делать коммерческие приложения, "затачивая" СУБД под своим нужды.

Далее, при использовании сервера падает масштабируемость и увеличивается потребление ресурсов для single-user варианта использования, в то время как встраиваемые СУБД масштабируются линейно - независимые процессы могут исполняться на разных ядрах независимо (да, требуется распараллеливание на уровне приложения или ОС, но это окупается).

White Owl
MBGКак резюме - если вы "близко знакомы" с каким-то отдельным решением, из этого не следует, что оно лучшее.Верно, на все 100%. Поэтому мой выбор - SA если у заказчика есть деньги и SQLite если денег нет.

Есть нюанс - когда у заказчика есть деньги, то он может оплатить специальную сборку эскулайт с нужными модулями, оптимизацией и т.п. Или можно взять готовую, например, по одной из ссылок на офсайте. А также можно пользоваться просто эскулайтом с офсайта - несколько модулей в него уже включено.

Замечу, что SQLite выделяется еще и модульной архитектурой, что позволяет прикладным разработчикам реализовать фактически любую функциональность, не трогая основного ядра. Любые монолитные СУБД, в том числе SQL Anywhere, на этом фоне оказываются мастодонтами (в смысле, заведомо устаревшими). Коммерческие производители отказываются прислушаться к Стоунбрейкеру, когда тот говорит о необходимости модульности всех систем (в т.ч. журналирования), т.к. им невыгодно переделывать продающийся продукт. Разумеется, задачи многих пользователей зачастую решаются любой современной СУБД, но раз уж речь у нас идет именно о перспективе, то SQLite оказывается лучшим выбором.

White OwlMBGВот кусок rules deb-пакета из моего репозитория:Вот смотрю я на этот список... Да, имеет смысл. Пожалуй сам возьму его на вооружение когда в следующий раз буду SQLite собирать. Но... а вот у нас в SA это все уже есть... :) Ну кроме MD5 - оно редко когда нужно, а если все же понадобиться, можно и внешний модуль написать.

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

Часть из этих расширений, если не ошибаюсь, используется в sqliteman, у коророго есть виндовая сборка - можете там посмотреть (сам тестирую только под debian, хотя многие модули никак от платформы не зависят).

White Owl
Человеческую речь - нет. Но превратить запрос с подзапросами в один запрос с inner или outer join может.

Планы выполнения в случае подзапросов и join-ов могут совпадать, а вот предварительные преобразования - не более чем костыль.

White Owl И вообще, с SMP у SA проблем нет :) Eсли на машине есть несколько процессоров, SA может их все задействовать даже в случае одного единственного запроса. Один процессор будет один подзапрос обрабатывать другой вторым подзапросом займется, третий будет результаты сводить в одну кучку...

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

White Owl
Мои критерии выбора:
- Заказчик готов платить не только разработчику.
- Заказчику требуется репликация.
- Если у заказчика есть (хотя бы в отдаленных планах) желание разделить клиентское приложение с базой данных и пустить в базу нескольких пользователей одновременно.
Тогда я выбираю SA.

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

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

White OwlMBG,

Если честно, мне сегодня совсем не хочется вести священные войны :)
SQLite - замечательная штука и я сам ее часто использую. Иногда меня огорчает ее некоторая ущербность (в первую очередь отсутствие рекурсивных триггеров), но в общем все вполне хорошо.
Но домашнюю бухгалтерию я все равно веду на SA11-de :)

Малость увлеклись, зато новичкам будет о чем подумать :-)

P.S. Рад за вас, что в эскулайте все хорошо - я-то сам на него частенько баг-репорты шлю ;-) Зато ошибки обычно исправляются в течении нескольких часов, такой поддержки [бесплатной] в других проектах я не встречал.