Внешний ключ базы данных в том или ином столбце

Можно ли связать одну таблицу с другой таблицей, даже если не ясно, в каком столбце отображается внешний ключ?

Образец:

Таблица ‘сервер’ имеет (среди прочих) два поля — > ‘внутренний ip’ и ‘внешний ip’

Другая таблица ‘server_details’ имеет только поле ‘ip’.

‘server_details ‘и’ server ‘ должны быть объединены по ip.

Проблема в том, что мы не знаем, является ли ip в server_details внешним или внутренним ip, поэтому он может отображаться в одном или в другом столбце, но каждый ip (должен быть) уникальным для всей базы данных и будет определенно соответствовать одному набору данных в одном из двух возможных полей.

Может кто-нибудь сказать мне, как это осознать? Или это вообще невозможно?

Я должен, наконец, сопоставить это поведение с доктриной entitys …

4 ответа

  1. Я думаю, что вы идете в противоположном направлении.

    server.internal_ip и server.external_ipможет иметь отношение внешнего ключа к server_details.ip

  2. Идея связывания таблиц является реликтом сетевой модели данных. В реляционных базах данных можно определить ограничения внешнего ключа (ограничения целостности, которые гарантируют, что значения одного столбца существуют в другом, но не создают и не ограничивают пути доступа) и объединить таблицы (при любых условиях, независимо от ограничений FK). Однако использование доктрины может ограничить вас в этом отношении, так как объектно-реляционные картографы пытаются изобретать базы данных сетевых моделей.

    Вы можете легко присоединиться serverк server_details:

    SELECT *
    FROM server_details sd
    INNER JOIN server s ON sd.ip = s.internal_ip OR sd.ip = s.external_ip
    

    или возможно

    INNER JOIN server s ON sd.ip = COALESCE(s.external_ip, s.internal_ip)
    

    Ограничение FK-это отдельный вопрос. Если ни один из ваших столбцов не представляет однозначно домен IPs, ограничение FK может быть неподходящим. Возможно, Вам удастся изменить свой дизайн, чтобы сделать его более сговорчивым к ограничениям целостности. Если вы опубликуете свою схему или список функциональных зависимостей, я могу изменить свой ответ.

  3. Следует добавить поле id на сервер, который может быть объявлен как PK, если сервер уже не имеет PK. Затем поместите поле server_id в server_details и объявите его как FK, который ссылается на сервер.id. Теперь, присоединиться легко:

    SELECT *
    FROM server_details sd
    INNER JOIN server s ON sd.server_id = s.id
    

    Поле id служит только для уникальной идентификации сервера. Для назначения новых значений можно использовать функцию autonumber СУБД.

    Я не уверен, как на это влияет доктрина.

  4. Проблема исчезла, потому что, по крайней мере, мы переопределили нашу datamodel в любом случае. Все равно спасибо за помощь!