Chúng ta lại đi, tranh luận cũ vẫn nảy sinh ...

Chúng ta nên có một khóa doanh nghiệp làm khóa chính hay chúng ta muốn có một id thay thế (tức là một danh tính SQL Server) với một ràng buộc duy nhất trên trường khóa doanh nghiệp?

Xin vui lòng, cung cấp các ví dụ hoặc bằng chứng để hỗ trợ lý thuyết của bạn.

Cả hai. Có bánh của bạn và ăn nó.

Hãy nhớ rằng không có gì đặc biệt về khóa chính, ngoại trừ việc nó được dán nhãn như vậy. Nó không có gì khác hơn là một ràng buộc KHÔNG NULL UNIITE và một bảng có thể có nhiều hơn một.

Nếu bạn sử dụng khóa thay thế, bạn vẫn muốn khóa doanh nghiệp để đảm bảo tính duy nhất theo quy tắc kinh doanh.

Chỉ một vài lý do để sử dụng khóa thay thế:

1. Tính ổn định : Thay đổi khóa vì doanh nghiệp hoặc nhu cầu tự nhiên sẽ ảnh hưởng tiêu cực đến các bảng liên quan. Khóa thay thế hiếm khi, nếu có, cần phải được thay đổi bởi vì không có ý nghĩa gắn liền với giá trị.

2. Quy ước : Cho phép bạn có một quy ước đặt tên cột Chính được tiêu chuẩn hóa thay vì phải suy nghĩ về cách tham gia các bảng với các tên khác nhau cho các PK của chúng.

3. Tốc độ : Tùy thuộc vào giá trị và loại PK, khóa thay thế của một số nguyên có thể nhỏ hơn, nhanh hơn để lập chỉ mục và tìm kiếm.

Dường như chưa có ai nói bất cứ điều gì hỗ trợ cho các phím không thay thế (tôi ngần ngại nói các phím "tự nhiên"). Vì vậy, ở đây đi ...

Một nhược điểm của khóa thay thế là chúng vô nghĩa (được một số người coi là một lợi thế, nhưng ...). Điều này đôi khi buộc bạn phải tham gia nhiều bảng hơn vào truy vấn của mình hơn là thực sự cần thiết. Đối chiếu:

select sum(t.hours)
from timesheets t
where t.dept_code = 'HR'
and t.status = 'VALID'
and t.project_code = 'MYPROJECT'
and t.task = 'BUILD';

chống lại:

select sum(t.hours)
from timesheets t
     join departents d on d.dept_id = t.dept_id
     join timesheet_statuses s on s.status_id = t.status_id
     join projects p on p.project_id = t.project_id
     join tasks k on k.task_id = t.task_id
where d.dept_code = 'HR'
and s.status = 'VALID'
and p.project_code = 'MYPROJECT'
and k.task_code = 'BUILD';

Trừ khi bất cứ ai nghiêm túc nghĩ rằng sau đây là một ý tưởng tốt?:

select sum(t.hours)
from timesheets t
where t.dept_id = 34394
and t.status_id = 89    
and t.project_id = 1253
and t.task_id = 77;

"Nhưng" ai đó sẽ nói, "điều gì xảy ra khi mã cho MYPRO DỰ ÁN hoặc GIÁ TRỊ hoặc nhân sự thay đổi?" Câu trả lời của tôi sẽ là: "tại sao bạn cần thay đổi nó?" Đây không phải là các khóa "tự nhiên" theo nghĩa là một số cơ quan bên ngoài sẽ hợp pháp hóa từ đó 'GIÁ TRỊ' nên được mã hóa lại thành 'TỐT'. Chỉ một tỷ lệ nhỏ các khóa "tự nhiên" thực sự thuộc danh mục đó - mã SSN và Zip là các ví dụ thông thường. Tôi chắc chắn sẽ sử dụng một khóa số vô nghĩa cho các bảng như Người, Địa chỉ - nhưng không phải cho tất cả mọi thứ , vì một số lý do mà hầu hết mọi người ở đây dường như ủng hộ.

Xem thêm: câu trả lời của tôi cho một câu hỏi khác

Khóa thay thế sẽ KHÔNG BAO GIỜ có lý do để thay đổi. Tôi không thể nói như vậy về các phím tự nhiên. Họ, email, nubmer - tất cả đều có thể thay đổi một ngày.

