Читаю книжку "sql для самых-самых тупых". И всё равно ничего не понимаю. Оъясните мне глубинную концепцию СУБД на пальцах. Не могу я её осознать. Заботать теорию надёжности за вечер - могу, апач поднять - могу, даже торт испечь могу, хоть и паршивый. А вот в чём скрытый смысл баз данных, понять не могу.
1)Возможность доступа к этим таблицам (т.е. поддержка языка БД, тот же SQL например). 2)Хранение таблиц в рациональной форме на диске и в оперативной памяти, кэширование. 3) Логи операций, резервное копирование, возможность восстановления данных 4) Ну и всякие дополнительные фишки, вроде транзакционных механизмов, локировок, ролей пользователей и т.п.
Да я бы не сказал. Я конечно не бог весть какой специалист по СУБД, у нас на проекте отдельный человек есть для тонких нюансов.
Но во-первых сами данные вполне могут храниться в бинарном виде (более того, в основном так и хранятся, это рациональнее). Т.е. не таблицы, а просто сплошной набор байтов, которые я умею преобразовывать в таблицы при необходимости. Во-вторых язык доступа к БД это, допустим, интрепретатор, который умеет преобразовывать текстовые sql-команды в инструкции процессору. Ну и т.д. И это мы еще не обсуждаем тот момент, что современные СУБД это обычно довольно сложные клиент-серверные приложения, т.е. есть сервер БД и много клиентов с возможностью одновременного доступа к нему.
И вот он момент, когда все слова мне вроде бы понятны, а общий смысл уже непостижим :) Как работает БД из пары таблиц и с одним пользователем,я примерно представляю. Но вот как работает сервер БД с кучей разноуровневых запросов к нему, уже нет.
Reply
Reply
2)Хранение таблиц в рациональной форме на диске и в оперативной памяти, кэширование.
3) Логи операций, резервное копирование, возможность восстановления данных
4) Ну и всякие дополнительные фишки, вроде транзакционных механизмов, локировок, ролей пользователей и т.п.
Reply
Reply
Но во-первых сами данные вполне могут храниться в бинарном виде (более того, в основном так и хранятся, это рациональнее). Т.е. не таблицы, а просто сплошной набор байтов, которые я умею преобразовывать в таблицы при необходимости.
Во-вторых язык доступа к БД это, допустим, интрепретатор, который умеет преобразовывать текстовые sql-команды в инструкции процессору.
Ну и т.д.
И это мы еще не обсуждаем тот момент, что современные СУБД это обычно довольно сложные клиент-серверные приложения, т.е. есть сервер БД и много клиентов с возможностью одновременного доступа к нему.
Reply
Как работает БД из пары таблиц и с одним пользователем,я примерно представляю. Но вот как работает сервер БД с кучей разноуровневых запросов к нему, уже нет.
Reply
Reply
Спасибо :)
Reply
На здоровье. Спрашивай еще, если вдруг бены по программированию понадобятся. Давно здесь сижу :)
Reply
Leave a comment