Ruslan Ruslanov, не, не понимаете вы. Это скелет-архитектура приложения. Не для того, чтоб было проще, а для того, чтоб было устойчево и без багов при росте и развитии.
Иван, он тут откормился хорошо. Хотя на самом деле я его понимаю. обычно советуешь, расписываешь , а автор джун отмечает ответы такие же джуновские, а качественные ответы так и висят не принятыми.
Я пожалуй его понимаю.
lovebarcafc, вобще там всё максимально упрощено, чтоб хомячки поняли, а так многое в документации описано так, что в крупном проекте лучше делать иначе
Алексей Уколов, WebDev, Алексей верно говорит, плюсую. Он добрый, ему не лень всё объяснить. Если не понимаете зачем так делать, задайте вопросы более подробные, чтоб понять смысл.
Alex, Целостность БД должна гарантировать сама БД, в этом смысл реляционной БД, чтоб никакая другая приложенька не испортила данные, а у автора управление сервисным флагом на уровне приложения как-раз.
Алексей Уколов, Gomonov, Как говорится, какой вопрос, таков ответ.
Уже не первый раз замечаю, как хорошие решения пропускаются и отмечаются ответом решения уровня junior.
Теперь как на форум сюда захожу, в коментах развлекаться.
Фиговый вариант, по рукам за такой бил бы у меня в команде.
Никто не используйте его.
вот в коментах под другим ответом всё расписали как делать правильно.
На уровне БД (конкретно в MySQL) такое реализовать нельзя
Ужас, куда катится тостер))
Вобще-то такие вещи, как у автора, на уровне БД делать важно, если она реляционная.
Именно в этом и фишка реляционной БД, что в ней строится фундамент логики и она не дает сделать то, что нельзя.
И это можно делать теми же триггерами, если иное не доступно, чтоб соблюсти логику данных.
Maggy, ахахаха. Российская фирма.
Вброс засчитан.
Так же как и бюрократ, всё производится в китае, а в России свинчивают ножку, сидушку и спинку.
И юр адрес в России.