I wanna be developer

Знаете ли вы, что в MySQL, помимо MyISAM и InnoDB, есть движок под названием Federated?

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

Её можно использоваться для следующих целей:

1. Каждый раз при собирании БД большого проекта приходится ждать по 15-20 минут, пока загрузится какая-то большая справочная таблица, например, города мира, список аэропортов мира или БД мест развлечений и отдыха. При использовании Federated вам нужно только задать CREATE TABLE — и данные будут сразу доступны из другой базы данных;
2. Эти справочные таблицы могут использоваться несколькими окружениями вашего проекта — например, на тестовом сайте и на продакш-версии.

Чтобы узнать, поддерживает ли ваш сервер данный движок, воспользуйтесь простейшим PHPMyAdmin — нажмите ссылку Домой (с домиком), затем “Типы таблиц”.

Если он недоступен, то зайдите в ваш my.ini файл, найдите блок “[mysqld]” и вставьте строку “federated” сразу после:

[mysqld]
federated

P.S. Если вы ошиблись в структуре созданной таблицы, PHPMyAdmin покажет вашу БД как пустую Чтобы исправить это, дропните эту таблицу SQL-запросом — и пересоздайте правильно.

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

Студент будучи хорошим учеником, спроектирует что-то вроде такой схемы:

products (id, name, price, quantity) -- для хранения товаров и остатков
users (id, name) -- для хранения пользователей
orders (id, date, sum) -- для хранения заказов

Потом студент свяжет эти таблицы, и будет прав, теория на его стороне:

users_orders (id_user, id_order)
orders_products (id_order, id_product)

Если студент был не просто хорош, а очень хорош, он навесит индексы, и foreign-keys.

Магазин начал работу, товары вносятся в базу, появились клиенты, пошл продажи. Все хорошо, убрали позиции старого ассортимента, добавили новые, пара клиентов забыли свои пароли и создали новые аккаунты. Тут начались чудеса – звонит клиент и просит найти старый заказ, а его нет. А если есть заказ, он оказывается пуст… В чем же ошибка ?

Ошибка в том что в эту сферически-вакуумную базу не были внесены некоторые неидеальности, чтобы учесть неидеальность реальности.

Заказ в интернет-магазине – это не просто список, это факт. Это – снимок реальности в каком то моменте времени. Поэтому таблица должна была выглядеть так:
orders_products (id_order, product_name, product_price, quantity, sum)

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

С foreign keys и каскадным удалением тоже шутить не надо – удаление плохого пользователя из таблицы users не должно удалять его заказы. Заказ – это факт свершенный, отрицать его или выкинуть ради красоты теории будет неверным.

Для лучшего понимания алгоритмов сортировки можно посмотреть анимацию их работыдиваниdistributed raman amplifier — нужно только кликнуть на нужный вид.