БД и СУБД: кой за какво отговаря

Глава 1 — «Картата на архива»

Снимката на «Kotomarket» вече не е сигнал от мъртъв сектор — тя лежи в карантинния отсек на «Vault-9» и под последния ред от нейния дъмп стои все същият подпис: «K.». Тази сутрин на твоята холопанел проблясва нов запис: «Допуск: опис на архива. Издаден от: модул S.Q.L.» Вратата на хранилището се отдръпва встрани; зад нея, в кехлибарена подсветка, равномерно бръмчат сървърните стелажи.

КВЕРИ: Преди да четеш чужда памет, разбери как е устроена. Да започнем с най-важното: какво тук е хранилището и кой е пазителят.

База данни и СУБД

База данни (БД) е организирано хранилище. В снимката на «Kotomarket» лежат купувачи, стоки, поръчки и събития: не разпилени по файлове, а в ясна структура — затова могат да бъдат прочетени дори сто и шейсет години по-късно.

Но самото хранилище не отговаря на въпроси. Нужна е програма, която умее да създава таблици, да записва нови поръчки, да чете данни и да следи връзките да не се чупят. Това е СУБД (система за управление на бази данни). Примери: PostgreSQL, MySQL, ClickHouse. Нашата снимка е база PostgreSQL и говори на същия SQL, на който е говорила и приживе на магазина.

Ти пишеш заявка на SQL → изпращаш я към СУБД → СУБД изважда нужните данни и връща резултата. Excel е добър за лична таблица, но не и за магазин, в който хиляди потребители едновременно разглеждат стоки, оформят поръчки и оставят събития в системата.

Database and DBMS

A database is an organized store. The Kotomarket snapshot holds buyers, products, orders, and events — not scattered across files, but in a clear structure. That’s exactly why it can still be read a hundred and sixty years later.

But the store itself doesn’t answer questions. You need a program that can create tables, record new orders, read data, and make sure the links never break. That’s a DBMS (database management system). Examples: PostgreSQL, MySQL, ClickHouse. Our snapshot is a PostgreSQL database, and it still speaks the same SQL it did when the shop was alive.

You write a query in SQL → send it to the DBMS → the DBMS fetches the data you asked for and returns the result. Excel is fine for a personal spreadsheet, but not for a shop where thousands of users browse products, place orders, and leave events in the system all at once.

Какво умее СУБД, което «просто файловете» не могат

Изглежда, че магазинът би могъл да живее и без СУБД: да записва поръчките в CSV или Excel. В мащаба на личен бележник така и правят — докато не дойдат задачите, заради които изобщо е измислена СУБД.

• Конкурентен достъп. В живия «Kotomarket» купувачите оформяха поръчки едновременно. Два процеса, които пишат в един файл, затриват промените си взаимно; СУБД изпълнява промените като транзакции и сама разплита паралелните операции. PostgreSQL прави това чрез механизма MVCC: четящите не блокират пишещите и обратно.
• Възстановяване след срив. Захранването премигна по средата на запис — файлът се повреди и не е ясно коя половина от поръчката е успяла да се запише. СУБД първо фиксира промяната в журнал (в PostgreSQL — WAL, write-ahead log) и след срива я доиграва: поръчката е или записана изцяло, или изобщо не е записана.
• Права за достъп. Файлът е отворен или целият, или никак. В СУБД правата са гранулярни — чак до отделна таблица:

-- Аналитику — только чтение заказов, без права их менять
GRANT SELECT ON orders TO analyst;

• Цялост. СУБД няма да приеме поръчка с цена-низ или с препратка към несъществуващ купувач: типовете на колоните и ограниченията се проверяват при всеки запис. На файла му е все едно какво лежи в него.
• Декларативни въпроси. «Покажи поръчките над 5000» — един ред SQL. С файл същата работа я върши програма, която някой трябва да напише и да не сгреши.