Что такое база данных на сайте. Просто о сложном

Александр Гусев

Веб-разработчик, it-волонтёр, фотограф

Для чего она нужна, как ею управлять и причем здесь скорость загрузки сайта? А еще есть так называемые ревизии, которые добавляют своих особенностей при работе. Посмотрим на все это со стороны, чтобы затем можно было умело обращаться с базой данных своего сайта. Заодно узнаем, сколько времени нужно запросу, чтобы сходить на базу и принести обратно на сайт найденную информацию.

Краткий вводный абзац

Любую информацию на сайте нужно где-то хранить. Это факт очевидный. А вот места хранения могут быть разными. Первый вариант – прямо внутри html или php файла. Такой способ встречается часто. Это когда вы открываете страницу в админке, чтобы отредактировать там информацию, а внутри страница пустая. Совсем. Но при просмотре страницы на сайте там есть текст, картинки, другие данные.

На it-волонтере у меня было, наверное, с десяток задач, когда нужно было поменять информацию именно таким способом. Все дело в том, что в этом случае текст и ссылки на картинки добавлены напрямую в php-файл темы сайта. Для изменения страницы нужно зайти на хостинг в папку темы и отредактировать нужный файл.

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

Что такое база данных

Технически это файл с расширением .sql (для сайта на WordPress). Внутри у него есть таблицы, в которых есть строки. А уже в строках записаны данные. Именно отсюда эти данные и берутся для вывода на страницах сайта. Главное преимущество такой схемы хранения данных – вся информация лежит в одном файле. А значит, ее можно легко сохранить.

Помимо информации страниц, в базе данных содержится много служебной информации. В общем, важный файл. Посмотреть список баз данных вашего аккаунта на хостинге можно в разделе «Базы данных».

Список баз данных на хостинге Timeweb.

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

Причем здесь скорость загрузки сайта

Связь здесь самая прямая. Чем меньше база данных, тем быстрее в ней найдется информация для дальнейшего отображения на сайте. И наоборот. К тому же, помимо контента страниц, в базе данных хранится и другая, служебная, информация.

А это, в первую очередь, данные всех плагинов сайта. Если у вас есть плагин безопасности, который записывает всю активность пользователей (неудачные попытки входа на сайт, активные сессии), то где он хранит все эти данные? Все там же, в базе данных. Только в отдельной таблице.

База данных хранит в себе все комментарии на сайте, данные всех зарегистрированных пользователей, все ссылки и настройки сайта. Короче говоря, вообще все. Без базы данных ваш сайт просто не откроется. Вместо этого выводится пустой экран с фразой «Ошибка установки соединения с базой данных». Поэтому чем больше на сайте контента и плагинов, тем больше размер базы данных. А это значит, что со временем скорость работы сайта может упасть.

Что такое ревизии постов и страниц

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

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

Поэтому время от времени такие копии нужно удалять. Сделать это можно с помощью плагина Optimize Database after Deleting Revisions.

Скриншот страницы плагина в каталоге WordPress.

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

У меня стоят вот такие настройки плагина:

Скриншот настроек плагина оптимизации базы данных.

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

К слову о плагинах – на сайте Теплицы есть статья про плагины под разные задачи для сайта на WordPress. Посмотрите, почитайте.

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

Что в итоге

Да, вся эта база данных чуть сложнее, чем правка страниц в админке сайта. Но все равно разобраться можно. Очень рекомендую как минимум проверить размер базы данных вашего сайта. Сделать это можно на хостинге или через плагин, кому как удобней. Увидите там много строк в какой-нибудь таблице – значит, есть повод разобраться в причинах и прибраться там. Сделайте сами или создавайте задачу на it-волонтере. Я подобных задач там не припомню, будет интересно.

Что такое База Данных (БД) / Хабр

База данных — это место для хранения данных. Используется в том числе в клиент-серверной архитектуре. Это все интернет-магазины, сайты кинотеатров или авиабилетов… Вы делаете заказ, а система сохраняет ваши данные в базе.