Khóa thay thế (thường là số nguyên) có giá trị gia tăng giúp quan hệ bảng của bạn nhanh hơn và tiết kiệm hơn về tốc độ lưu trữ và cập nhật (thậm chí tốt hơn, không cần cập nhật khóa ngoại khi sử dụng khóa thay thế, trái ngược với trường khóa doanh nghiệp, điều đó thay đổi ngay bây giờ và sau đó).

Khóa chính của bảng nên được sử dụng để xác định duy nhất hàng, chủ yếu cho mục đích nối. Hãy nghĩ về bảng Người: tên có thể thay đổi và chúng không được bảo đảm là duy nhất.

Hãy nghĩ về các công ty: bạn là một công ty Merkin hạnh phúc khi làm việc với các công ty khác ở Merkia. Bạn đủ thông minh để không sử dụng tên công ty làm khóa chính, vì vậy bạn sử dụng ID công ty duy nhất của chính phủ Merkia trong toàn bộ 10 ký tự chữ và số. Sau đó Merkia thay đổi ID công ty vì họ nghĩ rằng đó sẽ là một ý tưởng tốt. Không sao, bạn sử dụng tính năng cập nhật xếp tầng của công cụ db của bạn, để thay đổi không liên quan đến bạn ngay từ đầu. Sau đó, doanh nghiệp của bạn mở rộng và bây giờ bạn làm việc với một công ty ở Freedonia. Id công ty Freedonia lên đến 16 ký tự. Bạn cần phóng to khóa chính id công ty (cũng là các trường khóa ngoại trong Đơn hàng, Sự cố, MoneyTransifts, v.v.), thêm trường Quốc gia vào khóa chính (cũng trong khóa ngoại). Ôi! Nội chiến ở Freedonia, nó ' S chia thành ba quốc gia. Tên quốc gia của cộng sự của bạn nên được đổi thành tên mới; xếp tầng cập nhật để giải cứu. BTW, khóa chính của bạn là gì? (Quốc gia, CompanyID) hoặc (CompanyID, Quốc gia)? Cái sau giúp tham gia, cái trước tránh một chỉ mục khác (hoặc có lẽ nhiều, nếu bạn muốn Đơn hàng của mình được nhóm theo quốc gia).

Tất cả những điều này không phải là bằng chứng, nhưng một dấu hiệu cho thấy khóa thay thế để xác định duy nhất một hàng cho tất cả các mục đích sử dụng, bao gồm cả hoạt động tham gia, thích hợp hơn là khóa doanh nghiệp.

Tôi ghét khóa thay thế nói chung. Chúng chỉ nên được sử dụng khi không có khóa tự nhiên chất lượng có sẵn. Thật là vô lý khi bạn nghĩ về nó, để nghĩ rằng thêm dữ liệu vô nghĩa vào bảng của bạn có thể làm cho mọi thứ tốt hơn.

Đây là lý do của tôi:

1. Khi sử dụng các khóa tự nhiên, các bảng được nhóm theo cách mà chúng thường được tìm kiếm nhất do đó làm cho các truy vấn nhanh hơn.

2. Khi sử dụng các khóa thay thế, bạn phải thêm các chỉ mục duy nhất vào các cột khóa logic. Bạn vẫn cần ngăn chặn dữ liệu trùng lặp hợp lý. Ví dụ: bạn không thể cho phép hai Tổ chức có cùng tên trong bảng Tổ chức của mình mặc dù pk là cột id thay thế.

3. Khi các khóa thay thế được sử dụng làm khóa chính, thì rõ ràng các khóa chính tự nhiên là gì. Khi phát triển bạn muốn biết tập hợp cột nào làm cho bảng trở nên độc đáo.

4. Trong một đến nhiều chuỗi mối quan hệ, chuỗi khóa logic. Vì vậy, ví dụ: Tổ chức có nhiều Tài khoản và Tài khoản có nhiều Hóa đơn. Vì vậy, khóa logic của Tổ chức là OrgName. Khóa logic của Tài khoản là OrgName, AccountID. Khóa logic của Hóa đơn là OrgName, AccountID, InvoiceNumber.

   Khi các khóa thay thế được sử dụng, các chuỗi khóa bị cắt ngắn chỉ bằng cách có một khóa ngoại cho cha mẹ ngay lập tức. Ví dụ: bảng Hóa đơn không có cột OrgName. Nó chỉ có một cột cho AccountID. Nếu bạn muốn tìm kiếm hóa đơn cho một tổ chức nhất định, thì bạn sẽ cần tham gia các bảng Tổ chức, Tài khoản và Hóa đơn. Nếu bạn sử dụng các khóa logic, thì bạn có thể Truy vấn bảng Tổ chức trực tiếp.

