Личные инструменты
Счётчики

СУБД

Материал из Lurkmore

Перейти к: навигация, поиск
Not found 2.svgНарод требует хлеба и зрелищ!
Народ требует иллюстраций к статье!
В конце концов, если бы мы хотели почитать, мы бы пошли в библиотеку.

Содержание

СУБД — система управления базами данных. СУБД позволяет сосредоточиться на работе с данными, абстрагировавшись от их физического размещения, а также берет на себя заботу эффективного их сохранения и выборки. Хлеб насущный админов баз данных, предмет бешеного обожания аналитегов, от которых начальство требует нового отчёта вотпрямщаз, и бешеной ненависти быдлокодеров, которым эта НЁХ ломает такую стройненькую и уютненькую процедурку.

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

[править] Суть

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

Короче, СУБД освобождает разработчика от задач хранения, модификации и поиска данных. Его дело — указать, какие данные взять, и что с ними сделать. Все остальное сделает сама СУБД.

[править] SQL

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

Теоретически, SQL должен обеспечивать и независимость от платформы, возвращая один и тот же результат для любой СУБД, реализующей её. На практике каждый производитель СУБД добавляет в SQL свои, присущие только этой СУБД фишечки, чем усложняет работу программиста и разработчика СУБД, но это, конечно же, не мешает пэхапэ-быдлокодерам использовать ORM'ы, которые представляют из себя некую прослойку между грязным SQL и абстракциями высокого уровня, которая генерирует SQL вместо программиста и позволяет забить на особенности СУБД. Но пэхапэшники используют её, потому что не знают SQL, да и короче написать

$some_data = SomeData::find(20);

чем

$sql = "SELECT id
FROM Some_db.Some_data
WHERE id=20";
$result = $db->query($sql);

При этом с возрастанием сложности запроса количество SQL кода доходит до нескольких сотен строк, в то время как в ORM максимум 2-3. Но, конечно, вполне нормальное явление, что на чистом SQL запрос будет выполняться 15 секунд, а на ORM 30 минут. При этом сам по себе SQL имеет громоздкий синтаксис, но писать простые запросы можно, просто немного зная английский язык.

[править] Разновидности

Существует туева хуча разных СУБД, которые могут отличаться настолько, что не будут понимать SQL друг друга. Или вообще, не являться реляционными и, соответственно, не поддерживать SQL вовсе. Ниже приведены наиболее известные реляционные СУБД.

Удостоился ажно отдельной статьи здесь. Огромная сложная махина, для работы с которой требуются админы 80 уровня с сертификатами, подготовка коих стоит с десяток килобаксов. Умеет делать все, вплоть до того, что может выступать движком для веб приложений (APEX называется). Работает на Unix, винде и еще черт знает чем. Стоит ебических деньжищ, так что, ее могут себе позволить только большие конторы, что у нас, что на Западе. ИЧСХ, если ты не собираешься на ней крутить производственную базу, а просто разрабатываешь приложения, изучаешь или играешься, то скачать и пользоваться ей можно абсолютно бесплатно, даже самой ентерпрайзной версией, что есть таки вин.

  • MS SQL Server

Microsoft в свое время, в лучших своих традициях, подсуетилась и скопипиздила СУБД у Sybase. С тех пор, как они заявляют, ее полностью переписали. Как и всегда, MS клала и кладет прибор на стандарты и идет своим уникальным путем. Хотя, многим нравится. СУБД получилась уровнем пониже Oracle, хотя, по этому поводу идут свои холивары. Для управления БД используется почти исключительно UI, что несколько роднит эту систему с Delphi: вместо знания DDL тут нужно знать куда тыкнуть мышкой. Ну, есть еще PowerShell, но он никому не всрался. Работает, естественно, только под виндой, хотя мелкомягкие уже объявили, что будут портировать ее на Linux.

  • PostgreSQL

Этот ваш open source во всей своей силе. Была разработана в университете Беркли, откуда еще много чего повыходило. Доволько таки винрарна, несмотря на свой маленький размер. Ее уважают админы Oracle за то, что авторы не выебывались, а нормально следовали стандартам.

  • MySQL (MariaDB)