В этот статье я на простых примерах расскажу, что такое база данных и как она выглядит. А потом поясню некоторые термины из конкретной (реляционной) базы. Те, с которыми вы почти наверняка столкнетесь на работе.

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

Содержание

• Что такое база данных

• Как она выглядит

• Как получить информацию из базы

• Как связать данные между собой

• Зачем в базе индексы

• Что делать, если запрос к БД тормозит

• Преимущества базы данных

• Что знать для собеседования

• Статьи и книги по теме

• Резюме

Что такое база данных

База данных — хранилище,  куда приложение складывает свои данные. Если приложение небольшое, отдельная база не нужна. Но потом это становится удобнее и выгоднее с точки зрения памяти.

Катя решила открыть свой магазинчик. Она нашла хорошую марку обуви, которую «днем с огнем» не сыскать в ее городе. Заказала оптовую партию и стала потихоньку распродавать через знакомых. Пришлось освободить половину шкафа под коробки, но вроде всё поместилось.

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

Но покупатели хотят новинок, разных размеров. Да и самих покупателей становится все больше и больше. В шкаф коробки уже не влезают!

Теперь, если покупатель просит определенную пару, Катьке сложно её найти. Пока коробок было мало, она помнила наизусть, где что лежит. А теперь уже нет, да и все попытки организовать систему провалились. Места мало, да и детки любят с коробками поиграть.

Тогда Катька решила арендовать складское помещение. И вот теперь красота! Не надо теснить своих домашних, дома чисто и свободно! И на складе место есть, появилась система — тут босоножки, тут сапоги…

Чем больше объемы производства, тем больше нужно места. Если в начале пути склад не нужен, всё поместится дома, то потом это будет оправданно.

То же самое и в приложениях. Если приложение маленькое, то все данные можно хранить в памяти. Но учтите, что это память на вашем компьютере, вашем телефоне. И чем больше данных туда пихать, тем медленнее будет работать программа.

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

Как она выглядит

Да примерно как excel-табличка! Есть колонки с заголовками, и информация внутри:

Это называется реляционная база данных — набор таблиц, хранящихся в одном пространстве.

Что за пространство? Ну вот представьте, что вы храните все данные в excel. Можно запихать всю-всю-всю информацию в одну огро-о-о-о-мную таблицу, но это неудобно. Обычно табличек несколько: тут информация по клиентам, там по заказам, а тут по адресам. Эти таблицы удобно хранить в одном месте, поэтому кладем их в отдельную папочку:

Так вот пространство внутри базы данных — это та же самая папочка в винде. Место, куда мы сложили свои таблички, чтобы они все были в одном месте.

Пример базы Oracle

Цель та же — выделить отдельное место, чтобы у вас не была одна большая свалка:

Хранение данных в виде табличек — это не единственно возможный вариант. Вот вам для примера запись из таблицы в системе Users. Там используется MongoDB база данных, она не реляционная. Поэтому вместо таблички «словно в excel» каждая запись хранится в виде объекта, вот так:

А еще есть файловые базы — когда у вас вся информация хранится в файликах. Да-да, простых текстовых файликах!

Почитать о разных видах баз данных можно в википедии. Я не буду в этой статье углубляться в эту тему, потому что моя задача — объяснить «что это вообще такое» для ребят, которые базу в глаза не видели. А на работе они скорее всего столкнутся именно с реляционной базой данных, поэтому о ней и речь.

Да, базы бывают разные. Классификацию можно изучить, можно выучить. Но по факту от начинающего тестировщика обычно нужно уметь достать информацию из реляционной БД («обычно» != «всегда», если что).

Как получить информацию из базы

Нужно записать свой запрос в понятном для базы виде — на SQL. SQL (Structured Query Language) — язык общения с базой данных. В нем есть ключевые слова, которые помогут вам сделать выборку:

• select — выбери мне такие-то колонки…

• from — из такой-то таблицы базы…

• where — такую-то информацию…

Например, я хочу получить информацию по клиенту «Назина Ольга». Составляю в уме ТЗ:

