2008-08-28 105 views
8

Làm thế nào để bạn xác định rằng ràng buộc khóa ngoài phải là mối quan hệ 1: 1 trong sql giao dịch? Có khai báo cột UNIQUE đủ không? Dưới đây là mã hiện tại của tôi.!1: 1 Ràng buộc khóa ngoài

CREATE TABLE [dbo].MyTable(
    [MyTablekey] INT IDENTITY(1,1) NOT FOR REPLICATION NOT NULL, 
    [OtherTableKey] INT NOT NULL UNIQUE 
     CONSTRAINT [FK_MyTable_OtherTable] FOREIGN KEY REFERENCES [dbo].[OtherTable]([OtherTableKey]), 
    ... 
    CONSTRAINT [PK_MyTable] PRIMARY KEY CLUSTERED 
    (
     [MyTableKey] ASC 
    ) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY] 
GO 

Trả lời

9

Cột khóa ngoài có giới hạn UNIQUE và NOT NULL tham chiếu cột UNIQUE, NOT NULL trong bảng khác tạo mối quan hệ 1: (0 | 1), có thể là điều bạn muốn.

Nếu có mối quan hệ đúng 1: 1, mọi bản ghi trong bảng đầu tiên sẽ có một bản ghi tương ứng trong bảng thứ hai và ngược lại. Trong trường hợp đó, bạn có thể chỉ muốn tạo một bảng (trừ khi bạn cần một số tối ưu hóa lưu trữ lạ).

+2

..hoặc cần thiết để vượt quá giới hạn độ dài hàng của SQL. Microsoft Dynamics CRM thực hiện điều này để phân tách các cột được tạo sẵn từ các cột do người dùng thêm. – BlackWasp

+1

Hoặc nếu có một lý do chức năng để phân chia nó như các trường chỉ được tham chiếu trong một vài trường hợp mà bảng chính được tham chiếu thường xuyên. – HLGEM

+0

hoặc cho liên kết đa hình – WorldSEnder

4

Bạn có thể khai báo cột là cả khóa chính và khóa ngoài. Đây là một chiến lược tốt cho các bảng "mở rộng" được sử dụng để tránh đặt các cột vô giá vào bảng chính.

0

Dựa trên mã của bạn ở trên, ràng buộc duy nhất sẽ đủ cho mỗi khóa chính bạn có trong bảng, cột bị ràng buộc duy nhất cũng là duy nhất. Ngoài ra, điều này giả định rằng trong [OtherTable], cột [OtherTableKey] là khóa chính của bảng đó.

0

Nếu có mối quan hệ đúng 1: 1, mọi bản ghi trong bảng đầu tiên sẽ có bản ghi tương ứng trong bảng thứ hai và ngược lại. Trong trường hợp đó, bạn có thể chỉ muốn tạo một bảng (trừ khi bạn cần một số tối ưu hóa lưu trữ lạ).

Điều này rất không chính xác. Tôi sẽ cho bạn một ví dụ. Bạn có một bảng CLIENT có mối quan hệ 1: 1 với bảng SALES_OFFICE bởi vì, ví dụ, logic của hệ thống của bạn nói như vậy. Bạn có thực sự kết hợp dữ liệu của SALES_OFFICE vào bảng CLIENT không? Và nếu một bảng khác cần phải liên kết chúng với SALES_OFFICE? Và những gì về thực hành và mô hình chuẩn hóa cơ sở dữ liệu tốt nhất?

Cột khóa ngoài có giới hạn UNIQUE và NOT NULL tham chiếu cột UNIQUE, NOT NULL trong bảng khác tạo mối quan hệ 1: (0 | 1), có lẽ là những gì bạn muốn.

Phần đầu tiên của câu trả lời là câu trả lời đúng, không có phần thứ hai, trừ khi dữ liệu trong bảng thứ hai thực sự là một loại thông tin thuộc về bảng đầu tiên và sẽ không bao giờ được sử dụng bởi các bảng khác.

1

@bosnic:

Bạn có một khách hàng bảng mà có một 1: mối quan hệ 1 với bảng SALES_OFFICE vì, ví dụ, logic của hệ thống của bạn nói như vậy.

Logic ứng dụng của bạn nói gì và mô hình dữ liệu của bạn nói gì là 2 điều khác nhau. Không có gì sai khi thực thi mối quan hệ đó với mã logic nghiệp vụ của bạn, nhưng nó không có chỗ trong mô hình dữ liệu.

Bạn có thực sự kết hợp dữ liệu của SALES_OFFICE vào bảng CLIENT không?

Nếu mọi CLIENT đều có SALES_OFFICE duy nhất, và mỗi SALES_OFFICE có một số CLIENT duy nhất - thì có, chúng phải ở cùng một bảng. Chúng tôi chỉ cần một cái tên tốt hơn.;)

Và nếu một bảng khác cần liên kết chúng với self SALES_OFFICE?

Không có lý do gì để. Liên kết các bảng khác của bạn với CLIENT, vì CLIENT có SALES_OFFICE duy nhất.

Và điều gì về các mẫu và phương pháp hay nhất về chuẩn hóa cơ sở dữ liệu?

Điều này bình thường hóa.

Để công bằng, SALES_OFFICE và CLIENT rõ ràng không phải là mối quan hệ 1: 1 - đó là 1: N. Hy vọng rằng, SALES_OFFICE của bạn tồn tại để phục vụ hơn 1 khách hàng và sẽ tiếp tục tồn tại (trong một thời gian, ít nhất) mà không cần bất kỳ khách hàng nào.

Ví dụ thực tế hơn là SALES_OFFICE và ZIP_CODE. SALES_OFFICE phải có chính xác 1 ZIP_CODE và 2 SALES_OFFICE - ngay cả khi chúng có ZIP_CODE tương đương - không chia sẻ ví dụ của ZIP_CODE (do đó, việc thay đổi ZIP_CODE của 1 không ảnh hưởng đến nhau). Bạn sẽ không đồng ý rằng ZIP_CODE thuộc về một cột trong SALES_OFFICE?

Các vấn đề liên quan