что такое база данных и субд
Зачем нужны базы данных
И какие они бывают.
Если вы будете делать веб-приложение — например интернет-магазин, блог или игры, — почти наверняка вы столкнётесь с базой данных. Вот что это такое с точки зрения программирования, какие тут основные понятия и что с ними делать.
Данные
Вокруг нас всегда много разных данных, например:
Если это компьютерная игра, то данными будут типы и местоположения врагов, их уровень здоровья, уровень здоровья героя, тип героя, его положение, характеристики карты.
Если это приложение для работы с клиентом, то там будут храниться имя клиента, его заказы, номер телефона, уровень в программе лояльности.
Если это служба слежения за гражданами — фотография, имя, посещённые станции метро и улицы, место работы.
База данных и СУБД
Есть понятие базы данных — это набор данных, организованных каким-то способом. Например, если у вас в квартире есть гардеробная или кладовка, то всё это помещение со всем её содержимым может считаться базой (но не данных, а вещей или банок с огурцами, что не меняет сути).
Есть понятие системы управления базой данных (СУБД) — это когда семья села за стол и самого младшего отправляют в кладовку за огурцами, он приносит её и не разбивает по дороге. То есть СУБД — это какое-то средство для манипуляции данными в базе, например программа.
Для чего нужны
Вот основные задачи БД на примере гардеробной:
В чём преимущества
Базы данных и их системы управления заточены на работу с большим объёмом данных и от лица большого числа пользователей. Сейчас вы поймёте.
🤔 Представьте, что у вас есть экселька со списком клиентов. Это не база данных, это просто таблица. Чтобы прочитать или записать что-то в эту эксельку, вам нужно её открыть, сделать дело, сохранить.
❌ Допустим, экселька с клиентами лежит на сетевом диске. Вы открыли её и ковыряетесь в данных, вносите изменения. Пока вы это делаете, ваш коллега тоже её открыл и тоже вносит изменения. Потом вы сохранились и закрыли эксельку. Экселька перезаписалась вашими данными. Но у вашего коллеги эти данные не отобразились, он-то открыл её раньше. Теперь, когда он сохранит свою эксельку, его данные перезапишутся поверх ваших, а ваши данные пропадут. Это полный ахтунг: вся ваша работа потеряна.
❌ Или у вас в компании правило: экселька всегда на одной флешке, работаем только с неё. Сейчас флешка в вашем компьютере, вы с ней работаете. А вашему коллеге нужно с ней тоже поработать. Он говорит: «Дай». Вы ему «Отстань». Ну и слово за слово…
✅ Но можно организовать своего рода СУБД. Один ответственный сотрудник назначается главным по эксельке. Она открыта на его компьютере, а вы ему говорите: «Петруха, добавь в клиента такого-то вот такие данные». «Петруха, а шо, когда дедлайн по поставке для этих ребят из Воронежа?», «Петруха, питерские отказались, поставь там отказ».
Петруха — ваша система управления базой данных. А экселька — это его база данных.
Понятно, что Петруха медленный и не всегда многозадачный, но хотя бы он избавляет от проблемы рассинхрона версий и потери данных.
Скорость — ещё одно преимущество базы данных. База данных устроена так, что она легко и быстро находит, записывает, переписывает и снова находит данные. Всё потому, что СУБД всегда знает, что где лежит и по какому критерию искать. Там не будет случайных данных в случайном месте.
Скорость важна ещё и потому, что СУБД обычно обслуживает сразу много потоков: одновременно ей могут пользоваться десятки и сотни тысяч человек, поэтому ей некогда копаться. В хорошо сделанных БД всё молниеносно.
Сложность. Базы данных нужны в числе прочего для хранения сложно структурированных данных. Мы привыкли думать, что база данных — это такая таблица, где есть строки и столбцы. Но база данных при правильной организации может намного больше:
Базу можно представить как таблицу, но лишь в самом упрощённом виде. Для более сложных задач базу можно представить как очень сложное дерево, или огромный склад упорядоченных коробок, или даже как огромный завод по фасовке данных.
База данных — это отдельный файл?
Чаще всего да, все данные СУБД хранит внутри одного большого файла. Но если данных много или сама база так устроена, то она может разбиваться на несколько файлов поменьше.
Но для пользователей нет разницы, как физически хранится база, это забота СУБД. Главное — уметь общаться с базой через СУБД.
Где их используют
Базы данных сейчас используются почти везде:
Если у вас в работе появляется много одинаковых или похожих данных, то самый надёжный способ не потерять ничего из них — поместить их в базу данных.
Как это работает
Возьмём простой пример реляционной базы данных (можно упрощённо сказать, что это база данных в виде таблицы).
Каждая запись в реляционной базе данных раскладывается в одну или несколько ячеек. Например, запись в телефонной книге может выглядеть так:
В нашем примере у базы есть поля — Имя, Фамилия, Телефон и Фото, в которых могут храниться данные. Одна строчка — одна запись с данными.
Если пользователю нужно будет найти телефон Михаила Максимова по фамилии, происходит следующее:
Запрос от пользователя: Выдай мне из базы «Контакты» все записи, где поле «Фамилия» равно «Максимов»
Ответ от базы данных: ЛОЛ КЕК Ты кто такой
Запрос пользователя: Я хозяин этой базы Админ Админыч, пароль •••••. Выдай мне из базы «Контакты» все записи, где поле «Фамилия» равно «Максимов»
Ответ от базы данных: Найдена одна запись: [Михаил, Максимов, +79057362163, вот фото]
Разные базы — разные правила
Внутри каждой базы данных и её управляющей системы свои строгие правила:
Рабочая ситуация: допустим, вы работаете в банке и открыли карточку клиента, чтобы поменять ему кредитный лимит. В этот же момент другой сотрудник из соседнего офиса тоже хочет поменять лимит этому же клиенту, но уже на другую сумму. Как база отреагирует на такое? Должна ли она разрешать второму сотруднику открывать карточку или её нужно заблокировать, пока первый не закончит? А если она разрешит открыть карточку, то что будет, если двое сотрудников напишут там разный лимит — какой из них сохранять в итоге? СУБД задаёт эти правила и следит за их выполнением.
Что дальше
В следующей статье поговорим про MySQL — бурерождённую мать всех баз. Если разобраться, как она работает, то можно творить чудеса.
Базы данных и СУБД
Для правильной работы сайта нужны не только файлы с кодом страниц, но и базы данных. Для взаимодействия с БД используются системы управления базами данных (СУБД). В этой статье я расскажу о базах данных и СУБД, их разновидностях и основных отличиях.
Как работают базы данных
В базе данных может содержаться различная информация: личные данные пользователей, записи, даты, заказы, список клиентов и так далее. К примеру, если у вас интернет-магазин, то база данных вашего сайта может содержать прайс-листы, каталог товаров или услуг, отчеты, статистику и информацию о покупателях.
Любую информацию можно быстро заносить в базу данных и так же быстро извлекать ее при необходимости.
Важную роль играет взаимосвязь информации в базе данных: изменение одной строчки может привести к значительным изменениям других строк. Работать с данными таким образом гораздо проще и быстрее, чем если бы изменения касались только одного места.
Однако это не значит, что база данных обязательно должна быть у каждого сайта – к примеру, если у вас сайт-визитка, и никакой новой информации вы на сайте не размещаете, то база данных вам будет попросту не нужна.
Система управления базами данных (СУБД)
Система управления базами данных (сокращенно СУБД) – это программное обеспечение для создания и работы с базами данных.
Главная функция СУБД – это управление данными (которые могут быть как во внешней, так и в оперативной памяти). СУБД обязательно поддерживает языки баз данных, а также отвечает за копирование и восстановление информации после каких-либо сбоев.
Реляционные СУБД и язык SQL
Реляционные и объектно-реляционные СУБД являются одними из самых распространенных систем. Они представляют собой таблицы, в которых каждый столбец (он называется «field» или «поле») упорядочен и имеет определенное уникальное название. Последовательность строк (их называют «records» или «записи») определяется последовательностью ввода информации в таблицу. При этом обрабатывание столбцов и строк может происходить в любом порядке. Таблицы с данными связаны между собой специальными отношениями, благодаря чему с данными из разных таблиц можно работать – к примеру, объединять их при помощи одного запроса.
Для управления реляционными базами данных применяется особый язык программирования – SQL. Сокращение расшифровывается как «Structured query language», в переводе на русский – «язык структурированных запросов».
Команды, которые используются в SQL, делятся на:
Схема работы с базой данных выглядит следующим образом:
5 лучших СУБД
Далее я кратко расскажу о лучших СУБД, которые чаще всего используются при создании веб-проектов.
MySQL
MySQL является одной из самых популярных и распространенных СУБД, которая используется во многих компаниях (например, Facebook, Wikipedia, Twitter, LinkedIn, Alibaba и других). MySQL представляет собой реляционную СУБД, которая относится к свободному программному обеспечению: она распространяется на условиях GNU Public License. Как правило, эту систему управления базами данных определяют как хорошую, быструю и гибкую, рекомендованную к применению в небольших или средних проектах.
У MySQL есть множество различных преимуществ. Например, она поддерживает различные типы таблиц – как известные MyISAM и InnoDB, так и более экзотичные HEAP и MERGE. Кроме того, количество поддерживаемых типов постоянно растет. MySQL выполняет все команды быстро – возможно, сейчас это самая быстрая СУБД из всех существующих. С этой системой управления базами данных может одновременно работать неограниченное количество пользователей, а число строк в таблицах может достигать 50 миллионов.
Так как в сравнении с некоторыми другими системами MySQL поддерживает меньшее количество возможностей, то и работать с ней значительно проще, чем, к примеру, с PostgreSQL, о которой будет рассказано ниже.
Для работы с MySQL используется не только текстовый, но и графический режим. Это становится реальным благодаря приложению phpMyAdmin: для работы в приложении вам даже не нужно знать SQL-команды, а администрировать свою базу данных можно прямо через браузер.
MySQL – это выбор тех, кому необходима СУБД для проекта небольшого или среднего размера, быстрая и удобная в работе и без сложностей с администрированием.
PostgreSQL
Эта свободно распространяемая система управления базами данных относится к объектно-реляционному типу СУБД. Как и в случае с MySQL, работа с PostgreSQL основывается на языке SQL, однако, в отличие от MySQL, PostgreSQL поддерживает стандарт SQL-2011. Эта СУБД не имеет ограничений ни по максимальному размеру базы данных, ни по максимуму записей или индексов в таблице.
Если говорить о преимуществах PostgreSQL, то в первую очередь это надежность транзакций и репликаций, возможность наследования и легкая расширяемость. PostgreSQL поддерживает различные расширения и варианты языков программирования, такие как PL/Perl, PL/Python и PL/Java. Также есть возможность загружать C-совместимые модули.
Многие отмечают, что в отличие от MySQL данная СУБД имеет хорошую и подробную документацию, которая дает ответы практически на все вопросы.
О том, что это более масштабная, чем MySQL, СУБД, говорит и тот факт, что PostgreSQL периодически сравнивают с такой мощной системой управления данных, как Oracle. Все это позволяет говорить о PostgreSQL как об одной из самых продвинутых СУБД на данный момент.
SQLite
На данный момент это одна из самых компактных СУБД. Также она является встраиваемой и реляционной.
SQLite позволяет хранить все данные в одном файле и, благодаря своему небольшому объему, отличается завидным быстродействием. SQLite значительно отличается от MySQL и PostgreSQL своей структурой: движок и интерфейс этой СУБД находятся в одной библиотеке – и именно это позволяет выполнять все запросы очень быстро. Другие СУБД (MySQL, PostgreSQL, Oracle и т.д.) используют парадигму «клиент-сервер», когда взаимодействие происходит через сетевой протокол.
Из недостатков можно отметить отсутствие системы пользователей и возможности увеличения производительности.
Oracle
Эта СУБД относится к объектно-реляционному типу. Название произошло от названия разработавшей эту систему фирмы Oracle. Наравне с SQL СУБД использует процедурное расширение под названием PL/SQL, а также язык Java.
Oracle – это система, отличающаяся стабильностью уже не один десяток лет, поэтому ее выбирают корпорации, для которых важна надежность восстановления после сбоев, отлаженная процедура бэкапа, возможность масштабирования и другие ценные возможности. К тому же эта СУБД обеспечивает отличную безопасность и эффектную защиту данных.
В отличие от других СУБД, стоимость покупки и использования Oracle достаточно высока, и именно это зачастую является значимым препятствием к ее использованию в небольших фирмах. Вероятно, именно это также является причиной того, что в рейтинге лучших СУБД на 2016 год в России Oracle находится лишь на 6-м месте.
MongoDB
Эта СУБД отличается тем, что она предназначена для хранения иерархических структур данных, и поэтому ее называют документоориентированной (она представляет собой документное хранилище без использования таблиц или схем). MongoDB имеет открытый исходный код.
Используя идентификатор, вы можете производить быстрые операции над объектом. Также эта СУБД хорошо показывает себя и при сложных взаимодействиях. В первую очередь речь идет о быстродействии – в некоторых случаях приложение, написанное на MongoDB, будет работать быстрее, чем такое же приложение, использующее SQL, т.к. MongoDB относится к классу СУБД NoSQL и пользуется объектным языком запросов, который значительно легче SQL.
Однако этот язык имеет и свои ограничения, и потому MongoDB следует использовать в случаях, когда нет необходимости в сложных и нетривиальных выборках.
Заключение
Выбор СУБД – это важный момент при создании своего ресурса. Отталкивайтесь от своих задач и возможностей, пробуйте и экспериментируйте, чтобы найти именно тот вариант, который будет наиболее подходящим.
База данных и СУБД: основные понятия и определения
Основополагающие термины достаточно подробно рассмотрены в любой из серьезных монографий. Тем не менее, чтобы однозначно понимать суть в ходе чтения, нам нужно выработать общий словарь. С этой целью я буду по мере необходимости приводить минимальный набор определений, составляющий основу дальнейшего изложения.
База данных (БД) — структурированное поименованное хранилище информации.
Из самого первого определения должно быть понятно, что содержащий начисленные квартальные премии сотрудников файл формата CSV — текстовый формат, предназначенный для представления табличных данных (CSV от англ. Comma-Separated Values — значения, разделённые запятыми). Каждая строка файла — это одна строка таблицы. Значения отдельных колонок разделяются разделительным символом (запятой).) является хоть и очень простой, но базой данных, а текстовый файл с научным описанием мышей-полёвок ей не является.
Система управления базами данных (СУБД) — специализированное программное обеспечение, обеспечивающее доступ к базе данных как к совокупности её структурных единиц.
Из второго определения также должно быть понятно, что открыв упомянутый CSV-файл в текстовом редакторе, мы хоть и видим базу данных, но не работаем с ней посредством СУБД. Если же мы откроем файл в приложении LibreOffice Calc, то данная программа превращается хоть и в очень простую, но СУБД, позволяющую нам работать со структурированным текстом, как с таблицей на уровне колонок, строк и значений, а также посчитать итоги, средние и крайние величины. Положив файл в разделяемый по локальной сети каталог, получаем примитивную многопользовательскую СУБД на основе все того же приложения.
Исторически, в устройстве СУБД выделяли три уровня, предложенных ещё в 1975 году в отчёте ANSI/X3/SPARC :
Внутренний уровень не всегда связан с файловой системой. Наиболее развитые современные СУБД представляют собой по сути специализированную операционную систему (см. например информацию по SQLOS в составе Microsoft SQL Server), способную управлять физическими устройствами хранения, кешем данных, процессами и потоками, оперативной памятью, асинхронным запуском и внутренним планировщиком задач минуя собственно операционную систему компьютера.
Вернёмся к примеру с CSV-файлом и приложением LibreOffice Calc, наглядно показывающему, что даже в примитивной СУБД все три упомянутых уровня можно чётко выделить:
Тем не менее, LibreOffice Calc является не СУБД, а приложением для работы с электронными таблицами. Сама по себе всякая электронная таблица уже является БД, но далеко не всякая БД является электронной таблицей. Поскольку целью книги не является обзор способов организации простейших БД и примитивных СУБД, то на этом примере мы пока остановимся и перейдём к более насущным вопросам.
Любое приложение, реализующее аналогичные вышеописанным прикладные функции, требующие использования механизма транзакций, относится к типу транзакционных. Отличительные особенности таких приложений следующие.
В реляционной СУБД любой оператор SQL является одиночной транзакцией по умолчанию. Некоторые реализации, например, Firebird, по умолчанию открывают новую транзакцию при выполнении каждого оператора SQL, оставляя её «висеть» до выдачи команды завершения. Это так называемый режим неявных транзакций (implicit transaction). Для управления соответствующим поведением, СУБД обычно имеет опцию включения и отключения неявных транзакций, например, set implicit_transaction on|off в SQL Server.
Основными аббревиатурами, касающимися транзакций, с которыми вам придётся сталкиваться будут OLTP (On-Line Transaction Processing) — собственно интерактивная транзакционная обработка, и ACID (Atomicity- Consistency-Isolation-Durability) — принципы неделимости, целостности, изолированности и надёжности. О них мы поговорим в дальнейшем, рассмотрев на примерах принципы изоляции.
В противоположность транзакционной, аналитическая обработка данных имеет другие отличительные признаки.
Аналогичной аббревиатурой для интерактивной аналитической обработки является OLAP (On-Line Analytical Processing). Соответственно, интерактивное приложение, работающее с СУБД в режиме OLAP, относится к аналитическим.
Важное здесь слово «интерактивная». Действительно, в отличие от транзакционной, аналитическая обработка может вестись и в пакетном режиме: пользователь формулирует задачу в понятных приложению терминах, ставит обработку в очередь и, например, утром следующего дня получает результаты. Таковой, например, является заблаговременная ночная генерация регулярных отчётов, рассылаемых по утрам или с другой заданной периодичностью группам пользователей (см., например, Microsoft SQL Server Reporting Services).
Необходимо понимать, почему возникло разделение на транзакционную и аналитическую обработку, ведь со стороны внешнего уровня архитектуры СУБД они не слишком отличаются. В обоих случаях запросы, да, немного разные, ну и что?
Основная проблема заключается в том, что СУБД, ориентированные на транзакционную обработку, менее эффективны при работе с аналитическими запросами и наоборот. Универсальных архитектур и их реализаций, одинаково легко справляющихся как с большим потоком мелких запросов и транзакций, так и с гораздо меньшим числом массивных тяжёлых выборок по большому диапазону, не существует. Пока, по крайней мере. Ещё сложнее реализовать оба типа обработки одновременно в одной и той же БД. Поэтому возникла и уже долгое время [1] существует упомянутая выше специализация как среди СУБД, так и среди программистов, администраторов и консультантов.
Клиент-серверные и встроенные СУБД
Технология клиент-сервер является основой большинства реализаций современных программных систем. Речь идёт не только о паре «Приложение конечного пользователя — СУБД». Каждое звено многозвенной системы с длинными цепочками прохождения сообщений от пользовательского интерфейса через службы и серверы приложений к СУБД также работает в режиме «клиент-сервер». Отличительные признаки технологии следующие:
Роли клиента и сервера у процессов могут меняться. Например, сервер может время от времени опрашивать своих клиентов о состоянии. В производственной практике серверным приложением или просто сервером обычно называют тот процесс, основная задача которого состоит в обработке поступающих от клиентов запросов. В такой терминологии есть некоторый риск спутать приложение-сервер с компьютером-сервером, исполняющим роль физического устройства для эксплуатации тех самых серверных приложений. Поэтому однозначно понять смысл термина «сервер» можно только в контексте его употребления.
Из сказанного следует, что СУБД, работающая как самостоятельный процесс, также является сервером, СУБД-сервером. Однако, некоторые СУБД позволяют напрямую пристыковать себя к процессу-приложению, например, посредством динамических библиотек. В этом случае СУБД исполняется в том же процессе (in-process), что и приложение и называется встроенной или встраиваемой.
Рис. 1. Взаимодействие приложения с СУБД в системах с разным числом звеньев
Встроенные СУБД по сравнению с клиент-серверными имеют ряд преимуществ и недостатков. К преимуществам встроенных СУБД можно отнести следующие особенности.
Следует отметить, что возможно также использование встроенной СУБД в многопользовательском режиме для работы с разделяемыми по сети файлами данных. Такая технология получила название «файл-сервер» и была весьма популярна до широкого распространения клиент-серверных СУБД. Интересующихся я отсылаю к системам разработки под общим названием xBase. Сюда относятся такие продукты, как dBase, Paradox, FoxPro или Clipper (современная открытая кросс-платформенная реализация Clipper называется Harbour). Тем не менее, как минимум одна популярная встраиваемая СУБД до сих пор нередко используется в таком качестве, это Microsoft Access и его «мотор» MS Jet, являющийся компонентом операционной системы Windows.
Кроме преимуществ, встроенные СУБД обладают рядом ограничений и недостатков, вытекающих непосредственно из технологии.
Конечно, перечисленных критериев недостаточно для полноценного выбора технологии и типа СУБД, но, надеюсь, у читателя появится базис для систематизации поиска согласно требованиям к разрабатываемой программной системе.
Из ряда многочисленных встроенных СУБД, опробованных непосредственно на практике или в тестовом режиме, таких как xBase, Microsoft, Access, Microsoft SQL Server Compact, SQLite, Oracle Lite) наиболее интересным современным решением мне представляется Firebird по следующим причинам.
Конечно, Firebird не лишён недостатков, особенно с точки зрения администратора баз данных, но для автономных приложений эта СУБД предоставляет разработчику заманчивые возможности. В дополнение к теме я приведу выдержки из своего небольшого обзора состояния Firebird, написанного в 2013 году с позиций как администратора БД, которому необходимо обеспечивать промышленную эксплуатацию баз данных под Firebird, так и инженера, постоянно решающего вопросы поддержки работоспособности продукта среди многих клиентов, эксплуатирующих разные версии СУБД.
Сноска. Firebird 2.5: состояние
Firebird достаточно лёгок в администрировании: для относительно небольших
баз данных и приложений СУБД практически не требует вмешательства администратора БД. Для разработчиков автономных приложений это важный фактор, позволяющий минимизировать затраты на поддержку приложений у клиентов, не предоставляющих удалённый доступ к своей сети или у которых не имеется своего администратора БД в штате службы ИТ, если она вообще есть.
Однако, если эксплуатируемых баз данных, приложений и пользователей в хозяйстве становится все больше, то прежняя лёгкость начинает превращаться в легковесность.
Особенности реализации требуют, чтобы операция создания внешнего ключа между двумя таблицами проводилась только при наличии одного единственного соединения к БД. Сами же таблицы создать можно и в обычном соединении, имея соответствующие права. Просуществовало это ограничение до версии 2.1, но у многих клиентов в эксплуатации находится ещё версия 1.5.
Штатных средств соединения в однопользовательском режиме нет. Поддержка предлагает утилитой gfix отключить базу данных в эксплуатации (!), потом включить её в режиме sysdba, что, впрочем, тоже не гарантирует единственного соединения, если более одного сотрудника имеют доступ с уровнем sysdba.
Редакций Firebird по-прежнему несколько, к SuperServer и Classic добавилась SuperClassic. Исторически, Interbase, на основе открытого кода которого возник Firebird, использовал classic-архитектуру: на каждое соединение СУБД стартует отдельный серверный процесс. Такой подход обеспечивает достаточно высокую надёжность (если один процесс аварийно завершается, то на работу остальных это не влияет) и параллелизм средствами операционной системы, но отсутствует разделяемый кэш данных в оперативной памяти. В SuperServer серверный процесс один, каждое соединение работает в своём потоке с разделяемым кэшем. Но SuperServer не умеет распараллеливать запросы: пока один запрос выполняется со 100% загрузкой одного ядра (одного процессора), остальные ждут. Ситуацию призвана исправить появившаяся редакция SuperClassic.
Собственно, кэш данных у Firebird весьма условный, СУБД использует кэш файлов операционной системы, поэтому сбросить его для проверки производительности «холодных» запросов невозможно даже перезапустив СУБД. К примеру, в SQL Server для этого есть специальная команда.
Средства администрирования, прежде всего аудита и мониторинга из комплекта достаточно примитивны. Например, трассировщик запросов, [4] образцом которого вполне может служить MS SQL Server Profiler, являет собой утилиту командной строки, запускаемую со своим конфигурационным файлом. Последующую расшифровку полученных результатов надо проводить вручную при помощи регулярных выражений. Есть коммерческие утилиты, предоставляющие более дружественный интерфейс. В версии 2.5 появились возможности накопления статистики в системных таблицах мониторинга вида MONSXXX.
Средством «полной очистки» БД от так называемого мусора до сих пор является процедура резервного копирования и последующего за ним восстановления при помощи утилиты gbak. Однако, подобная процедура означает отключение пользователей от СУБД на всё время восстановления, делая проблематичной работу в режиме 24×7. Файл базы данных понемногу растёт даже при нулевом балансе добавленных и удалённых записей с постоянной фиксацией транзакций, данные дефрагментируются, что может снизить производительность. Ощущается нехватка аналога команды VACUUM, имеющейся в СУБД PostgreSQL.
Firebird не блокирует используемые файлы. Таким образом файл БД можно скопировать на сервере прямо во время многопользовательской работы. Как оказалось, некоторые клиенты именно так и поступают, называя подобное непотребство «резервным копированием». Проблема заключается в том, что во время копирования нет никакой гарантии нахождения файла в целостном состоянии, как и отсутствия незавершённых транзакций. Наверное, все-таки лучше было бы предусмотреть блокирование, как дополнительную защиту «от дурака».
Наличие перечисленных проблем не позволяет поднять усреднённую планку использования выше чем уровень «СУБД рабочих групп и небольших предприятий», означающий для систем транзакционной обработки десятки пользователей при объёмах БД в десятки гигабайт. Но, вполне возможно, что и такого уровня будет достаточно для ваших приложений.
С другой стороны, с точки зрения программиста, Firebird представляет собой удобный СУБД-сервер: простой в установке, нетребовательный к ресурсам вычислительного устройства, переносимый между различными операционными системами, встраиваемый в приложение. Собственный язык программирования позволяет реализовать логику в хранимых процедурах и триггерах. Имеется большое число средств проектирования, разработки и отладки: от свободно распространяемых с открытым кодом до коммерческих. Стандартные средства сетевого доступа к СУБД имеются практически для всех платформ разработки от массово-корпоративной Явы до более экзотических вроде Руби.