Комментарии 22
По-моему, статья "Почему плохо надеяться на БД для валидации данных" — это из вредных советов.
Почему?
1 — NULL/NOT NOT, unique, fk — это все не только бизнес логика, но и технические ограничения. Позволяющие лучше понять, как разработчику, так и СУБД как лучше (правильнее) работать с данными.
2 — Если у приложения несколько интерфейсов, то и бизнес требования на каждом из них могут отличаться. СУБД тут может выступать арбитром в принятии конечного решения, проходят ли данные или нет.
3 — Иногда данные таки приходится править через различные db viewer-ы, да или даже миграции, где ты их вносишь в обход валидаций уровня приложения. Те же foreign keys или unique таким образом можно легко нарушить.
4 — В целом, зачем тогда реляционная СУБД? Все скатывается в NoSQL и контроль данных на уровне приложения.
Потому что автор слишком уж узко мыслит.
Валидность данных не должна зависеть от какого-то там условного ларавеля. Сегодня это только ларавел, завтра к нему добавились дотнет и питон. А послезавтра автор запушил релиз с багом в валидаторе и как наташины котики уронил вообще всё.
Уникальные и внешние ключи, NOT NULL и прочее — они не только про валидацию, они ещё и про построение модели данных, которой очень охотно пользуется оптимизатор.
Так что я на 100% согласен с предыдущем комментарием — советы очень вредные, особенно для использования в больших системах. Сначала автор не описал в СУБД модель данных, через полгода появилась необходимость создать парочку реплик базы, потому что всё тормозит, через год у вас в штате уже есть табунчик девопсов. Зато DDD и феншуй.1)
1) Феншуй в понимании его автором статьи с вредными советами.
Надеяться на БД в вопросе валидации данных действительно плохо, по-моему. Но ограничения уровня БД полезны как последний рубеж защиты от ошибок (или выбранных компромиссов) программиста (не пользователя). Попытки нарушения схемы БД должны отдавать 500 в контексте HTTP, а не 400 за редкими исключениями когда ради нефункциональных требований типа быстродействия приходится идти на возможные ошибки в SQL типа unique constraint violation, чтобы не лочить таблицы на запись.
[RFC] Saner string to number comparisons
Это будет славная охота. Хотя для многих она будет последней. Что скажете? (с) Маугли
$a = "9"
$a > 100 // true - php 8
$a > 100 // false - php 7
Это же ломает вообще всё…
нет, "9" это числовая строка и все работает по прежнему
https://3v4l.org/YaF6p
везде false
В PHP 8, при сравнении чисел и строк с помощью нестрогого == оба операнда приводятся к строке и сравниваются как строки, если один из них не является числовой строкой.
0 == 'foobar' теперь официально false.
Теперь собеседующим придётся указывать версию языка в вопросах о нестрогом сравнении =)
Это просто праздник какой-то, особенно про сравнение. Дело даже не в том, что более ожидаемый результат будет, а в том, что ломают BC в одной из "духовных скреп" PHP, что означает, что и другие 'столпы" не так твёрдо стоят. Глядишь и дойдём до строго динамически типизированного интерпретируемого языка
PHP-Дайджест № 185 (20 июля – 3 августа 2020)