Definizione di una relazione uno a uno in SQL Server

Question

Devo definire una relazione uno-a-uno e non riesco a trovare il modo corretto di farlo in SQL Server.

Perché una relazione one-to-one chiedi?

Sto usando WCF come DAL (Linq) e ho una tabella contenente una colonna BLOB. Il BLOB non cambia quasi mai e sarebbe uno spreco di larghezza di banda trasferirlo ogni volta che viene effettuata una query.

Ho dato un'occhiata allo this solution e, sebbene sembri un'ottima idea, posso solo vedere Linq avere un piccolo sibilo quando proviamo a implementare questo approccio.

Qualche idea?

Answer 1

Uno a uno è in realtà utilizzato frequentemente nella relazione supertipo/sottotipo. Nella tabella figlio, la chiave primaria funge anche da chiave esterna per la tabella padre. Ecco un esempio:

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 

Answer 2

Perché non rendere la chiave esterna di ogni tabella univoca?

Answer 3

non esiste una relazione uno-a-uno esplicita.

Tuttavia, dal fatto che tbl1.id e tbl2.id sono chiavi primarie e tbl2.id è una chiave esterna che fa riferimento a tbl1.id, è stata creata una relazione implicita 1: 0..1.

Answer 4

Put 1: 1 oggetti collegati nella stessa riga della stessa tabella. Ecco da dove viene la "relazione" nel "database relazionale": le cose correlate vanno nella stessa riga.

Se si vuole ridurre la dimensione dei dati che viaggiano sul filo prendere in considerazione sia la proiezione solo le colonne necessarie:

SELECT c1, c2, c3 FROM t1 

o creare una vista che proietta solo le colonne rilevanti e utilizzare questo punto di vista, se necessario:

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

Si noti che i BLOB sono archiviati in fila in SQL Server in modo da non risparmiare molto I/O disco mediante il partizionamento verticale dei dati. Se si tratta di colonne non BLOB, è possibile trarre vantaggio dal partizionamento verticale come descritto, poiché si eseguirà meno IO del disco per eseguire la scansione della tabella di base.

Answer 5

Che ne dici di questo. Collegare la chiave primaria nella prima tabella alla chiave primaria nella seconda tabella.

Tab1.ID (PK) < -> Tab2.ID (PK)

Il mio problema era che ho un processo a 2 stadi con campi obbligatori in entrambi. L'intero processo potrebbe essere classificato come un episodio (messo nella stessa tabella), ma c'è uno stadio iniziale e uno stadio finale.

Answer 6

A mio parere, una soluzione migliore per non leggere il BLOB con la query LINQ sarebbe quella di creare una vista sulla tabella che contiene tutta la colonna eccetto quelle BLOB.

È quindi possibile creare un'entità EF in base alla vista.