5. Lưu trữ các giá trị khóa thay thế của các bảng tra cứu làm cho các bảng chứa đầy các số nguyên vô nghĩa. Để xem dữ liệu, các chế độ xem phức tạp phải được tạo để nối với tất cả các bảng tra cứu. Bảng tra cứu có nghĩa là giữ một tập hợp các giá trị được chấp nhận cho một cột. Nó không nên được mã hóa bằng cách lưu trữ khóa thay thế số nguyên thay thế. Không có gì trong các quy tắc chuẩn hóa cho thấy rằng bạn nên lưu trữ một số nguyên thay thế thay vì chính giá trị đó.

6. Tôi có ba cuốn sách cơ sở dữ liệu khác nhau. Không phải một trong số họ hiển thị bằng cách sử dụng các khóa thay thế.

Tôi muốn chia sẻ kinh nghiệm của tôi với bạn về cuộc chiến bất tận này: D về vấn đề nan giải tự nhiên và thay thế. Tôi nghĩ rằng cả khóa thay thế (khóa được tạo tự động nhân tạo) và khóa tự nhiên (bao gồm (các) cột có ý nghĩa miền) đều có ưu và nhược điểm . Vì vậy, tùy thuộc vào tình huống của bạn, có thể phù hợp hơn khi chọn phương pháp này hay phương pháp khác.

Vì dường như nhiều người trình bày các khóa thay thế là giải pháp gần như hoàn hảo và các khóa tự nhiên là bệnh dịch, tôi sẽ tập trung vào các quan điểm khác của quan điểm:

Nhược điểm của khóa thay thế

Các khóa thay thế là:

1. Nguồn gốc của vấn đề hiệu suất:
   • Chúng thường được thực hiện bằng các cột tăng tự động có nghĩa là:
     • Một chuyến đi khứ hồi tới cơ sở dữ liệu mỗi khi bạn muốn nhận Id mới (tôi biết rằng điều này có thể được cải thiện bằng cách sử dụng bộ nhớ đệm hoặc thuật toán [seq] hilo nhưng các phương thức đó vẫn có nhược điểm riêng).
     • Nếu một ngày bạn cần di chuyển dữ liệu của mình từ lược đồ này sang lược đồ khác (ít nhất nó xảy ra khá thường xuyên trong công ty của tôi) thì bạn có thể gặp phải sự cố va chạm Id. Và Có, tôi biết rằng bạn có thể sử dụng UUID nhưng những lần kéo dài đó đòi hỏi 32 chữ số thập lục phân! (Nếu bạn quan tâm đến kích thước cơ sở dữ liệu thì đó có thể là một vấn đề).
     • Nếu bạn đang sử dụng một chuỗi cho tất cả các khóa thay thế của mình thì - chắc chắn - bạn sẽ kết thúc với sự tranh chấp trên cơ sở dữ liệu của mình.
2. Dễ bị lỗi. Chuỗi có giới hạn max_value vì vậy - với tư cách là nhà phát triển - bạn phải chú ý đến các điểm sau:
   • Bạn phải quay vòng chuỗi của mình (khi đạt đến giá trị tối đa, nó sẽ quay trở lại 1,2, ...).
   • Nếu bạn đang sử dụng chuỗi theo thứ tự (theo thời gian) dữ liệu của mình thì bạn phải xử lý trường hợp đi xe đạp (cột có Id 1 có thể mới hơn hàng có giá trị tối đa Id - 1).
   • Đảm bảo rằng mã của bạn (và thậm chí các giao diện máy khách của bạn không nên xảy ra vì nó là Id nội bộ) hỗ trợ các số nguyên 32b / 64b mà bạn đã sử dụng để lưu trữ các giá trị chuỗi của mình.
3. Họ không đảm bảo dữ liệu không trùng lặp. Bạn luôn có thể có 2 hàng với tất cả các giá trị cột giống nhau nhưng với giá trị được tạo khác nhau. Đối với tôi đây là THE vấn đề các phím thay thế từ một điểm thiết kế cơ sở dữ liệu của view.
4. Thêm trong Wikipedia ...

Huyền thoại về chìa khóa tự nhiên

1. Khóa tổng hợp ít hiệu quả hơn so với khóa thay thế. Không! Nó phụ thuộc vào công cụ cơ sở dữ liệu được sử dụng:
   • Oracle
   • MySQL
