A
" Есть таблица с фореин ключом на саму себя."
такое возможно?!
это как?
такое возможно?!
это как?
Например, если есть поле parent_id
Size: a a a
2020 October 26
VY
Так же как и с двумя таблицами, только связь делаешь на себя
ок,
и получаем именно ту проблему, как у Антона Кучерявого - в пустую таблицу невозможно ввести значение....
интересно - как ее решить?
у меня в проекте есть подобная проблема, почти такая же
и получаем именно ту проблему, как у Антона Кучерявого - в пустую таблицу невозможно ввести значение....
интересно - как ее решить?
у меня в проекте есть подобная проблема, почти такая же
SC
ок,
и получаем именно ту проблему, как у Антона Кучерявого - в пустую таблицу невозможно ввести значение....
интересно - как ее решить?
у меня в проекте есть подобная проблема, почти такая же
и получаем именно ту проблему, как у Антона Кучерявого - в пустую таблицу невозможно ввести значение....
интересно - как ее решить?
у меня в проекте есть подобная проблема, почти такая же
nullable колонка и всё
VY
nullable колонка и всё
та на которую форейн кей ссылается?
SC
та на которую форейн кей ссылается?
Ну да. parent_id или что там будет
VY
Ну да. parent_id или что там будет
да, для 1-й записи - ОК, а дальше как бы не очень :( - желательно, чтобы все остальные были обязательно с этим парент_ид...
кодом обеспечить?
кодом обеспечить?
SC
Сделай nullable, потом вставь строку, потом сделай не nullable.
SC
Звучит как дичь, но если надо — вот вариант в две миграции
A
Сделай nullable, потом вставь строку, потом сделай не nullable.
мне кажется, что это не сработает
A
да, для 1-й записи - ОК, а дальше как бы не очень :( - желательно, чтобы все остальные были обязательно с этим парент_ид...
кодом обеспечить?
кодом обеспечить?
проверяй на уровне приложения, чтобы никогда не был нулл и все
SC
мне кажется, что это не сработает
Теоретическая возможность есть. Проблема, что у всех записей должен быть проставлен parent_id, даже у корневого элемента.
Нахер это надо — второй вопрос.
Нахер это надо — второй вопрос.
A
Теоретическая возможность есть. Проблема, что у всех записей должен быть проставлен parent_id, даже у корневого элемента.
Нахер это надо — второй вопрос.
Нахер это надо — второй вопрос.
wat? на какого парента ссылается корневой элемент? что-то тут не так
SC
Вот именно.
A
wat? на какого парента ссылается корневой элемент? что-то тут не так
Ответив на этот вопрос, мы сможем ответить и на "что было раньше -курица или яйцо")))
A
Теоретическая возможность есть. Проблема, что у всех записей должен быть проставлен parent_id, даже у корневого элемента.
Нахер это надо — второй вопрос.
Нахер это надо — второй вопрос.
Не может он быть у всех проставлен. У родительских записей он останется null.
B
Теоретическая возможность есть. Проблема, что у всех записей должен быть проставлен parent_id, даже у корневого элемента.
Нахер это надо — второй вопрос.
Нахер это надо — второй вопрос.
типо сделать сидер который отключает проверку форейнов, добавляет запись с парент ИД 1 и ИД 1 и включает проверку ключей?)
B
VY
Звучит как дичь, но если надо — вот вариант в две миграции
А если в 1-й миграции не писать форейн-кей, но в ней же создать корневого юзера, а 2-й миграцией добавить только ФК.
Не будет ли это "правильнее"?
Не будет ли это "правильнее"?
SC
Всё хуйня. Я написал дичь. Делайте nullable и кодом проверяйте
ВС
Я не читал всё.. Но похоже кто то проектирует приложение с базы а не с логики приложения 🧐