Возьмем, к примеру, если у меня была таблица с именем «site» с столбцом created_at и update_at, которые были и DATETIME, и теперь нужно значение по умолчанию, я мог бы выполнить следующий sql для этого.
ALTER TABLE `site` CHANGE `created_at` `created_at` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP; ALTER TABLE `site` CHANGE `created_at` `created_at` DATETIME NULL DEFAULT NULL; ALTER TABLE `site` CHANGE `updated_at` `updated_at` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP; ALTER TABLE `site` CHANGE `updated_at` `updated_at` DATETIME NULL DEFAULT NULL;
Последовательность операторов важна, поскольку таблица не может иметь двух столбцов типа TIMESTAMP со значениями по умолчанию CUREENT TIMESTAMP
Проблема в дизайне базы данных. В вашей таблице набор ('kid_id', 'user_id') должен быть уникальным. Но второе (1,1) в вашем примере неверно, потому что уже есть набор (1,1).
Если вы хотите, чтобы один и тот же пользователь спонсировал «одного и того же ребенка несколько раз», ваш подход не сработает. Вы можете использовать отдельный первичный ключ для поддержания этого ограничения. В этом случае это должно быть что-то вроде
| pivot_id*| kid_id | user_id | * = Primary Key
+---------+---------+----------+
| 1 | 1 | 1 | -> Sponsored 1st Slot (CURRENTLY GETTING)
+---------+---------+----------+
| 2 | 1 | 1 | -> Sponsored 2nd Slot (SAME DATA WITH DIFFERENT KEY)
+---------+---------+----------+
| 3 | 2 | 1 | -> Sponsored 3rd Slot (THIS WILL WORK)
Да, я согласен с ответом @ Набила. Существует проблема с дизайном базы данных. Приложение выдает ошибку из-за уникального ограничения в таблицах БД. Либо придерживайтесь предложенного им подхода, либо вы также можете добавить поле подсчета. Я полагаю, вы хотите знать, сколько спонсоров получил ребенок? Сделайте все эти поля уникальными (kid_id, user_id, slots)