В базе данных нет ограничений внешнего ключа.!

Question

Моя организация работает на Spring MVC с Hibernate. Мы всегда указать ограничения внешнего ключа в файле отображения, как для человека и ContactList в Person.hbm.xml

<set name="ContactList"> 
    <key column="PersonId" foreign-key="Fk_Peson_Contact"/> 
    <one-to-many class="Sample.Model.Contact"/> 
</set> 

Это отображение будет создать один-ко-многим между Person и Contact, и держать PersonID в качестве столбца внешнего ключа в Contact таблице ,

Но теперь организация решила не говоря уже о каких-либо отношений в файле отображения, значит, в описанном выше случае Person отображение не будет иметь какой-либо один-ко-многим отображения вместо этого Contact отображение будет иметь свойство <property name="FK_PersonID"/>, который будет создать столбец для хранения personID. В этой таблице сценариев Person и Contact будут выглядеть одинаково, но разница заключается в их отсутствии между Person и Contact coz. Не указано сопоставление.

В таком случае, если мы хотим получить контактный листок человека, тогда нам нужно запустить два запроса для получения другого человека для его контактного списка. предположим, что мы хотим получить personList с помощью своего контактного списка, тогда мы должны указать For loop на PersonList и получить его ContactList, который будет сбрасывать количество запросов.

Когда я спрашиваю, почему не указать отношения, то старший сказал,

• Если внешний ключ в БД, то мы не можем сделать нарезку и секционирования.

• Когда мы запускаем запрос на соединение, DB занимает больше времени для его выполнения. Это может замедлить работу сервера БД.

Но, мой вопрос -

• если я делать For looping на personList то будет срабатывать количество запросов для извлечения контактов это возможно?

• Может ли такой цикл замедлить приложение или сервер приложений?

• Что делать, если я хочу получить personList с его conatctList, AddressList, QualificationList, вызывает ли это проблему n + 1?

Какой сценарий более выгоден, если указать отображение или нет.

Answer 1

Ну, я один из ранних демонов разбиения на (MS) SQL на Microsoft, они показали запрос, который выбран из разделенной таблицы с данными, заполненными несколькими участками, и использовал свои индексы и статистику, чтобы даже не беспокоиться доступ к разделам, которые не имели (релевантных) данных. Конечно, если у вас нет fk constaint, то он не может использовать индекс и статистику, чтобы знать соответствие fk. Я был бы уверен, что это будет покрыто Кален Делани в ее книге (для соответствующей версии MSSQL). Ключ в том, что статистика будет содержать необходимую информацию для предотвращения ненужных запросов. Демо фактически использовало объединение, чтобы легко демонтировать эффект.