2. Chìa khóa tự nhiên không tồn tại trong cuộc sống thực. Xin lỗi nhưng chúng tồn tại! Ví dụ, trong ngành hàng không, bộ dữ liệu sau đây sẽ luôn là duy nhất liên quan đến một chuyến bay theo lịch trình nhất định (hãng hàng không, khởi hành, chuyến bay số, hoạt độngSuffix). Tổng quát hơn, khi một tập hợp dữ liệu kinh doanh được đảm bảo là duy nhất theo một tiêu chuẩn nhất định thì bộ dữ liệu này là một ứng cử viên tự nhiên [tốt].
3. Các khóa tự nhiên "gây ô nhiễm lược đồ" của các bảng con. Đối với tôi đây là một cảm giác nhiều hơn là một vấn đề thực sự. Có khóa chính gồm 4 cột gồm 2 byte, mỗi cột có thể hiệu quả hơn một cột 11 byte. Ngoài ra, 4 cột có thể được sử dụng để truy vấn trực tiếp bảng con (bằng cách sử dụng 4 cột trong mệnh đề where) mà không cần nối với bảng cha.

Phần kết luận

Sử dụng các khóa tự nhiên khi có liên quan để làm như vậy và sử dụng các khóa thay thế khi sử dụng chúng tốt hơn.

Hy vọng rằng điều này đã giúp ai đó!

Dù sao sử dụng một chìa khóa không có ý nghĩa kinh doanh. Đó chỉ là thực hành tốt.

EDIT: Tôi đã cố gắng tìm một liên kết đến nó trực tuyến, nhưng tôi không thể. Tuy nhiên, trong 'Các mô hình kiến ​​trúc doanh nghiệp' [Fowler], nó có một lời giải thích tốt về lý do tại sao bạn không nên sử dụng bất cứ thứ gì ngoài một khóa không có ý nghĩa gì ngoài việc là một khóa. Thực tế là nó chỉ nên có một công việc và một công việc duy nhất.

Khóa thay thế khá tiện dụng nếu bạn định sử dụng công cụ ORM để xử lý / tạo các lớp dữ liệu của mình. Mặc dù bạn có thể sử dụng các khóa tổng hợp với một số trình ánh xạ nâng cao hơn (đọc: hibernate), nhưng nó sẽ thêm một số phức tạp vào mã của bạn.

(Tất nhiên, những người theo chủ nghĩa cơ sở dữ liệu sẽ lập luận rằng ngay cả khái niệm khóa thay thế cũng là một sự gớm ghiếc.)

Tôi là một fan hâm mộ của việc sử dụng uids cho các phím thay thế khi thích hợp. Chiến thắng chính với họ là bạn biết trước khóa, ví dụ: bạn có thể tạo một thể hiện của một lớp với ID đã được đặt và được đảm bảo là duy nhất trong khi với, một khóa số nguyên bạn sẽ cần mặc định là 0 hoặc - 1 và cập nhật thành giá trị phù hợp khi bạn lưu / cập nhật.

Mặc dù vậy, UID có hình phạt về mặt tra cứu và tốc độ tham gia vì vậy nó phụ thuộc vào ứng dụng được đề cập đến việc liệu chúng có mong muốn hay không.

Theo tôi, sử dụng khóa thay thế sẽ tốt hơn vì không có cơ hội thay đổi. Hầu như bất cứ điều gì tôi có thể nghĩ về cái mà bạn có thể sử dụng như một khóa tự nhiên đều có thể thay đổi (từ chối trách nhiệm: không phải lúc nào cũng đúng, nhưng thông thường).

Một ví dụ có thể là DB của ô tô - thoạt nhìn, bạn có thể nghĩ rằng biển số xe có thể được sử dụng làm chìa khóa. Nhưng những điều này có thể được thay đổi để đó là một ý tưởng tồi. Bạn sẽ không thực sự muốn tìm ra điều đó sau khi phát hành ứng dụng, khi ai đó đến với bạn muốn biết lý do tại sao họ không thể thay đổi biển số của họ thành một cái mới được cá nhân hóa sáng bóng của họ.

Luôn luôn sử dụng một cột duy nhất, thay thế khóa nếu có thể. Điều này làm cho các phép nối cũng như chèn / cập nhật / xóa sạch hơn nhiều vì bạn chỉ chịu trách nhiệm theo dõi một mẩu thông tin duy nhất để duy trì hồ sơ.

