Почему рекомендуется избежать однонаправленной one-many ассоциации на внешнем ключе? [дубликат]
1 ответ
Хотя сложно проверить, задействован ли SSL, проблема заключается в принудительном использовании SSL.
Из базы знаний RackspaceCloud Support :
Вы можете переписать URL-адреса в web.config:
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Redirect to HTTPS" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{HTTP_CLUSTER_HTTPS}" pattern="^on$" negate="true" />
<add input="{HTTP_CLUSTER-HTTPS}" pattern=".+" negate="true" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{SCRIPT_NAME}" redirectType="SeeOther" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Вы можете принудительно использовать SSL в ASP.NET:
<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<script runat="server">
protected void Page_Load(object sender, System.EventArgs e)
{
if(Request.ServerVariables["HTTP_CLUSTER_HTTPS"] != "on")
{
if(Request.ServerVariables.Get("HTTP_CLUSTER-HTTPS") == null)
{
string xredir__, xqstr__;
xredir__ = "https://" + Request.ServerVariables["SERVER_NAME"];
xredir__ += Request.ServerVariables["SCRIPT_NAME"];
xqstr__ = Request.ServerVariables["QUERY_STRING"];
if (xqstr__ != "")
xredir__ = xredir__ + "?" + xqstr__;
Response.Redirect(xredir__);
}
}
Response.Write("SSL Only");
}
</script>
<html>
<head id="Head1" runat="server">
<title>SSL Only</title>
</head>
<body>
</body>
</html>
однонаправленная ассоциация "один ко многим" на внешнем ключе является необычным случаем, и не рекомендуется.
У этого есть два аспекта:
- однонаправленный
- один ко многим
Поток удаленный ответ @CalmStorm ссылается на адреса только второго из этих вещи, но начнем с этого.
Этот поток рекомендует заменить отношения «один-ко-многим» на таблицы соединения, потому что в противном случае подход «один-ко-многим» «заполняет боковую таблицу с множеством столбцов, которые не принадлежат этой сущности, они существуют только для« связывания »порпусов. (так в оригинале) '. Эта тактика может привести к чистой модели на уровне Hibernate, но, к сожалению, приведет к повреждению базы данных.
Потому что SQL может только утверждать, что у дочерней записи есть родитель; нет способа обеспечить соблюдение правила, согласно которому у родителя должен быть ребенок. Следовательно, нет никакого способа настаивать на том, чтобы таблица имела записи в объединяемой таблице, и в результате появляется возможность иметь потерянные дочерние записи, то есть как раз то, что внешние ключи предназначены для предотвращения.
У меня есть еще несколько возражений, но следующее по важности - несоответствие. Таблицы пересечений предназначены для представления отношений «многие ко многим». Использование их для представления отношений «один ко многим» сбивает с толку и требует слишком много дополнительных объектов базы данных, на мой вкус.
Итак, ко второму аспекту: однонаправленные ассоциации "один ко многим". Проблема в том, что Hibernate обрабатывает их по умолчанию. Если мы вставляем родительский элемент и дочерний элемент в одну транзакцию, Hibernate вставляет дочернюю запись, затем вставляет родительский элемент, а затем обновляет дочерний элемент с помощью родительского ключа. Для этого требуются откладываемые ограничения внешнего ключа (фу!) И, вероятно, также откладываемые ненулевые ограничения (двойное фу).
Есть несколько обходных путей. Один из них - использовать двунаправленные ассоциации "один ко многим". Согласно в цитируемом вами документе , это наиболее распространенный подход. Другой подход - настроить отображение дочернего объекта, но у него есть свои разветвления.