Определение отношения "один-к-одному" в SQL Server

Мне нужно определить отношения "один к одному" и не может найти подходящего способа сделать это в SQL Server.

Почему индивидуальные отношения вы спрашиваете?

Я использую WCF как DAL (Linq), и у меня есть таблица, содержащая столбец BLOB. BLOB вряд ли когда-либо изменится, и это будет пустой тратой пропускной способности, чтобы передавать его каждый раз, когда выполняется запрос.

Я рассмотрел это решение, и хотя это кажется отличной идеей, я могу просто увидеть, что Linq имеет немного шипение, когда пытаясь реализовать этот подход.

Любые идеи?

Ответы

Ответ 1

Индивидуально на самом деле часто используется в отношении супертипа/подтипа. В дочерней таблице первичный ключ также служит внешним ключом для родительской таблицы. Вот пример:

org_model_00

CREATE TABLE Organization
( 
     ID       int PRIMARY KEY,
     Name     varchar(200),
     Address  varchar(200),
     Phone    varchar(12)
)
GO

CREATE TABLE Customer
( 
     ID              int PRIMARY KEY,
     AccountManager  varchar(100)
)
GO

ALTER TABLE Customer
    ADD  FOREIGN KEY (ID) REFERENCES Organization(ID)
        ON DELETE CASCADE
        ON UPDATE CASCADE
GO

Ответ 2

Почему бы не сделать внешний ключ каждой таблицы уникальным?

Ответ 3

нет такой вещи, как явное отношение "один-к-одному".

Но, поскольку tbl1.id и tbl2.id являются первичными ключами, а tbl2.id является ссылкой на внешний ключ tbl1.id, вы создали неявное отношение 1: 0..1.

Ответ 4

Поместите 1:1 связанные элементы в одну и ту же строку в той же таблице. То, что "отношение" в "реляционной базе данных" происходит от связанных вещей, входит в одну и ту же строку.

Если вы хотите уменьшить размер данных, перемещающихся по проводу, рассмотрите либо проецирование только необходимых столбцов:

SELECT c1, c2, c3 FROM t1

или создать представление, которое обрабатывает только соответствующие столбцы и использует это представление при необходимости:

CREATE VIEW V1 AS SELECT c1, c2, c3 FROM t1
SELECT * FROM t1
UPDATE v1 SET c1=5 WHERE c2=7

Обратите внимание, что BLOB хранятся за пределами строки в SQL Server, поэтому вы не сохраняете много дискового ввода-вывода по вертикальной разбивке своих данных. Если бы это были столбцы, отличные от BLOB, вы могли бы выиграть от вертикального разбиения, как вы описали, потому что вы будете делать меньше дискового ввода-вывода для сканирования базовой таблицы.

Ответ 5

Как насчет этого. Свяжите первичный ключ в первой таблице с первичным ключом во второй таблице.

Tab1.ID(PK) ↔ Tab2.ID(PK)

Моя проблема заключалась в том, что у меня есть двухэтапный процесс с обязательными полями в обоих. Весь процесс можно отнести к одному эпизоду (поставить в ту же таблицу), но есть начальный этап и заключительный этап.

Ответ 6

На мой взгляд, лучшим решением для не чтения BLOB с запросом LINQ было бы создание представления в таблице, содержащей весь столбец, кроме BLOB.

Затем вы можете создать объект EF на основе представления.