Дай мне информацию по клиенту, у которого ФИО = «Назина Ольга»

Переделываю в SQL:

select * from clients where name = 'Назина Ольга';

В дословном переводе:

select -- выбери мне
* -- все колонки (можно выбирать конкретные, а можно сразу все)
from clients -- из таблицы clients
where name = 'Назина Ольга'; -- где поле name имеет значение 'Назина Ольга'

См также:

Комментарии в Oracle/PLSQL — мой перевод остается работающим запросом, потому что я убрала «лишнее» в комментарии

Если бы у меня была не база данных, а простые excel-файлики, то же действие было бы:

1. Открыть файл с нужными данными (clients)

2. Поставить фильтр на колонку «ФИО» — «Назина Ольга».

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

Бывают запросы и сложнее — когда надо достать данные не из одной таблицы, а из разных. В базе это будет выглядеть даже лучше, чем в эксельке. В экселе вам нужно открыть 1-2-3 таблицы и смотреть в каждую. Неудобно.

А в базе данных вы внутри запроса SQL указываете, какие колонки из каких таблиц вам нужны. И результат запроса их отрисовывает. Скажем, мы хотим увидеть заказ, который сделал клиент, ФИО клиента, и его номер телефона. И всё это в разных таблицах! А мы написали запрос и увидели то, что нам надо:

И пусть в таблице клиентов у нас будет 30 колонок, а в таблице заказов 50, в результате выборки мы видим ровно 4 запрошенные. Удобно, ничего лишнего!

Конечно, написать такой запрос будет немного сложнее обычного селекта. Это уже select join, почитать о нем можно тут. И я рекомендую вам его изучить, потому что он входит в «базовое знание sql», которое требуется на собеседованиях.

Результаты выборки можно группировать, сортировать — это следующий уровень сложности. См раздел «статьи и книги по теме» для получения большей информации.

Как связать данные между собой

Вот например, у нас есть интернет-магазин по доставке пиццы. Так выглядит его база данных:

• В таблице «orders» лежат данные по заказам. Что заказали (пиццу, суши, роллы), когда, насколько довольны доставкой?

Но как понять, где чей был заказ? Сколько раз заказывал Вася, а сколько Алина?

Тут есть несколько вариантов:

1. Запихать все данные в одну таблицу: тут и заказы, и информация по клиентам… В целом удобно, открыл табличку и сразу видишь — ага, это Васин заказ, а это Машин.

Но есть минусы:

• Таблица все растет и растет, в итоге получается просто огромной! А когда данных много, легкость чтения пропадает, придется листать до нужной колонки.

• Поиск будет работать медленнее. Чем меньше информации в таблице, тем быстрее поиск. Когда у нас много строк, количество колонок становится существенным.

• Много дублей — один человек может сделать хоть сотню заказов. И вся информация по нему будет продублирована сто раз. Неоптимальненько!

Чтобы избежать дублей, таблицы принято разделять:

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

Нам надо у заказа сделать отметку о клиенте. Значит, таблица «orders» будет ссылаться на таблицу «clients». Ключ можно поставить на любую колонку таблицы (в некоторых базах колонка должна быть уникальной, сначала её нужно такой указать). Какую бы выбрать?

Можно ссылаться на имя. А что, миленько, в таблице заказов будем сразу имя видеть! Но минуточку… А если у нас два клиента Ивана? Или три Маши? Десять Саш… Ну вы поняли =) И как тогда разобраться, где какой клиент? Не подходит!

Можно вешать foreign key на несколько колонок. Например, на фамилию + имя, или фамилию + имя + отчество. Но ведь и ФИО бывают неуникальные! Что тогда? Можно добавить в связку дату рождения. Тогда шанс ошибиться будет минимален, хотя и такие ребята существуют. И чем больше клиентов у вас будет, тем больше шанс встретить дубликат.

А можно не усложнять! Вместо того, чтобы делать внешний ключ на 10 колонок, лучше создать в таблице клиентов primary key, первичный ключ. Первичный ключ отвечает за то, чтобы каждое значение в поле было уникальным, никаких дублей. При попытке добавить в таблицу запись с неуникальным первичным ключом получаешь ошибку:

