Là một khóa chính 5+ cột có hại cho bảng lớn (100 triệu +) không?

Tôi đã đọc về một số vấn đề DB ngoài đời thực và một dự án có một hàng 100 triệu hàng cộng với 5 cột là chính. Tôi nghĩ điều này là xấu, nhưng ai đó có thể cho tôi biết chính xác tại sao không?

Bảng này là một loại bảng tổng hợp / tổng hợp vi mô, vì vậy 5 cột giống như (ngày, market_id, sản phẩm_id ...). Lúc đầu, tôi nghĩ rằng khóa chính 5 cột không lý tưởng, nhưng càng nghĩ, tôi thực sự không thể đưa ra lý do chính đáng tại sao nó lại tệ.

Đây là trong một cuộc thảo luận đêm khuya với một nửa các kỹ sư của công ty. Có người chỉ đề cập đây là một thiết kế tồi, một kỹ sư cao cấp đã đồng ý, nhưng không ai thực sự nhảy vào lý do tại sao. Do đó cố gắng nghiên cứu vấn đề cho bản thân mình!

Có vấn đề về hiệu năng với các khóa chính rất phức tạp. Và nó có thể không bảo vệ chống lại sự trùng lặp cũng như một khóa chính đơn giản hơn có thể.

Tuy nhiên, có một mẫu thiết kế thường xuyên tạo ra các bảng với khóa chính được tạo thành từ sáu thành phần. Đó là bảng thực tế lược đồ sao. Nếu bảng thực tế của lược đồ sao có sáu chiều, thì khóa chính sẽ có sáu thành phần. Tôi chưa bao giờ thấy một bảng thực tế không có khóa chính được khai báo và tôi nghĩ rằng nó cũng đáng để chi phí, mặc dù quy trình ETL vẫn phải được viết khá cẩn thận.

Một số cơ sở dữ liệu báo cáo bắt chước mô hình lược đồ sao ngay cả khi nó không được thiết kế rõ ràng theo cách đó.

100 triệu + hàng không quá lớn đối với một bảng thực tế, đặc biệt là với dữ liệu lớn ngày nay.

Bảng trong câu hỏi là một bảng tổng hợp / tổng hợp.

Sau đó, nó không chỉ tốt, nó là "đúng".

Và nó có mùi giống như một bảng Tóm tắt, vì nó bắt đầu bằng day.

Bạn có một số chỉ số phụ? Hãy nhớ rằng nếu bạn đang sử dụng InnoDB, phần còn lại của các cột CHÍNH HÃNG sẽ được xử lý vào cuối chỉ mục phụ. Một lần nữa, đây không hẳn là một vấn đề.

100M hàng là rất nhiều cho một rollup. Nghe có vẻ như bảng quá mịn. Đó là, có lẽ thay vì nếu (ngày, a, b, c, d) bạn nên có 4 lần triển khai với các PK như (ngày, a, b, c), (ngày, b, c, d), (ngày, c, d, a), (ngày, d, a, b) (hoặc một số kết hợp phù hợp). Tôi làm điều đó, mỗi hàng có thể chỉ có 10 triệu hàng, do đó làm cho các báo cáo vẫn nhanh hơn, trong khi có độ linh hoạt gần như trong báo cáo.

Hoặc có thể chuyển sang (tuần, a, b, c, d), dẫn đến có thể chỉ có 14M hàng. (Có lẽ nhiều hơn.)

Sử dụng PHẦN THAM GIA để tạo điều kiện cho việc cắt tỉa --- Nhập tốc độ cao --- Mẹo kho dữ liệu --- Bảng tóm tắt . Chúng tóm tắt nhiều kỹ thuật tôi đã phát triển trong một số dự án DW. Như bạn có thể suy ra, mỗi dự án là khác nhau. Số lượng Bảng tóm tắt 'điển hình' (theo kinh nghiệm của tôi) là 3 - 7. Mục tiêu trong tóm tắt là 10 hàng Fact -> 1 hàng Tóm tắt. (Đó có thể là một 'trung vị'.) Trong một trường hợp hiếm hoi, tôi đã tóm tắt một bảng Tóm tắt. Trong một trường hợp hiếm hoi khác, tôi đã THAM GIA một bảng Tóm tắt để có hiệu quả tốt; thông thường các bảng Tóm tắt đủ nhỏ để chúng đủ nhanh để truy cập trực tiếp từ UI.

Chà, thực sự có một PK với hơn 5 cột không hẳn là xấu.

Nó trở nên tồi tệ khi PK cũng là chỉ mục được nhóm vì người ta sẽ tính là định danh hàng và do đó sẽ được thêm vào mỗi hàng trong chỉ mục NC. Điều này sẽ làm tăng đáng kể không gian cần thiết.

Nó cũng sẽ tệ khi bạn thực sự sử dụng PK bởi một FK khác, vì bạn phải có dữ liệu của tất cả 5+ cột trong cả bảng hiện tại cũng như một tham chiếu từ đó. Một lần nữa nó sẽ tăng dung lượng lên rất nhiều!

Hiệu suất thông minh sẽ rất tệ khi PK được sử dụng làm chỉ mục - hãy để nó ở trong bảng hoặc kết hợp với FK - vì PK-Key lớn hơn chứa 5+ cột sẽ chiếm nhiều không gian hơn, do đó sẽ có ít mục hơn phù hợp trong một trang và từ đó cần đọc nhiều trang hơn để phân tích chỉ mục.

Điều đó nói rằng - có thể luôn luôn có một lý do tốt để thực sự làm như vậy dù sao, ví dụ như một bảng thực tế. Do đó, câu trả lời tốt nhất sẽ thực sự giống như trong hầu hết các trường hợp: Nó phụ thuộc!

Trân trọng Dennis

Trong hơn 15 năm qua tôi không cần chìa khóa như vậy, đôi khi nhìn thấy nó và nó chỉ gây rắc rối. Rất nhiều rắc rối. Trước hết, khóa chính là để giữ tính toàn vẹn dữ liệu và chúng phải được tổng hợp. Họ không nên có bất kỳ ràng buộc với thế giới thực. Tại sao ? Khi thế giới thực thay đổi, và chắc chắn, khóa chính của bạn sẽ biến mất và bạn phải cập nhật nó, và tất cả các thông tin liên quan.

Hãy tưởng tượng bạn cần nhớ ker này trong một số bảng / cơ sở dữ liệu / dịch vụ khác thay vì một trường bạn cần sao chép một số trường và bạn có thể quên sao chép một số trong số chúng. Thay vào đó, khóa chính sysntetic, chỉ là một phần dữ liệu, bạn phải cung cấp. Tôi không đề cập đến sự thống nhất của chỉ số, mà có thể bởi một chủ đề lớn khác để thảo luận.

Vì vậy, tóm tắt ngắn, khóa chính tổng hợp (tăng tự động, hướng dẫn, ..) là đơn giản để duy trì, sao chép, ...

Vì vậy, tôi xem xét, tổng hợp khóa chính và một khóa khác cho 5 cột bạn đã đề cập.

Cuối cùng, nếu bảng chỉ là tổng hợp và sẽ không bao giờ có ai đó cần tham chiếu hàng theo khóa (nhưng thế giới thay đổi, hãy tin tôi, ít nhất là đối với tôi nó sẽ thay đổi vĩnh viễn), tôi có thể sẽ để nó như vậy (chính khóa có năm hàng), nhưng trong trường hợp chúng ta đã từng có, nó luôn gây ra nhiều rắc rối. Vì vậy, tôi nói với bạn.