#java #hibernate #entity-relationship
#java #гибернация #сущность-отношение
Вопрос:
У меня есть существующий дизайн объекта. Существует Individual сущность. A Guardian или a Minor хранятся как Individual . Если вы Minor используете, вы назначили ноль или более опекунов. Эта связь хранится в другом объекте.
Существует дополнительное требование; добавить флаг, чтобы показать, что Guardian Address он должен использоваться для Minor , если установлена связь. Можно снять этот флаг позже. Если флаг снят, будет использоваться существующий адрес, и никакие изменения в адресе опекуна не будут перезаписывать адрес несовершеннолетнего.
Связь между Minor и Guardian сохраняется как
(minor_individual_id, guardian_individual_id, type_of_the_relationship)
где type_of_the_relationship может иметь такие значения, как «legal» и т. Д..
Это так же просто, как добавить новый флаг в таблицу отношений? После добавления адрес несовершеннолетнего должен быть изменен на адрес опекуна. Информация об адресе хранится в другом объекте ( Address ). Можно ли это сделать с помощью встроенной функции гибернации? Или мы должны добавить слой, чтобы позаботиться об этой функциональности? Есть ли что-нибудь в гибернации, что позволяет мне знать, что флаг был обновлен и должен произойти новый набор обновлений?
Объект address содержит индивидуальный идентификатор и адрес для отдельного лица в одной таблице.
Как только флаг установлен, его можно установить только один раз для каждого несовершеннолетнего, поскольку это приведет к путанице, если у несовершеннолетнего будет несколько опекунов, чтобы каскад адресов был включен для каждого из его опекунов. Спасибо.
Структура базы данных:
индивидуальная (таблица / объект)
Возраст идентификатора (в зависимости от возраста, вы рассматриваетесь как несовершеннолетний)
GuardianRelationShip (таблица / сущность)
Minor_Individual_Id
Guardian_Individual_Id
Адрес (таблица / объект)
Individual_Id
Адресная
строка1 Город
-государство
Если у Minor вас есть идентификатор с Individual идентификатором 2, а у a Guardian есть идентификатор с Individual идентификатором 1. Это будет выглядеть так
Id Age (Individual)
1 40 Guardian
2 5 Minor
Minor Guardian (GuardianRelationShip)
2 1
IndividualId City State (Address)
1 LA CA
2 NY NY
Как только они будут связаны, идея состоит в том, что адрес для второстепенного «индивидуального идентификатора 2» будет изменен на NY / NY.
Если есть запрос. в нем говорится, что используйте адрес опекуна для несовершеннолетнего и разрешите разблокирующий адрес, как бы вы это сделали?
Ответ №1:
У вас есть AddressEntity . Я бы создал IndividualEntity.address и адрес несовершеннолетнего могли ссылаться на тот же адрес, что и один из опекунов (кстати, несколько опекунов тоже могут жить по одному адресу!). После этого вы можете проверить, равен ли адрес несовершеннолетнего одному из адресов опекуна.
Я не понимаю, какую проблему решает флаг. Пожалуйста, предоставьте больше информации, а также некоторый код для иллюстрации ваших сущностей и отношений.
Комментарии:
1. Правильно, но в вашем идеальном мире. Адрес сохраняется как адрес, а ссылка на адрес сохраняется в другом объекте. В этом мире оба объединены, поэтому, если два человека живут по одному адресу, есть две строки данных, разница в которых заключается в индивидуальном идентификаторе. Следовательно, для того, чтобы я мог изменить адрес несовершеннолетнего, я должен физически перезаписать адрес несовершеннолетнего.
2. Итак, у вас есть fk в адресе для ссылки на человека? Не наоборот? В этом случае вы все равно можете сделать ссылку из MinorEntity на адрес. (Или не для адреса, а для RelationshipEntry, чтобы гарантировать, что несовершеннолетний ссылается на адрес своего опекуна)
3. Несовершеннолетний и опекуны не являются сущностями. Это просто определение пользователем отношений между двумя людьми. Я постараюсь лучше обновить редактирование, чтобы показать существующую erd.
4. В любом случае, вам нужно изменить структуру базы данных. Какие у вас есть ограничения на изменение модели данных? Не могли бы вы изменить это правильно?
5. Проблема заключается в изменении модели данных. Высшее руководство опасается изменения модели данных и возникновения проблем, поэтому ему приходится работать с сосуществующим дизайном.
Ответ №2:
Разрешить Individual запись без соответствующей Address записи. Если вы хотите ограничить его только хранителями, разрешайте только тот случай, когда запись для Individual таблицы не имеет соответствующего соответствия в GuardianRelationship.Minor столбце. Если адрес равен нулю, найдите guardian и используйте этот адрес.
Если вы применяете это правило выше, убедитесь, что вы учитываете крайние случаи, которые изменяют структуру, например, у человека больше нет указанного опекуна и у него нет адреса.
Комментарии:
1. Это не будет работать с момента запроса. указывает, что следует использовать адрес опекуна, но пользователь может переопределить. Это определенно требует, чтобы я сохранил решение пользователя.
2. @EnderWiggin Вставка адреса для младшего является переопределением. Если это null, родительский адрес. Если другой адрес, переопределение.
3. Я вижу только пару проблем; если вы не находите адрес, вы предполагаете, что адрес связан. Это означает, что они могут попытаться ввести адрес для младшего, который разорвет ссылку. Как вы решаете угловой случай, о котором вы упоминаете? Также как вы узнаете, какой адрес опекуна использовать?
4. Будет работать некоторая высокоуровневая логика для копирования адреса при удалении. Если у вас есть дело с двумя опекунами, вы можете затем запросить таблицу домохозяйств / адресов и связанную таблицу индивидуальных адресов. Это устраняет нулевое соображение, о котором я говорил выше.