и на какие ошибки вообще нужно тестировать?
вам потребуется писать скрипты, которые будут следить за целостностью этого json.
А что если в один прекрасный день добавится еще 1 конфиг, например изображение в шапке товара или еще что-то. Это все весьма неудобно станет поддерживать.
Я удаляю товар и все что к нему относится, по ключу красиво удаляется.
похожее в MySQL 5.5.
Скоро чихать буду от active record.
вы пренебрегаете заповедью "реляционная бд"
Во вторых, я вспомнил, как когда-то давно в детстве хранил картинки в json и это весьма не очень хорошая практика.
Тянет на парочку отдельных сервисов.
Поэтому я бы не пологался только на доктирину в плане целостности данных.
Поэтому внушительную часть логики можно вынести на сервер баз данных. Я не сторонник этого, но я сторонник того, чтобы все было максимально по понятиям и устойчиво как к потере данных, так и к структуре.
Поэтому я не могу свыкнуться с мыслью, что можно запить на базу, на ключи и тп. Как минимум ключи проставляют индексы. что способствует ускорению работы бд.
что они делают так-же.
Но тогда, для изображений не проставляется id автоматически, для этого я добавляю:
ну не знаю, вроде в доках написано, что можно не беспокоиться о связанности в пределах бандла.
Плюс, база - это хранилище, куда может иметь доступ не только проект с доктриной, и если нужно будет оставить базу, а все остальное выкинуть и переехать на другие технологии, тут весьма проблематичный вопрос выйдет.
Я придерживаю позиции, что база это отдельная сущность, которая должна быть спроектирована отдельно от технологий, который с ней работают.
Проектировать сущности это куда удобнее чем актив рекорд, но это не должно ломать базу, обходя ключи, делая данные более неустойчивыми к целостности.