В 2017 году была очень популярна MongoDB — это такая база данных, которая не требует схемы, то есть не ограничивает разработчиков в формате данных, которые они в неё складывают. С тех пор много воды утекло — разработчики перестали пихать schemeless куда попало, менее маргинальные БД вроде PostgreSQL научились JSONb, а создатели MongoDB даже добавили поддержку схемы. Но многие ребята всё ещё пытаются хранить важные для бизнеса данные в JSON, и это плохо.
Сейчас покажу тупой пример. Допустим мы — книжное издательство, и храним у себя информацию о книгах в простом формате:
{
name: 'Как перестать переставать и начать начинать',
author: 'Роббинс, Тони',
…
}
Автора книги всегда можно узнать, обратившись к ключу author объекта типа book — так делают сайт, мобильное приложение, интеграция с типографией и электронная библиотека. И когда неожиданно после года работы выяснится, что автора у книги может быть два или три, и book.author становится массивом, вам приходится лезть во все приложения, которые выводят автора книги и менять код для вывода, иначе пользователи увидят что-то вроде «'Роббинс, Тони', 'Трейси, Брайан'» вместо «Тони Роббинс и Брайан Трейси».
Пример предельно упрощён, но смысл понятен — если не ограничить формат хранения данных, то рано или поздно кто-то туда положит такое дерьмо, от которого развалится всё приложение. Если не хотите, чтобы так случилось — делайте максимально жёсткую структуру данных: никогда не пользуйтесь JSON для важных данных, и добавляйте столько констрейнтов, сколько только можете придумать. Если вам не повезло работать с критичными данными, хранящимися в документоориентированных БД — пишите максимально жёсткие схемы.