Тоже open source, но более дикий и лохматый. Самая популярная база для создания веб-сайтов, входит в состав так называемого LAMP (Linux, Apache, MySQL, PHP). Поддерживает несколько движков СУБД, из которых не все поддерживают транзакции ACID (движок MyISAM как раз такой). Его когда-то прикупила себе Sun Microsystems, а теперь, когда сама Sun принадлежит Oracle, MySQL тоже оказался в его загребущих лапах. Сие перепугало сообщество разработчиков, и они быстро форкнули MySQL, запилив MariaDB.

  • SQLite

Это не столько СУБД, сколько библиотека, которая позволяет хранить данные в файле, обращаясь в нему как к базе данных с помощью SQL. Там тоже можно создавать таблицы и индексы, выполнять DML и запросы. Удобно в случае, если не хочется возиться с XML или создавать свой формат файла.

[править] Админ СУБД (DBA)

Администратор СУБД — это такая темная личность, которая для разработчиков отрабатывает ту же роль, что и админ локальной сети для обычных юзеров. А именно — постоянно вставляет палки в колеса (по их мнению).

  • DBA vs разработчики.

Эти две стороны чуть ли не постоянно испытывают ненависть друг к другу и всячески пытаются избежать взаимодействия. Претензии разрабов в том, что DBA не дает им делать то, что они хотят, что, как правило, сводится к сваливанию данных в несвязанные таблицы и написанию кривых запросов. Также, админ может не дать пользователям какие-либо права в базе данных и требовать обоснования для их раздачи. В итоге, разрабы, вместо того, чтобы лишний раз подумать или спросить у знающих людей, начинают городить костыли, чтобы обойти запреты. Отсюда растут ноги у печально знаменитой схемы из 4 таблиц, в которой можно хранить любые данные любой структуры.

Со стороны админа же, пользователи выглядят как варвары, которые забивают гвозди микроскопом. SQL они принципиально знать не хотят, обосновывая это тем, что знать его — это задача админа. Если в команде есть архитектор баз данных или отдельная группа людей, отвечающая за взаимодействие с БД, то это сглаживает проблему, но в реалиях этой страны (да и не только этой) проще нанять лишних 2-3 быдлокодера, чем одного архитектора с сертификатами и опытом. Повальное непонимание работы базы данных, игнорирование переменных привязки, неадекватное использование транзакций, попытки отгородиться от базы с помощью ORM, вызывают хронический facepalm у DBA.

  • DBA vs руководство.

Основная задача руководства, как известно, заработать деньги, и чем быстрее тем лучше. И это входит в прямой конфликт с задачей админа наладить стабильную быструю работу базы данных. Из-за этого админ почти никогда не привлекается к процессу разработки базы и его советов никто не спрашивает. Эта задача сбрасывается на команду разработчиков, которая см. выше. То, что они разрабатывают, естественно, глючит и тормозит, но, ЧСХ, претензии по этому поводу валятся на DBA, вызывая у него приступы лютой ненависти.

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

[править] В интернетах

В интернетах СУБД являются темой срача и фаллометрии, как, впрочем, и все остальное в этой вселенной. Уровень ФГМ на тематических форумах зашкаливает при упоминании вражьей базы данных. Конечно, разные СУБД используются для разных целей, но это не мешает выяснять на никому ненужных синтетических тестах, что Oracle аж на 0.00000001 сек быстрее SQL Server, но стоит туеву хучу денег, что выливается в суммы, сопоставимые с годовым бюджетом небольших государств. Но справедливости ради стоит отметить, что при этом сама СУБД кроссплатформенна в отличие майкрософтовского поделия.

В вебе стандартом де-факто является Mysql, ибо бесплатный и легко установить, но при возрастании нагрузок жутко тормозит. Мускулистов легко затроллить, предложив им нормально расшардить свою БД. Также среди мускулистов популярен срач Myisam vs InnoDB, которые по сути низкоуровневые движки, которые непосредственно отвечают за доступ к данным. Когда мускула не хватает по производительности, а кредит на Oracle никто не даст, то в дело вступает PostgreSQL, которая также открытая и не тормозит.

Еще один достаточно новый срач — это реляционные СУБД vs Документо-ориентированные. Суть срача в том, что реляционки больше известны, под них больше разработчиков и для них уже все есть, но они жутко тормозят при хранении большого количества однородных данных — тех же хэш-таблиц или деревьев с большим уровнем вложенности и слабой поддержкой индексов, в то время как документо-ориентированные обещают изменить мир, но все никак не могут из-за высокого порога вхождения, малого количества документации, плохой поддержки среди хостеров и необходимости строить тонны костылей при попытках хранить что-то отличное от хэш-таблиц. И еще тонны плюшечек, которые есть в реляционках.

