Целесообразно ли использовать yml с данными, вместо бд и entity?
Здравствуйте.
Есть три типа списков - категории, действия и скиллы в которых будут храниться иерархические данные одной вложенности (id -- title -- parent). Сказали мне, что их нужно хранить в YML конфиге, а не в БД, аргументируя, что они маловероятно будут изменяться в будущем, а для связи этих данных с Entity проекта написать менеджер. По-моему - это нецелесообразный геморрой, может просто я чего-то не понимаю и это нормальная практика ?
Окей, если в некоторых случаях это удобно - хранить в yml данные, то каким образом тогда осуществлять связь между этими данными и сущностями доктрины ? Например связи ManyToMany ?
ну не знаю на счет менеджера. но репозиторий писать придется, а для того что бы все это работало нежно с доктриной еще и свой гидратор которйы умеет эти данные туда пихать. Как по мне проще в базе это хранить + написать простенькие cli скрипты для управления этим делом.
Тут другой вопрос, если это удобнее поддерживать через yaml будет (как никак его можно в git хранить, что упрощает контроль), то может оно и лучше.
Спасибо за ответ. Печаль-беда. Я-то надеялся на категорическое - "нет" )) Вопрос еще один - каким образов осуществлять связь между, например категорией и сущностью (например Image). Т.е. когда все хранится в БД, то есть таблица, например - image_categories, где два поля image_id и category_id. Тут же как организовать, если в yml будет написана только иерархия. Прописывать ID вручную, или использовать вместо ID - ключ массива ? Или вообще хранить категории в сериализованном виде ? Просто мой мозг говорит ,что это в высшей степени извращение и отказывается понимать всю ситуацию )
Сергей Протько: Про гидраторы я понял, сам процесс связывания осознал, только как организовать хранение связующей информации, использовать для этого сериализованные данные в ячейке таблицы, либо ключи массива из yml кидать в связующую таблицу , или ID для каждого элемента из YML списка прописывать вручную ?
Сергей Протько: я вроде понял, а вроде и не понял. Ну вот есть у меня 50 записей. Я их закидываю в YML файл:
categories:
category:
id: 1
name: category_1
category:
id: 2
name: category_2
...
- это тупость и не вижу преимущества хранения в YML
или
categories:
category_1:
id: 1
category_2:
id: 3
...
- это тоже идиотия
или
categories:
category_1
category_2
...
- ну, а тут как тогда связывать с сущностями в БД ? ManyToMany например. По ключу массива ? Ну так, а если я поменяю местами значения ? Или хранить в виде:
categories:
FIRST_CATEGORY: category_1
SECOND_CATEGORY: category_2
...
- а если таких 50 значений ? Для каждого писать конский ключ ?
Это не к вам претензии, вы не подумайте, просто у меня бомбит от ситуации.
Александр Евгеньевич:
1) если у категории может быть только один родитель, то можно в одном файле все хранить. Тогда преимущества будут, иначе да, как-то странно. Работать со всем этим делом через репозиторий.
2) при many-to-many мы просто будем использовать не доктриновскую коллекцию а свою. И это будет просто как еще один тип. Тогда у нас все взаимодействие объектов сохраняется и боли нету.
Ну в целом да, повторюсь, это большое усложнение и оно оправдано только когда вам критически важно иметь полный контроль над данными через VCS например. Ну короче я не вижу проблем что бы это реализовать но и профита особо не вижу. так как можно случайно нарушить целостность.
Сергей Протько: у меня тут еще вопрос, как система должна реагировать, на случай удаления значение (entity) из yml файла ? При удалении из БД все связи тоже подчищаются, однако же, при удалении из YML все же останется на месте. Я так понимаю, при выборке должна будет идти проверка на соответствие связи - действительности, и если сущность из YML уже не существует, удалять связь ? При использовании ManyToMany будем использовать свою коллекцию, т.е. нужно ее передавать при загрузке приложения в доктрину, чтобы она могла с ней работать ? И по поводу "еще один тип" - тип поля ? Может у вас там где ссылка завалялась на раздел из доков доктрины, как раз для этого случая ? А то ну совсем не понятно, что и в каком порядке нужно делать, каким образом доктрина будет знать, откуда брать данные для связи ManyToMany. Придется править аннотации ?
Александр Евгеньевич: вот в последнем предложении моего последнего комментария я уже говорил что вы таким образом позволите случайно нарушить целостность в базе. В этом случае просто при выборке по id будет возвращаться null.
Сергей Протько: глянул. Получается вместо аннотаций, вида "ManyToMany(JoinTable()) и т.д." Просто создать свой тип поля, который будет хранить в себе массив значений ?
Сергей Протько: задам уж тут вопрос, так быстрее, создал я тип поля и столкнулся с тем, что в тип-то ничего не заинжектить, а данные о категориях у меня хранятся в контейнере. Как быть ? Неужто не получится ограничится только типом поля и придется фигачить гидратор ? Я глянул ObjectHydrator так чуть не помер от количества всего в нем.
Можно хранить в БД, а редактировать в YAML.
Вариантов несколько. Можно, например, загонять из YAML в БД с помощью команды. Или сделать страницу, на которой прозрачно для пользователя подгружаются данные из БД и отображается YAML, а когда пользователь его сохраняет, в БД данные обновляются.
Спасибо за ответ. Но задача заключалась именно в хранении в YML редактировании в YML без взаимодействия с БД. Решено было использовать тип поля SET, создать кастомный тип в Doctrine и связать все через менеджер (сервис). Как-то так.
Средний
