Поиск
Позволю себе предоставить на конструктивный суд общественности список хорошо зарекомендовавших себя архитектурных решений и практик. Сегодня поговорим о базах данных MySQL.
Повелитель CHAR
Если есть возможность, используем поле CHAR для текстовых полей. И искать будет быстрее, и защита от дурака будет. Так, например, для MD5-хэша пароля это CHAR(32), для тикера валюты (USD, EUR) – CHAR(3). Есть ещё масса примеров: если ваше приложение работает с данными по аэропортам, то кандидатом на тип CHAR будет ICAO-код аэропорта (4 символа) или IATA-код (3 символа), если с банками, то код BIC.
Приручаем TIMESTAMP
Часто требуется хранить дату создания и/или модификации сущности (поля stamp_created и stamp_updated). Не все пользуются фреймворками типа Symfony, где система сама отвечает за их наполнение — и так как порой их актуальность обеспечивается вручную, были случаи, когда эти поля оставались просто пустыми — некогда было возиться. Можно объявить поле так, что этот функционал будет работать сам. Правда, в случае MySQL придётся выбирать: автоматически будет работать либо дата создания, либо дата модификации. Для этого нужно создать поле типа TIMESTAMP; в первом случае (created) указываем инициализацию текущим временем, во втором (updated) — указываем авто-обновление поля при каждой модификации текущей записи. Оба варианта умеет делать PHPMyAdmin.
Каскады FOREIGN KEY
Конечно, это касается не только MySQL. Удаление данных в иерархии сущностей можно автоматизировать с помощью каскадного удаления FOREIGN KEY (да, это банально, но часто на это кладут). Например, у меня в Rival Alert есть пользователи, у пользователей есть графики, у графиков есть данные. Без FOREIGN KEY функция удаления пользователя должна сначала удалить все данные по графикам этого пользователя, потом все его графики, и только потом — самого юзера. При использовании FOREIGN KEY вся соответствующая информация удалится сама, причем логикой на стороне сервера БД, и без дополнительных запросов от сервера приложений.
Кстати, FOREIGN KEY поддерживаются только в InnoDB-движке. Перейдя на него, вы получите возможность использовать транзакции, но потеряете полно-текстовый поиск (он в MyISAM).
Есть ещё идейка, которую держу про запас. В той же “Building Scalable Web Sites” пишут, что для ускорения работы приложения базу данных можно немножко де-нормализовать, например, рейтинги статей считать не налету на каждый запрос, а держать в отдельном поле таблицы статей уже в посчитанном виде и время от времени обновлять, ну или скажем вам нужно дублировать название/ссылку статьи в каждой записи рейтинга. Так вот идейка состоит в том, чтобы использовать CASCADE UPDATE для обновления полей в зависимой таблице — тогда целостность данных при такой денормализации будет выше.
INSERT + UPDATE в одном запросе
Частый кейс: если нет такого записи — вставить (INSERT), если есть — обновить для неё пару полей (UPDATE). Часто это решается через предварительный SELECT, чтобы установить факт наличия такой записи. Можно сделать это одним запросом, лишь бы был PRIMARY KEY или UNIQUE KEY.
Приведу пример. В том же Rival Alert у меня у одного графика за один день может быть только одно значение (такое вот условие). Сколько раз в базу будет класться это значение — не важно. Так вот, если значения “за сегодня” нет — мы его добавляем, если есть — обновляем (в поле `date` хранится текущая дата; пара `id_graph`+`date` — уникальна для каждой записи, что было указано через UNIQUE при создании таблицы).
Кстати, чтобы запрос стал красивее, и вам не нужно было два раза указывать значение вставки/обновления (в моём примере — это 4444), можно в разделе UPDATE указать, что нужно взять значение из раздела INSERT:
Оба запроса делают то же самое, только теперь вам нужно будет лишь в одном месте подставлять фактическое значение, а не в нескольких.
И последнее. Если вам нужно работать по сути с одними и теми же данными, но из разных баз данных, посмотрите в сторону Federated Storage Engine. Полезно иметь такую фичу на примете.
Надеюсь, эта заметка поможет вам кода писать меньше, а успевать больше.
Повелитель CHAR
Если есть возможность, используем поле CHAR для текстовых полей. И искать будет быстрее, и защита от дурака будет. Так, например, для MD5-хэша пароля это CHAR(32), для тикера валюты (USD, EUR) – CHAR(3). Есть ещё масса примеров: если ваше приложение работает с данными по аэропортам, то кандидатом на тип CHAR будет ICAO-код аэропорта (4 символа) или IATA-код (3 символа), если с банками, то код BIC.
Приручаем TIMESTAMP
Часто требуется хранить дату создания и/или модификации сущности (поля stamp_created и stamp_updated). Не все пользуются фреймворками типа Symfony, где система сама отвечает за их наполнение — и так как порой их актуальность обеспечивается вручную, были случаи, когда эти поля оставались просто пустыми — некогда было возиться. Можно объявить поле так, что этот функционал будет работать сам. Правда, в случае MySQL придётся выбирать: автоматически будет работать либо дата создания, либо дата модификации. Для этого нужно создать поле типа TIMESTAMP; в первом случае (created) указываем инициализацию текущим временем, во втором (updated) — указываем авто-обновление поля при каждой модификации текущей записи. Оба варианта умеет делать PHPMyAdmin.
Каскады FOREIGN KEY
Конечно, это касается не только MySQL. Удаление данных в иерархии сущностей можно автоматизировать с помощью каскадного удаления FOREIGN KEY (да, это банально, но часто на это кладут). Например, у меня в Rival Alert есть пользователи, у пользователей есть графики, у графиков есть данные. Без FOREIGN KEY функция удаления пользователя должна сначала удалить все данные по графикам этого пользователя, потом все его графики, и только потом — самого юзера. При использовании FOREIGN KEY вся соответствующая информация удалится сама, причем логикой на стороне сервера БД, и без дополнительных запросов от сервера приложений.
Кстати, FOREIGN KEY поддерживаются только в InnoDB-движке. Перейдя на него, вы получите возможность использовать транзакции, но потеряете полно-текстовый поиск (он в MyISAM).
Есть ещё идейка, которую держу про запас. В той же “Building Scalable Web Sites” пишут, что для ускорения работы приложения базу данных можно немножко де-нормализовать, например, рейтинги статей считать не налету на каждый запрос, а держать в отдельном поле таблицы статей уже в посчитанном виде и время от времени обновлять, ну или скажем вам нужно дублировать название/ссылку статьи в каждой записи рейтинга. Так вот идейка состоит в том, чтобы использовать CASCADE UPDATE для обновления полей в зависимой таблице — тогда целостность данных при такой денормализации будет выше.
INSERT + UPDATE в одном запросе
Частый кейс: если нет такого записи — вставить (INSERT), если есть — обновить для неё пару полей (UPDATE). Часто это решается через предварительный SELECT, чтобы установить факт наличия такой записи. Можно сделать это одним запросом, лишь бы был PRIMARY KEY или UNIQUE KEY.
Приведу пример. В том же Rival Alert у меня у одного графика за один день может быть только одно значение (такое вот условие). Сколько раз в базу будет класться это значение — не важно. Так вот, если значения “за сегодня” нет — мы его добавляем, если есть — обновляем (в поле `date` хранится текущая дата; пара `id_graph`+`date` — уникальна для каждой записи, что было указано через UNIQUE при создании таблицы).
Кстати, чтобы запрос стал красивее, и вам не нужно было два раза указывать значение вставки/обновления (в моём примере — это 4444), можно в разделе UPDATE указать, что нужно взять значение из раздела INSERT:
Оба запроса делают то же самое, только теперь вам нужно будет лишь в одном месте подставлять фактическое значение, а не в нескольких.
И последнее. Если вам нужно работать по сути с одними и теми же данными, но из разных баз данных, посмотрите в сторону Federated Storage Engine. Полезно иметь такую фичу на примете.
Надеюсь, эта заметка поможет вам кода писать меньше, а успевать больше.
