СУБД

Материал из Lurkmore

Перейти к: навигация, поиск
Eri x Yakumo.jpgВ эту статью нужно добавить как можно больше данных.
Также сюда можно добавить интересные факты, картинки и прочие кошерные вещи.

Содержание

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

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

Словарь

Реляционная СУБД — хранит данные в таблицах. Каждая таблица в мозгу проектировщика БД олицетворяет некую сущность. Структура реляционной БД кагбэ моделирует предметную область. В идеале вся необходимая информация должна содержаться в базах СУБД (включая информацию о структуре этих баз). Почему именно таблицы — а на них хорошо ложится матан из теории множеств. В результате более 90% используемых СУБД — реляционные.

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

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

Запрос — обращение извне к СУБД. Годная СУБД не должна пропускать к данным никакого обращения, не являющегося запросом. Любые физические манипуляции с данными выполняет только сама СУБД. Для облегчения работы с запросами придуман стандарт Structured Query Language (SQL). Если ты работаешь с базами данных, не поленись, выучи его, школьник, и твои волосы станут мягкими и шелковистыми. А запросы — правильными и быстрыми.

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

DML — язык манипуляции данными. Для SQL его основа — 4 оператора: SELECT, INSERT, UPDATE, DELETE.

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

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

Транзакция — запросы, которые должны выполниться все или вернуть всё, как было. Эпичный механизм защиты от былинных фейлов, игнорируемый говноразработчиками чуть реже, чем всегда.

Курсор — а вот эту хуиту говнокодеры обожают. Особо эпические ухитряются создать курсор из результата запроса в миллион записей и в цикле построчно обрабатывать ее. Если кто не понял, курсор — набор записей, по которому возможна навигация. НЕ НУЖЕН. Но всегда найдется заказчик-самодур, которому такое захочется.

Хранимые процедуры — как уже сказано, в идеале база данных должна хранить в себе все необходимое. И процедуры обработки данных в том числе.

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

Инди-субд

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

java_objects
id (int) object (blob)
1 (binary)
2 (binary)

Данная операция моментально превращает сложную систему в подобие громадного текстового файла, уничтожая любые преимущества СУБД по скорости и все возможности по работе с данными. При этом данная модель данных настолько распространена, что практически является локальным мемом на Ежедневном ЧтоЗаНахе[1].

В случае, если индусский говнокодер не знаком с Java, но знаком с иерархиями — структура таблички несколько изменится[2].

universe
id (int) parent_id (int) value (varchar(1024))
1 0 документ1
2 1 строка документа1
3 1 строка документа2
4 0 документ2

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

К. О. сообщает

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

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

SQL

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

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

@some_data = SomeData.find 20

чем 

SELECT id
FROM Some_db.Some_data
WHERE id=20;

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

В интернетах

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

В вебе стандартом де-факто является 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 представляет собой довольно сложную и мозголомную штуку. Когда модель данных уходит в развитии дальше примеров из учебников, можно неожиданно обнаружить, что большая часть рабочего времени проходит не в написании кода, а в попытках выкрутить этой блядской хреновине руки и заставить ее делать то, что требуется, и не делать чего не просят.

SQL-инъекция

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

А также

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

Примечания

  1. ↑ «Хороший» пример данного подхода приведен в книге Мартина Фаулера «Архитектура корпоративных программных приложений» ISBN 5-8459-0579-6.
  2. ↑ Справедливо для реляционных СУБД. Объектные, объектно-реляционные СУБД хранят объекты в полях объектного типа, например Oracle.

Суть СУБД

У меня зазвонил телефон:
– Кто говорит?
– Слон.
– Какой "слон"?
– Как "какой"? Голубой.
– Стой! Что значит "слон голубой"?
– Ммм... Как же вам объяснить... Вам не наскучило жить?
– Нет.
– А мне в обед сорок лет.
– Кому?
– Слону.
– Какому? А... голубому?
– Именно так.
– Вот чудак.
– Кто?
– Вы.
– Я думал, слон.
– Слон здесь совсем ни при чем.
– По-вашему, он таки есть?
– Откуда мне знать.
– Зачем тогда утверждать?
– Что утверждать?
– Что нету слонов других.
– Голубых? Разве я утверждал? Я только сказал "алло".
– Значит, вам повезло.
– В чем?
– В том, что у вас телефон. И позвонил слон. Раньше он был петухом.
– Голубым?
– Вовсе нет.
– А каким?
– Мне неизвестен цвет.
– Так слон — это он или вы?
– В сущности, мы равны. Дело лишь в том, что сущности не ясны.
– Петух тогда кто?
– Это тот, кем был слон.
– Пока не стал голубым?
– Он всегда был таким.
– Так вам неизвестен цвет.
– Цвет петуха.
– Который, по сути, и стал слоном?
– Снова нет. Слон — был петухом. Но петух со слоном не знаком.
– Вы же равны.
– Я — со слоном. Но не он с петухом.
– Так... Значит, слон — был петухом? И всегда голубым? А петух, поскольку неясен цвет, — его уже нет. Он исчез в сорок лет. И вместо него — вы. Стали слоном без проблем. Голубым. То есть, вы раньше были другим?
– Зачем? Я всегда был слоном. А слон — тот ходил петухом. И был всегда голубым. В итоге он жил один. Петух же не стал слоном. И не исчез. Он рядом и он как бы есть. Только не весь. Остался один лишь цвет. Которого тоже нет. Петух его не имел. Но цвет — он того не хотел. Поскольку он был умен. Как слон. Слон с петухом не знаком: петуха как бы нет. А цвет, голубой, — он живой. И тоже умеет мечтать, кем стать. Цвет в сорок лет стал слоном. Слон — даже пел петухом. Петух, первый из двух, — оставил лишь след. Вторым же был цвет. Цвет — это след, которого именно нет без слона. Суть вам ясна?? Я, как и сказано, слон. Хоть и не полностью он. Особенность есть одна: в отличие от слона я слегка знаю того петуха.
– ...Всё, теперь понял вас. ...Скажите, который час?
– Пять утра.
– Мне на работу пора. База упала вчера. Рань, но IT-отдел не успел в срок завершить проект. Кстати, и мне сорок лет, а я вот встаю с петухами.
– Вы не один. Я с вами.
– Польщен. Мне повезло говорить со слоном. И слон, безусловно, умен. Всё же, зачем этот слон голубой мой потревожил покой? Только, прошу, без абстракций пространных.
– Я архитектор баз данных.

Пейсатель руками Геннадий Попов (DoMaggiore)

Источник — «http://lurkmore.to/%D0%A1%D0%A3%D0%91%D0%94»