БД на Lazarus

[Lemboy]

Что касается литературы, то есть отличная книга Шумакова и Фаронова "Программирование баз данных на Delphi"
(или "Руководство разработчика баз данных") с очень хорошей вводной теоретической частью.
Ну и конечно упомянутая уже классическая "Понимание SQL" Грубера.

[Makz87]

Спасибо за советы, для себя остановился на sqlite, эксперементируем.

Запросы 1-к-1 1с 8, во всяком случае на мой взгляд.

А вообще этот sql приглянулся потому, что

а)На мой взгляд проще выучить

б)Не требует установки сервера, встраиваемый.

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

Спасибо за внимание!

[GAMER]

всех переводят на линукс

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

Есть альтернативная MariaDB - MySQL-клон.

По ходу вопрос. Можно ли работать с sql-запросами и dbf-файлами? dbf-файлы открыты другой программой.

[Vadim]

GAMER
В смысле, делать SQL-запросы к dbf-файлам?

[Ism]

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

А есть еще компоненты zeos.

[WAYFARER]

postgresql или mysql

Сии СУБД нельзя сравнивать, у них в корне различный принцип работы, да и назначение. PostgreSQl можно сравнить пожалуй с Oracle, хотя и работают они по разному.
В вашем случае настоятельно рекомендую использовать PostgreSQL, но только после того как вникните в её архитектуру и принципы работы.
У меня вообще подход к разработке заключается в том, что я все что возможно делаю на уровне БД, собственно приложение используется только для представления данных пользователю в удобном виде. В этом плане я вижу только две СУБД, которые позволят мне писать быстрые, и главное легко масштабируемые приложения - это PostgreSQL и Oracle. Решающим фактором выбора является только лицензия. PostgreSQL распространяется под самой свободной из всех свободных лицензий - BSD, что позволяет без проблем использовать его в закрытых коммерческих приложениях. Язык PL/PgSQL дает возможность реализовать практически все что угодно, а если его возможностей не хватает можно использовать для написания процедур другие расширения, такие как PL/Perl, PL/Tcl, PL/Java, PL/Php, C и т.д. Мощнейшие на мой взгляд механизмы транзакций, репликации и т.д. Богатый инструментарий позволяет легко эмигрировать с другой СУБД, например SQL server или Oracle. Много можно еще наговорить:))))...

[Nik]

PostgreSQL распространяется под самой свободной из всех свободных лицензий - BSD, что позволяет без проблем использовать его в закрытых коммерческих приложениях.

Самый свободный - это SQLite, как ни крути. Другое дело, что далеко не везде его можно применить (для небольших настольных/web приложений - самое оно).

[Ism]

dbf отличный формат обмена информацией, но держать на нем базу данных неправильно, это каменный век.

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

Тогда уж firebird , он работает и как embedded и как клиент сервер без изменений. Ве данные хранятся в одном файле, как sqlite. Единственное ходят слухи , что firebird плохо работает с базами больших объемов.

[Vadim]

Единственное ходят слухи , что firebird плохо работает с базами больших объемов.

Это только слухи.
В том же интернете можно найти сведения, что люди спокойно работают с базами Interbase объёмом по 15..20 гигов и стенаний по этому поводу от них не слышно.

[alexs]

Единственное ходят слухи , что firebird плохо работает с базами больших объемов.

В том же интернете можно найти сведения, что люди спокойно работают с базами Interbase объёмом по 15..20 гигов и стенаний по этому поводу от них не слышно.

Ну слухи не безпочвенны. Но только для определённых граничных ситуаций.
Я столкнулся с замедлением работы в случае больших размеров blob полей - создал локальное хранилище книг (копия либрусека) - база получилась размером более 100 гиг. Вот тут начались небольшие притормаживания.
Но это экстремальная ситуация. Для обычных учётных БД firebird - лучше не придумаешь.

[WAYFARER]

В том же интернете можно найти сведения, что люди спокойно работают с базами Interbase объёмом по 15..20 гигов и стенаний по этому поводу от них не слышно.

Читал статейку интересную - База размером 1 терабайт на Firebird
Как там показано, FireBird со своей задачей справился. Но как он себя поведет при количестве одновременных соединений скажем 100 или больше, при условии что пользователи будут интенсивно выбирать, обновлять и вставлять данные!? Мне кажется что в этом случае производительность будет ограничена только объемом оперативной памяти, но очень бы уж хотелось увидеть продолжения теста, с большим кол-вом пользователей и с использованием хранимых процедур.

[Vadim]

Но как он себя поведет при количестве одновременных соединений скажем 100 или больше, при условии что пользователи будут интенсивно выбирать, обновлять и вставлять данные!?

Проверьте.

[Ism]

Бухгалтерская база со 100 пользователями размером в 1 терабайт . А в блобах немецкие фильмы

[Vadim]

в блобах немецкие фильмы

Порно? Тогда точно тормозить будет.