Đây có phải là một cách tiêu chuẩn để thiết kế cơ sở dữ liệu?

Gần đây tôi đã biết về cách các mối quan hệ được xác định trong cơ sở dữ liệu tại nơi làm việc và tự hỏi liệu đây có phải là một thông lệ tiêu chuẩn.

Giả sử chúng ta có hai quy trình: Quy trình A và Quy trình B. Quy trình B phụ thuộc vào kết quả từ Quy trình A, do đó, có một mối quan hệ cần được xác định giữa quy trình B chạy và quy trình A. Đây là cách mối quan hệ được xác định:

TableProcessA:
Id

và

TableProcessB:
Id
ProcessAId

Bây giờ, cho đến thời điểm này, mọi thứ có ý nghĩa với tôi, nhưng sau đó mọi thứ trở nên hơi lạ đối với tôi và sự hiểu biết của tôi về thiết kế bảng. Bất cứ khi nào một hàng được tạo trong TableProcessA hoặc TableProcessB, một hàm được gọi sẽ tạo ra một id duy nhất toàn cầu cho mỗi. Về cơ bản, tất cả các trường Id trong TableProcessA và TableProcessB sẽ không chứa bất kỳ kết quả khớp nào vì Id không chỉ là duy nhất cho bảng của nó, mà cho toàn bộ cơ sở dữ liệu.

Câu hỏi của tôi là, tiêu chuẩn này như thế nào? Tôi đã đưa ra ý tưởng rằng mỗi bảng chỉ cần có một id tự động tăng tốc duy nhất chỉ cho bảng chứ không phải toàn bộ cơ sở dữ liệu.

Đây không phải là một thực tế kỳ lạ. Chúng được gọi là GUID hoặc ID duy nhất toàn cầu. Ý tưởng là, được đưa ra một GUID, bạn có thể cho biết chính xác phần dữ liệu mà id thuộc về vì nó sẽ là duy nhất ở mọi nơi . GUID được sử dụng tốt nhất khi bạn sẽ hợp nhất các nguồn dữ liệu tương tự khác nhau; ví dụ hàng tồn kho cho các cửa hàng khác nhau.

Tôi sẽ làm một số nghiên cứu và tìm hiểu tại sao đây là một thực tế phổ biến trong môi trường của bạn. Có lẽ nó cần thiết, có thể là không.

Về nguyên tắc, việc có các Id duy nhất trên cơ sở dữ liệu không quá tệ nhưng theo kinh nghiệm của tôi thì nó khá bất thường. Trừ khi có một yêu cầu cụ thể để duy trì các khóa Id duy nhất trên toàn cầu, sử dụng danh tính bình thường sẽ ổn vì các loại thực thể hoặc đối tượng có xu hướng cụ thể và thường không dẫn đến bất kỳ phép nối nào không phù hợp.

Bên cạnh câu hỏi của bạn, tôi thực sự khuyên bạn không nên sử dụng GUID làm khóa chính hoặc thay thế vì nó chiếm gấp 4 lần dung lượng của một int. Bây giờ trong thời của nhiều đĩa gigabyte, bạn có thể nói nó không quan trọng nhưng khi bạn có vài triệu hàng dữ liệu, nó vẫn cần tài nguyên để đọc từ đĩa hoặc truyền qua mạng, thậm chí nhiều hơn nếu chúng được đưa vào bất kỳ chỉ mục nào. Mặc dù tôi thuộc các chỉ mục chủ đề, GUID rất tệ trong các khóa chính do có tính chất ngẫu nhiên và thường gây ra sự phân mảnh đáng kể.

Bây giờ có lẽ đã quá muộn cho cơ sở dữ liệu này nhưng hãy ghi nhớ nó cho tương lai

Các quy trình của bạn có thể tạo các bản ghi chứa GUID làm tham chiếu đến thể hiện quy trình, nhưng sử dụng GUID làm khóa không nhất thiết phải là tối ưu.

Tôi thấy ba nhược điểm chính của việc sử dụng GUID làm khóa cơ sở dữ liệu và sẽ tránh chúng trừ khi bạn có một số lý do thuyết phục để sử dụng chúng. Lưu ý rằng thuộc tính duy nhất trên toàn cầu không mang lại cho bạn bất kỳ lợi thế nào khi sử dụng khóa duy nhất cục bộ trong một bảng, bởi vì bạn đã biết dữ liệu đến từ bảng nào.

Sự bất tiện: Chẳng hạn, việc nhập GUID không dễ dàng lắm nếu bạn muốn thực hiện một truy vấn đặc biệt của cơ sở dữ liệu, ví dụ:

select *
  from Foo
 where FooID = 12345

đấu với

select *
  from Foo
 where FooID = convert (uniqueidentifier, '5E64E653-35F0-4803-B459-F5F59C701F22')

Cái sau thực tế có nghĩa là bạn cần một nguồn GUID để cắt và dán từ đó.

2. Quy tắc tự nhiên: Khóa chính tự động tăng lên có tác dụng phụ là tự nhiên sắp xếp các giao dịch của bạn theo thứ tự chúng được nhập vào hệ thống. Điều này thường khá hữu ích. GUID thường không được tạo theo thứ tự, vì vậy chúng không được sử dụng trong vấn đề này.

3. Kích thước: Ít vấn đề hơn những ngày này, nhưng GUID dài 16 byte. Nó chiếm nhiều không gian hơn trong bảng và bất kỳ chỉ mục nào bao gồm nó.

Tôi sẽ không nói rằng đó là bình thường, nhưng cũng không bình thường khi thiết lập mọi thứ theo cách này.