Sau đó, khi cần thiết, xếp các khóa kinh doanh của bạn dưới dạng các chỉ số hoặc chỉ mục duy nhất. Điều này sẽ giữ cho bạn toàn vẹn dữ liệu.

Logic nghiệp vụ / khóa tự nhiên có thể thay đổi, nhưng khóa phisical của bảng KHÔNG BAO GIỜ thay đổi.

Trên một kịch bản trung tâm dữ liệu, tôi tin rằng tốt hơn là đi theo con đường chính thay thế. Hai lý do:

• Bạn độc lập với hệ thống nguồn và các thay đổi ở đó - như thay đổi kiểu dữ liệu-- sẽ không ảnh hưởng đến bạn.
• DW của bạn sẽ cần ít không gian vật lý hơn vì bạn sẽ chỉ sử dụng các loại dữ liệu số nguyên cho các khóa thay thế của mình. Ngoài ra các chỉ số của bạn sẽ làm việc tốt hơn.

Khóa thay thế có thể hữu ích khi thông tin doanh nghiệp có thể thay đổi hoặc giống hệt nhau. Rốt cuộc, tên doanh nghiệp không phải là duy nhất trên toàn quốc. Giả sử bạn giao dịch với hai doanh nghiệp tên Smith Electronics, một ở Kansas và một ở Michigan. Bạn có thể phân biệt chúng theo địa chỉ, nhưng điều đó sẽ thay đổi. Ngay cả nhà nước cũng có thể thay đổi; Điều gì xảy ra nếu Smith Electronics ở Kansas City, Kansas di chuyển qua sông đến Thành phố Kansas, Missouri? Không có cách rõ ràng nào để giữ cho các doanh nghiệp này khác biệt với thông tin khóa tự nhiên, vì vậy khóa thay thế là rất hữu ích.

Hãy nghĩ về khóa thay thế giống như một số ISBN. Thông thường, bạn xác định một cuốn sách theo tiêu đề và tác giả. Tuy nhiên, tôi đã có hai cuốn sách có tựa đề "Trân Châu Cảng" của HP Willmott và chúng chắc chắn là những cuốn sách khác nhau, không chỉ là các phiên bản khác nhau. Trong trường hợp như vậy, tôi có thể đề cập đến vẻ ngoài của những cuốn sách, hoặc sớm hơn so với sau này, nhưng tôi cũng có thể sử dụng lại số ISBN.

Xin nhắc lại, không nên đặt các chỉ số được nhóm trên các khóa thay thế ngẫu nhiên, ví dụ như GUID đọc XY8D7-DFD8S, vì SQL Server không có khả năng sắp xếp vật lý các dữ liệu này. Thay vào đó, bạn nên đặt các chỉ mục duy nhất trên các dữ liệu này, mặc dù cũng có thể có ích khi chỉ cần chạy trình lược tả SQL cho các hoạt động của bảng chính và sau đó đặt các dữ liệu đó vào Trình cố vấn điều chỉnh công cụ cơ sở dữ liệu.

Xem chủ đề @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cb13129be

Trường hợp 1: Bảng của bạn là bảng tra cứu có ít hơn 50 loại (chèn)

Sử dụng khóa kinh doanh / tự nhiên . Ví dụ:

Table: JOB with 50 inserts
CODE (primary key)       NAME               DESCRIPTION
PRG                      PROGRAMMER         A programmer is writing code
MNG                      MANAGER            A manager is doing whatever
CLN                      CLEANER            A cleaner cleans
...............
joined with
Table: PEOPLE with 100000 inserts

foreign key JOBCODE in table PEOPLE
looks at
primary key CODE in table JOB

Trường hợp 2: Bảng của bạn là một bảng có hàng ngàn chèn

Sử dụng các phím thay thế / tự động . Ví dụ:

Table: ASSIGNMENT with 1000000 inserts
joined with
Table: PEOPLE with 100000 inserts

foreign key PEOPLEID in table ASSIGNMENT
looks at
primary key ID in table PEOPLE (autoincrement)

Trong trường hợp đầu tiên:

• Bạn có thể chọn tất cả các lập trình viên trong bảng NHÂN DÂN mà không cần sử dụng phép nối với bảng JOB, nhưng chỉ với: "CHỌN * TỪ NHÂN DÂN WHERE JOBCODE = 'PRG'"

Trong trường hợp thứ hai:

• Truy vấn cơ sở dữ liệu của bạn nhanh hơn vì khóa chính của bạn là một số nguyên
• Bạn không cần bận tâm đến việc tìm khóa duy nhất tiếp theo vì chính cơ sở dữ liệu sẽ cung cấp cho bạn sự tự động tiếp theo.