Здесь ключ — «id_order»

Вот на него и нужно ссылаться! Обычно таким ключом является ID, идентификатор записи. Его можно сделать автоинкрементальным — это значит, что он генерируется сам по алгоритму «прошлое значение + 1».

Например, у нас гостиница для котиков. Это когда хозяева едут в отпуск, а котика оставить не с кем — оставляем в гостинице!

Есть таблица постояльцев:

Тут привозят еще одного Барсика. Добавляем его в таблицу:

— Имя Барсик, 5 лет! (мы не указываем ID)

Система добавляет:

ID сгенерился автоматически. Последнее значение было 2, значит, новый Барсик получил номер 3. Обратите внимание — Барсиков уже два, но их легко различить, ведь у них разные идентификаторы!

Теперь, если в другой таблице надо будет сослаться на котика, мы будем делать это именно через уникальный идентификатор. Например, у нас есть таблица комнат для постояльцев, куда мы заносим информацию о том, кто там живет:

Мы видим, что в первой комнате живет котик с id = 1, а во второй — с id = 2. В третьей комнате пока никто не живет. Так, благодаря связке таблиц, мы всегда можем понять, что именно за котофей там проживает.

Итак, теперь мы знаем, что идентификатор лучше делать первичным ключом, дабы обеспечить его уникальность. Можно сделать поле автоинкрементальным, чтобы оно заполнялось само. Так и поступим в таблице клиентов:

И в таблице заказов! «id_order» пусть генерится сам и всегда будет уникален. А еще в таблицу заказов мы добавим колонку «id_client» и повесим на нее foreign key, ссылку на «id_client» в таблице клиентов.

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

И наоборот, несколько таблиц могут ссылаться на одну и ту же колонку текущей таблицы. ID клиента мы можем указывать в таблице адресов, телефонов, email адресов, документов, заказов… Ограничений на это нет.

Зачем в базе индексы

Давайте представим, что у нас есть табличка excel. Если она небольшая (пара строк, пара колонок), то найти нужную ячейку не составит труда:

1. Открыли файлик — открывается моментально (если нет проблем с жестким диском)

2. Нажали «Ctrl + F», ввели запрос — тут же нашли результат.

Но что, если у нас сотни колонок и миллионы строк в файлике? Тогда начинаются тормоза. Файл открывается долго, в поиск значение ввели и система подвисла, обрабатывая результат…

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

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

Индекс — это как алфавитный указатель в библиотеке. Вот представьте, заходите вы в библиотеку и хотите найти «Преступление и наказание» Достоевского. А все книги стоят «от балды», никакого порядка. Чтобы найти нужную, надо обойти все стелажи и просмотреть все полки!

Совсем другое дело, если книги отсортированы по авторам. А внутри автора — по названию. Тогда найти нужную книгу будет легко!

Индекс играет ту же роль для базы данных. Если повесить его на колонку таблицы, поиск по ней пойдет быстрее!

А можно повесить индекс на несколько нужных колонок (автор + название). Тут главное — не забывать порядок поиска в индексе. Если у нас индекс сначала по автору, а потом по названию, он будет бесполезен для поиска по названию, придется все равно пересматривать все книги. Поэтому, если нам часто нужно искать по названию и почти никогда — только по автору, имеет смысл поменять порядок в индексе — сначала название, потом автор.

Что делать, если запрос к БД тормозит 

Если мы говорим о тестировщиках (а статья написана в первую очередь для них), то тут есть 2 варианта:

1. Вы работаете с базой напрямую, составляете запросы к ней. И эти запросы работают медленно.

2. Медленно работает система, но уже поняли, что тормозит выборка из БД (например, увидели в логах).

Первый вариант мы разбирать не будем. Потому что это не про базу, а про SQL. И, если вы работаете с базой, то должны уметь писать сложные запросы, применять хинты там, где нужно, и так далее. Это не тема базовой статьи.

