PHP Приведение SQL таблицы к нужному виду
Решил создать библиотеку, но сначала хотел узнать, может уже есть что-то готовое.
Смысл: не заходить каждый раз в phpmyadmin и не писать вручную патчи для обновления структуры. В простом php файле я создаю шаблон, указывая какая у нас должна быть таблица в БД, например:
table users (
id int(11) primary autoinc,
login varchar(60),
age int default "18",
email varchar(60),
comment text
);
и можно указать несколько таких таблиц.
Скрипт подключается к БД и делает следующее:
- проверяет, существует ли такая таблица, если нет то создаёт
- проверяет, существуют ли такие поля в таблице, если нет, то создаёт
- проверяет, соответствует ли каждое поле заданному типу, если нет, то обновляет тип поля
- аналогично со значениями по умолчанию
- в идеале ещё порядок полей чтобы обновлял как в шаблоне (но не знаю, насколько это реализуемо).
Думаю это сильно упростит и ускорит работу - изменяю один файл update_db.php и обновляю файлы на сервере. Не нужно писать патчи, не нужно лазать в phpmyadmin.
Ответы (1 шт):
Описанное вами называется идемпотентностью (сколько раз ни выполняй - результат один и тот же) - но миграции на практике зачастую описывают изменения в базе данных, которые нельзя вывести путем сравнения начального и конечного состояний схемы, поскольку у инструмента недостаточно информации, чтобы знать, как перенести существующие данные.
Несколько примеров:
Переименование таблицы, колонки, etc - думаю тут все понятно
Разделение или объединение столбцов - при разделении столбца можно создать два или более новых столбца и удалить исходный столбец. Аналогично, объединение столбцов создаст новый столбец и удалит исходные столбцы. В любом случае при идемпотентном сценарии любые данные в удаленных столбцах будут потеряны.
Изменение типа данных или размера столбца - при замене типа данных столбца, например с INT на SMALLINT, данные могут быть усечены
Работа с большими перемещениями данных - такие операции, как удаление столбца или добавление NOT NULL столбца со значением по умолчанию, могут занять много времени и создать много записей в журнале, крупномасштабные миграции данных в таких условиях лучше всего делать постепенно в отдельных разбиваемых партиях
etc