Đây là một trong những trường hợp khóa thay thế khá nhiều luôn có ý nghĩa. Có những trường hợp bạn chọn cái gì tốt nhất cho cơ sở dữ liệu hoặc cái gì tốt nhất cho mô hình đối tượng của bạn, nhưng trong cả hai trường hợp, sử dụng khóa vô nghĩa hoặc GUID là một ý tưởng tốt hơn. Nó làm cho việc lập chỉ mục dễ dàng hơn và nhanh hơn và đó là một danh tính cho đối tượng của bạn không thay đổi.

Ngựa cho các khóa học. Để nói rõ sự thiên vị của tôi; Trước tiên tôi là nhà phát triển, vì vậy tôi chủ yếu quan tâm đến việc cung cấp cho người dùng một ứng dụng hoạt động.

Tôi đã làm việc trên các hệ thống có khóa tự nhiên và phải mất nhiều thời gian để đảm bảo rằng các thay đổi giá trị sẽ gợn qua.

Tôi đã làm việc trên các hệ thống chỉ có các khóa thay thế và nhược điểm duy nhất là thiếu dữ liệu không chuẩn hóa để phân vùng.

Hầu hết các nhà phát triển PL / SQL truyền thống mà tôi đã làm việc không thích khóa thay thế vì số lượng bảng trên mỗi lần tham gia, nhưng cơ sở dữ liệu thử nghiệm và sản xuất của chúng tôi không bao giờ đổ mồ hôi; các kết nối thêm không ảnh hưởng đến hiệu suất ứng dụng. Với các phương ngữ cơ sở dữ liệu không hỗ trợ các mệnh đề như "X bên trong tham gia Y trên Xa = Yb" hoặc các nhà phát triển không sử dụng cú pháp đó, các phép nối thêm cho các khóa thay thế làm cho các truy vấn khó đọc hơn và lâu hơn để nhập và kiểm tra: xem bài đăng @Tony Andrew. Nhưng nếu bạn sử dụng ORM hoặc bất kỳ khung công tác tạo SQL nào khác, bạn sẽ không nhận thấy nó. Gõ cảm ứng cũng giảm nhẹ.

Có thể không hoàn toàn liên quan đến chủ đề này, nhưng tôi đau đầu với các khóa thay thế. Các phân tích được phân phối trước của Oracle tạo ra các SK được tạo tự động trên tất cả các bảng kích thước của nó trong kho và nó cũng lưu trữ các phân tích trên thực tế. Vì vậy, bất cứ khi nào chúng (kích thước) cần được tải lại khi các cột mới được thêm vào hoặc cần được điền cho tất cả các mục trong thứ nguyên, các SK được chỉ định trong quá trình cập nhật làm cho các SK không đồng bộ với các giá trị ban đầu được lưu trữ trên thực tế, buộc tải lại hoàn toàn tất cả các bảng thực tế tham gia vào nó. Tôi muốn rằng ngay cả khi SK là một con số vô nghĩa, sẽ có một số cách mà nó không thể thay đổi cho các hồ sơ gốc / cũ. Như nhiều người biết, ngoài luồng hiếm khi phục vụ nhu cầu của tổ chức và chúng tôi phải tùy chỉnh liên tục. Chúng tôi hiện có 3yrs dữ liệu trong kho của chúng tôi, và tải lại hoàn toàn từ các hệ thống tài chính của Oracle là rất lớn. Vì vậy, trong trường hợp của tôi, chúng không được tạo từ mục nhập dữ liệu, mà được thêm vào một kho để giúp báo cáo hiệu suất. Tôi hiểu rồi, nhưng chúng ta thay đổi, và đó là một cơn ác mộng.

Trong trường hợp cơ sở dữ liệu thời gian, tốt nhất nên có sự kết hợp của khóa thay thế và khóa tự nhiên. ví dụ: bạn cần theo dõi thông tin thành viên cho một câu lạc bộ. Một số thuộc tính của một thành viên không bao giờ thay đổi. ví dụ: Ngày sinh nhưng tên có thể thay đổi. Vì vậy, hãy tạo một bảng Thành viên với khóa thay thế thành viên_id và có một cột cho DOB. Tạo một bảng khác được gọi tên người và có các cột cho thành viên_id, thành viên_fname, thành viên_lname, date_updated. Trong bảng này, khóa tự nhiên sẽ là Member_id + date_updated.