А вот что делать во втором случае? Это не задача тестировщика — разбираться в том, почему запрос работает медленно. Этим занимаются DBA (администраторы баз данных) или разработчики.

Зато задача тестировщика — предоставить разработчику всю нужную информацию. Иногда её можно запросить у заказчика и его админов, а иногда нужно достать самому. Обычно для этого нужно:

1. Получить план запроса

2. Пересобрать статистику и проверить, продолжает ли тормозить

План запроса

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

1. Строит план выполнения запроса (как ей кажется, оптимальный)

2. Выполняет его

Посмотреть план можно через ключевые слова. В Oracle это EXPLAIN PLAN:

EXPLAIN PLAN FOR -- построй мне план для...
SELECT last_name FROM employees; -- вот такого запроса!

А если вы работаете через графический интерфейс, то там обычно можно просто выделить запрос и нажать горячую клавишу. Выглядит ответ примерно так:

На рис sql developer — графический интерфейс для обращения к базе Oracle

Сверху на картинке идёт запрос. А снизу — план его выполнения. Нас сейчас не сильно волнует, что значит информация из первых колонок (то, как именно запрос обходит базу, в данном случае фулл-скан по таблице), нас интересует последняя колонка, «COST». Это стоимость запроса — 857 ms.

А теперь изменим запрос, сделав выборку по одному конкретному человеку по колонке с индексом:

Оп, цена запроса уже 5 ms. Это, на минуточку, в 170 раз быстрее!

И это простейший запрос на тестовой базе. В реальной базе данных будет сильно больше, поэтому проход таблицы по индексированной колонке существенно сократит время выполнения запроса.

Вот пример плана чуть более сложного запроса, когда мы делаем выборку из двух таблиц:

Вы не обязаны понимать, «что тут вообще происходит», но вам нужно уметь получать этот план. Пригодится.

Допустим, поступает жалоба от заказчика — клиент открывает карточку в вебе, а она открывается минуту. Что-то где-то тормозит! Но что и где? Начинаем разбираться. Причины бывают разные:

1. Тормозит на уровне БД — тут или сам запрос долго отрабатывает, или статистику давно не пересобирали, или диски подыхают.

2. Тормозит на уровне приложения — тогда надо копаться внутри кода функции «открыть карточку», что она там делает, получив ответ от Базы (и снова есть вариант «подыхают диски, на которых установлено ПО»).

3. Тормозит на уровне сети — сервер приложения и сервер БД обычно размещают на разных машинах. Значит, есть общение между ними по интернету. А интернет может тупить.

Если есть подозрение, что тормозит сам select, разработчик попросит прислать план его выполнения на реальной базе. Конечно, если «с той стороны» грамотные админы, они это сделают сами. Но иногда это нужно уметь вам. Например, если вас отправили в банк разбираться на месте, что пошло не так. Вы проверяете разные гипотезы и собираете информацию для разработчика.

Собираете план, сохраняете в файлик и прикладываете в задачу в джире. Или отправляете по почте.

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

Статистика в БД

Именно статистика позволяет базе данных выбрать оптимальный план выполнения запроса. Почему вообще возникают проблемы вида «на тестовой базе один план, на боевой другой»?

Да потому, что один и тот же запрос можно выполнить несколькими способами. Например, у нас есть таблица клиентов и таблица телефонов, и мы пишем такой запрос:

Найди мне всех клиентов, созданных в этом году,

У которых оператор связи в телефоне — Мегафон

Как можно выполнить запрос? Можно сначала обойти таблицу клиентов и поискать тех, кто создан в этом году. А потом уже для них проверять телефоны. Можно наоборот, проверить все телефоны на оператора и потом уже для связанных клиентов проверять дату создания.

Какой вариант будет лучше? Никто не скажет без данных по таблицам. Может, у нас мало клиентов, но кучи телефонов (база перекупщиков), тогда быстрее будет начать с клиентов. А может, у нас миллионы клиентов, но всего пара сотен телефонов, тогда мы начнем с них.

