СУБД для программиста. Базы данных изнутри

Отформатировано странно, для кого написано непонятно, темы подобраны в лучших традициях классификатора Борхеса. При этом по тексту разбросаны довольно едкие (и небезынтересные) реплики автора обо всём подряд.

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

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

Автор использует СУБД Firebird для небольших проектов, где требуется локальная база данных, работающая непосредственно на том же компьютере, где работает приложение. Перимущество этой СУБД в том, что при необходимости перехода от локальной базы данных к сетевой, используемой с нескольких компьютеров по сети, можно использовать вариант соответствующей Firebrid, который по большинству функций совместим с локальной версий Firebird. Если же с самого начала предполагается, что к базе данных будут обращаться множество сетевых клиентов, то в таких случаях автор сразу использует Microsoft SQL Server. В конце книги автор приводит сравнение NoSQL СУБД MongoDB с Microsoft SQL Server как по производительности, так и по наглядности запросов. По обеим сравниваемым параметрам результаты оказываются не в пользу MongoDB.

Если у кого-то имеются старые программы, написанные на платформе Clipper, то можно воспользоваться современным вариантом этой платформы. Платформа Harbour полностью совместима с Clipper, её исходные тексты открыты (выпускаются под собственной лицензией), работает на большом количестве различных операционных систем, как настольных, так и мобильных. Неплохой вариант для того, чтобы перенести старые программы для MS-DOS на более современные операционные системы, избавившись от необходимости использовать эмуляторы.

Особенно интересными мне показались сведения о сетевой модели данных, которая нашла практическое воплощение в виде американской СУБД Raima (бывшее название - dbVista) и в виде отечественной СУБД КроносПро.

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

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

По поводу разработки через тестирование автор приводит эмпирические наблюдения: на одну строку тестируемого кода приходится 1-2 строки тестирующего кода, из-за чего длительность разработки по этой методике может увеличиваться в 2-3 раза. В книге автор делится своими наработками по модульному тестированию SQL-запросов. Хотя об этом не часто можно прочитать на просторах интернета, но оказывается, SQL-запросы тоже можно тестировать.