[править] Новые разработки

Многие современные СУБД произошли (прямо или косвенно) от Ingres, написанной в Университете Беркли в 70-х (ОМГ! BSD оттуда же!). После того, как основные алгоритмы поиска и хранения данных вместе с языком SQL стабилизировались, разработчики современных систем заняты в основном:

  • Добавлением поддержки малопопулярных возможностей SQL;
  • Добавлением тучи малопопулярных функций и типов;
  • Написанием новой СУБД с нуля (теперь и на PHP);
  • Написанием трансляторов из базы данных в объекты (облегчая тем самым работу быдлокодерам);
  • Перепиливанием системы частично или полностью для поддержки XML.

Последний пункт является причиной отдельной темы срача, где участники делятся на лагерь, поклоняющийся Oracle, MS SQL Server и DB2 за умение работать с XML без бубна, и лагерь, старающийся убедить противника в том, что XML = УГ.

С легкой руки одной корпорации, которая применяет данный принцип в своей системе, в последнее время часто встречается рекомендация при программировании всех операций по сохранению данных в файлах заменять их записью в «легкие» базы данных типа SQLite. Это позволяет абстрагироваться от конкретной реализации операций чтения/записи файлов в разных системах и переложить всю черновую работу на движок базы данных, который все-таки пилят не самые последние быдлокодеры. Внезапно, ничего нового в этом нет. w:PalmOS юзала этот принцип за год до основания Google.

[править] Object-Relational Mapping (ORM)

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

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

На практике же все получается не так радужно, как рисуется в учебниках. И дело даже не в том, что библиотеки кривые (хотя, и это тоже есть), а в том, что объектная модель очень плохо совмещается с реляционной, и авторам библиотек приходится постоянно идти на компромиссы: либо ставить костыли, либо выкидывать функциональность. Получается гибрид ежа с ужом.

Плюсы ORM:

Собственно, их мало, но за них быдлокодеры готовы биться насмерть, по понятным причинам:

  • Позволяет разработчикам наглухо отгородиться от базы данных. Ведь это такое счастье: не надо больше изучать SQL (правда, надо изучать HQL, JPQL или какой-то еще недо-SQL).
  • Не надо писать руками DML.
  • Не надо заморачиваться с курсорами.
  • Не надо разбираться в планах выполнения запросов.
  • Блджад, вообще ничего не надо знать про СУБД!

Минусы ORM:

  • Как следствие первого плюса, закономерно приводит к написанию мегатонн кода, который, через ORM, адски насилует базу данных во все порты. А фигли, с точки зрения кода там все правильно, а вот ORM этот правильный код транслирует в сотни, тысячи неоптимизированных запросов, причем, бывает, что и откровенно левых. Помножьте эти тысячи на количество сеансов и оцените эмоции админа, у которого создается ощущение, что прога хочет вытащить к себе всю базу данных, строчка за строчкой, по одиночным ID.
  • ORM не знает какие именно поля были изменены у объекта, поэтому в базе данных обновляет их все, даже если изменилось только одно. Доставляет, если в записи присутствуют какие-нибудь большие штуки типа BLOB.
  • Если нужно получить несколько объектов, ORM будет ждать, пока они все не будут получены из базы (вместе со своими зависимостями, естественно), прежде чем вернуть хоть что-то.
  • Некоторые вещи ORM нельзя заставить сделать в принципе, ибо они требуют реляционной модели. Например, рекурсивные и иерархические запросы. Одно время в Hibernate был глюк (может, и сейчас есть): его было невозможно заставить НЕ извлекать зависимость OneToOne.
  • Вообще, в целом, ORM представляет собой довольно сложную и мозголомную штуку. Когда модель данных уходит в развитии дальше примеров из учебников, можно неожиданно обнаружить, что большая часть рабочего времени проходит не в написании кода, а в попытках выкрутить этой блядской хреновине руки и заставить ее делать то, что требуется, и не делать чего не просят.

[править] А также

Субдуральная гематома — понятие медицинское, выглядит как обширное кровоизлияние в мозг. С сабжем связано чуть менее, чем никак, зато по производимому эффекту сходно с процессом изучения структуры и работы с этими вашими СУБД.

[править] См. также