Так вот, в статистике по БД хранится в том числе информация о распределении данных и характеристики хранения таблиц и индексов. И когда вы запускаете запрос, база (а точнее, оптимизатор внутри нее) строит возможные планы выполнения. Для каждого плана рассчитывает примерное время выполнения, а потом выбирает лучшее.

Время же он рассчитывает, ориентируясь на статистику:

Именно поэтому просто пересбор статистики иногда убирает проблему «у нас тут тормозит». Прилетело в таблицу много данных, а статистика об этом не знает, и чешет по таблице через фуллскан, считая, что информации там мало.

См также:

Ручной и автоматический сбор статистики оптимизатора в базе данных Oracle

Практические методы оптимизации запросов в Apache Spark — подробнее об оптимизации запросов, в том числе и про индексы

Преимущества реляционных баз данных

Почему используют реляционную базу данных:

1. Она поддерживают требования ACID (по крайней мере транзакционная БД)

2. Это единый синтаксис SQL, который используется повсеместно

Требования ACID

ACID — это аббревиатура из требований, которые обеспечивают сохранность ваших данных:

• Atomicity — Атомарность

• Consistency — Согласованность

• Isolation — Изолированность

• Durability — Надёжность

Если база данных не поддерживает их, то могут быть печальные последствия из серии «Деньги с одного счета ушли, на другой не пришли? Ну сорян, бывает».

См также:

Требования ACID на простом языке — подробнее об этих требованиях

Единый синтаксис SQL

Я спросила знакомого разработчика:

— Ну и что, что единый синтаксис? В чем его плюшка то?

Ответ прекрасен, так что делюсь с вами:

— Почему в школе все преподают на русском? Почему не каждый свой язык? Одна школа — один, другая — другой. А ещё лучше не школа, а для каждого человека. Почему вавилонскую башню недостроили?

Как разработчик пишет код? Написал, проверил на коленке. Если не работает — думает, почему. Если непонятно, идет гуглить похожие ошибки. А что проще нагуглить? Ошибку распространенной БД, или сделанный на коленке костыль для работы с файлами? Вот то-то и оно…

Что знать для собеседования

Для начала я хочу уточнить, что я сама тестировщик. И мои статьи в первую очередь для тестировщиков ))

Зато тестировщика спрашивают про SQL. Вот вам обсуждение из чатика выпускников, пригодится для повторения материала:

— В вакансии написано: уметь составлять простые SQL запросы. А простые это какие в народном понимании?

— (inner, outer) join, select, insert, update, create, последнее время популярны индексы, group by, having, distinct.

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

Статьи и книги по теме

База данных

Википедия

Какие бывают базы данных

Базы данных. Виды и типы баз данных. Структура реляционных баз данных. Проектирование баз данных. Сетевые и иерархические базы данных.

SQL

Книги:

Изучаем SQL. Линн Бейли — Обожаю эту линейку книг, серию Head First O`Reilly. И всем рекомендую)) Просто и доступно даже о сложном пишут.

Статьи:

Как изучить основы SQL за 2 дня

Полезные запросы

Тренажеры:

http://www.sql-ex.ru/ — Бесплатный тренажер для практики

Ресурсы и инструменты для практики с базами данных | SQL

Задачка по SQL. Найти объединенные данные

Резюме

База данных — это место для хранения данных. Они бывают самых разных видов, даже файловые! Но самые распространенные — реляционные базы данных, где данные хранятся в виде таблиц.

Если посмотреть на информацию о таблице в БД, мы можем увидеть ее ключи и индексы. Что это такое:

1. PK — primary key, первичный ключ. Гарантирует уникальность данных, часто используется для колонки с ID. Если ключ наложен на одну колонку — каждое значение в ячейках этой колонки уникальное. Если на несколько — комбинации строк по колонкам уникальны.

2. FK — foreign key, внешний ключ. Нужен для связки двух таблиц в разных соотношениях (1:1, 1:N, N:N). Этот ключ указываем в «дочерней» таблице, то есть в той, которая ссылается на родительскую (в таблице с данными по лицевому счету отсылка на client_id из таблицы клиентов).

3. Индекс. Нужен для ускорения выборки из таблицы.

Транзакционные базы данных выполняют требования ACID:

• Atomicity — Атомарность

• Consistency — Согласованность

• Isolation — Изолированность

• Durability — Надежность

См также:

Что такое транзакция

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

Поэтому логика приложения — отдельно, база — отдельно. Так и получается клиент-серверная архитектура =)

См также:

Клиент-серверная архитектура в картинках

Чтобы достать данные из базы, надо написать запрос к ней на языке SQL (Structured Query Language). Разработчики пишут SQL-запросы внутри кода приложения. А тестировщики используют SQL для:

• Поиска по базе — правильно ли данные сохранились? В нужные таблицы легли? Это select-запросы.

• Подготовки тестовых данных — а что, если это значение будет пустое? А что, если у меня будет 2 лицевых счета на одной карточке? Можно готовить данные через графический интерфейс, но намного быстрее отправить несколько запросов в базу. Когда есть к ней доступ и вы знаете SQL =)

План-минимум для изучения: select, join, insert, update, create, delete, group by, having, distinct.

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

Так вот, тестировщика на собеседовании не будут спрашивать про базы данных. Разработчика ещё могут спросить, а вас то зачем? Вполне достаточно понимания, что это вообще такое. И про ключи могут спросить — что такое primary или foreign key, зачем они вообще нужны.

Все, что вам нужно знать о веб-базах данных

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

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

Определение веб-базы данных

Веб-база данных — это, по сути, база данных, к которой можно получить доступ из локальной сети или Интернета, а не к базе данных, данные которой хранятся на рабочем столе или в подключенном хранилище. Используемые как для профессионального, так и для личного использования, они размещаются на веб-сайтах и ​​представляют собой продукты «программное обеспечение как услуга» (SaaS), что означает, что доступ предоставляется через веб-браузер.

Один из типов веб-баз данных, с которым вы, возможно, более знакомы, — это реляционная база данных. Реляционные базы данных позволяют хранить данные в группах (известных как таблицы) благодаря их способности связывать записи вместе. Он использует индексы и ключи, которые добавляются к данным, для поиска информационных полей, хранящихся в базе данных, что позволяет быстро извлекать информацию.

Чтобы нарисовать картину, просто подумайте о том, когда вы делаете покупки в Интернете и хотите взглянуть на конкретный продукт. Ввод ключевых слов, таких как «черное платье», позволяет всем черным платьям, хранящимся на веб-сайте, отображаться прямо в том самом браузере, который вы просматриваете, потому что информация «черное» и «платье» хранится в их записях базы данных.

Знаете ли вы, что Zenkit можно использовать для создания реляционной веб-базы данных с помощью полей ссылок связать вместе две таблицы (коллекции)?

Некоторые преимущества использования веб-базы данных включают:

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

MySQL

Что-то, что вы часто будете видеть в связи с темой веб-баз данных, а также стоит отметить, поскольку оно используется на многих высококлассных веб-сайтах, таких как Google, Facebook, Twitter и WordPress, — это MySQL. Основанная на языке структурированных запросов, MySQL представляет собой систему управления реляционными базами данных (СУБД).

Просто чтобы вы знали, система управления базами данных — это программное обеспечение, которое управляет перемещением данных в базу данных, из нее и из нее. Термин «база данных» относится к фактическим данным, которые хранятся.

MySQL — не единственная система управления базами данных, но одна из самых популярных. Причины этого:

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

Заключительные мысли

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

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

Ура,

Динни и команда Zenkit

Была ли эта статья полезной? Пожалуйста, оцените это!

Нажмите, чтобы оценить этот пост!

[Всего: 41 Среднее: 4,2]

Пожалуйста, поделитесь

Что такое веб-база данных?

`;

Интернет

Факт проверен

Дата последнего изменения: 31 октября 2022 г.

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

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

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

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

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

В некоторых случаях веб-базы данных можно купить с уже включенной информацией.

This entry was posted in Популярное