любой нормальный сервер с поддержкой транзакций даже после сбоя операцию выполнит. монга кстати тоже выполнит операцию если сбой был на сервере БД
проблема монги в том, что те же каскадные удаления надо делать на программном уровне, и сбойнуть все может (с куда большей вероятностью чем падение сервера) именно на уровне приложения, и тут уже журнал операций сервера БД не поможет
люди описали свою ошибку, потом описали в каких случаях не использовать этот инструмент. заголовок немного не соответствует статье, но это не отменяет полезности самой статьи
И что? Меняйте. Имя сериала это описательное поле, это не индекс
в скольких коллекциях и скольких документах вы его храните во имя денормализации? а если что-то сломалось по дороге?
А что если в реляционной базе понадобится внести дополнительное поле описания? Это же надо будет изменить структуру таблицы для всего что уже записано и переиндексировать потом все с начала.
зачем? обычно это можно решить без такого размаха
С небольшим количеством данных удобнее работать в реляционной модели, но если данных много и приходится учитывать операции индексирования, то документарная модель лучше справляется.
очень многие вещи без того же JOIN выливаются в огромный баттхерт. а уж от потери целостности данных — так и совсем грустно становится
Я не путаю ничего. Проще — это когда все делается 1 запросом, который гарантированно или выполнится, или нет, не сломавшись на пол-дороги и не оставив базу в неопределенном состоянии.
А дополнительные поля описания — вполне можно вместить и в реляционную модель. Это будет не так красиво как в Mongo, но 5 лет использования Mongo на серьезных наборах данных четко убедили меня в мысли, что целостность — все-таки более приятный бонус.
ну вот люди сделали ошибку, написали статью о том как ошиблись (я думаю статья не новая явно)
если бы 5 лет назад эта статья попалась бы нам на глаза — мы бы тоже не выбрали монгу в качестве основной БД
а 5 лет назад в монге помимо ограничений «by design» было еще очень-очень много недоработок и хреновостей, которые приходилось героически преодолевать. сейчас с этим уже намного-намного лучше
так про это и статья: если нужна реляционность (а она чаще всего нужна) — Mongo не очень хороший выбор, так как реляционность придется делать на уровне кода, а это чревато массой проблем
Почему например документ не может из себя представлять описание эпизода?
А другой документ описание сериала. Причем эти документы можно разнести по разным коллекциям.
и потом банальная задача «удалить сериал» при отсутствии поддержки целостности превращается в многоступенчатый процесс:
— удаляем все связанные записи из коллекции с сериями
— удаляем все связанные записи из коллекции с отзывами
— удаляем запись из коллекции сериалов
а если записей много, и где-то этот процесс навернулся — у нас остается неконсистентность
при этом задача «удалить актеров, на которых больше нет ссылок из сериалов» — становится достаточно нетривиальной
какой же это кризис? производители выпускают разные модели, с разной начинкой и звуком, проводят эксперименты, меняют дизайн и софт. в общем, работа идет, зачем тут останавливаться? всегда найдется поле для улучшения. хоть это плееры, хоть автомобили, хоть компьютеры…
кстати, и эргономику они тоже сильно подтянули, те же iBasso и Fiio X5 — очень даже хороши
спасибо китайцам, благодаря их усилиям хорошую связку плеер + наушник можно приобрести где-то от 300 долларов, а за 500 — так и вовсе отличную. и этот ценник имеет тенденцию к снижению
проблема монги в том, что те же каскадные удаления надо делать на программном уровне, и сбойнуть все может (с куда большей вероятностью чем падение сервера) именно на уровне приложения, и тут уже журнал операций сервера БД не поможет
в скольких коллекциях и скольких документах вы его храните во имя денормализации? а если что-то сломалось по дороге?
зачем? обычно это можно решить без такого размаха
очень многие вещи без того же JOIN выливаются в огромный баттхерт. а уж от потери целостности данных — так и совсем грустно становится
А дополнительные поля описания — вполне можно вместить и в реляционную модель. Это будет не так красиво как в Mongo, но 5 лет использования Mongo на серьезных наборах данных четко убедили меня в мысли, что целостность — все-таки более приятный бонус.
если бы 5 лет назад эта статья попалась бы нам на глаза — мы бы тоже не выбрали монгу в качестве основной БД
а 5 лет назад в монге помимо ограничений «by design» было еще очень-очень много недоработок и хреновостей, которые приходилось героически преодолевать. сейчас с этим уже намного-намного лучше
и потом банальная задача «удалить сериал» при отсутствии поддержки целостности превращается в многоступенчатый процесс:
— удаляем все связанные записи из коллекции с сериями
— удаляем все связанные записи из коллекции с отзывами
— удаляем запись из коллекции сериалов
а если записей много, и где-то этот процесс навернулся — у нас остается неконсистентность
при этом задача «удалить актеров, на которых больше нет ссылок из сериалов» — становится достаточно нетривиальной
кстати, и эргономику они тоже сильно подтянули, те же iBasso и Fiio X5 — очень даже хороши