Tùy chọn thiết kế bảng cho số hàng lớn?

Question

Tôi có một ứng dụng gửi dữ liệu dựa trên tương tác của người dùng (không phải đầu vào của người dùng). Dữ liệu được gửi có thể là một giá trị Integer, String, Date hoặc Boolean. Có 140 phím. Chúng tôi có thể nhận được bất cứ nơi nào từ 1 cặp giá trị khóa đến tất cả 140 tại một thời điểm.

Chúng tôi muốn lưu trữ mọi thứ nhưng sẽ chỉ sử dụng 20 trong số 140 khóa trong ứng dụng. Số còn lại sẽ được sử dụng cho đường mòn kiểm tra sau này - vì vậy chúng tôi vẫn cần lưu trữ chúng.

Dữ liệu này được ứng dụng sử dụng để quyết định nơi người dùng cần truy cập để cần truy cập hồ sơ theo id sinh viên và kéo 20 hoặc hơn tùy chọn trong vòng mili giây. Có thể có hàng tỷ hàng dữ liệu (nó là bản nâng cấp cho một ứng dụng hiện có với hơn 20.000 người dùng) nên hiệu suất là rất quan trọng. Người dùng tạo một hàng mới mỗi khi họ truy cập vào ứng dụng.

VÍ DỤ DỮ LIỆU:

Score:1 
ID:3212 
IsLast:False 
Action:Completed 

Tôi có 2 ý tưởng về làm thế nào để làm điều này và tìm kiếm một số giúp đỡ trên đó là tốt nhất hoặc là một lựa chọn thứ ba là một lựa chọn tốt hơn.

OPTION 1:

ý tưởng đầu tiên của tôi là sử dụng một cột cho giá trị như là một chuỗi sau đó có một nhìn lên bảng các loại dữ liệu có thể sử dụng khi giá trị cần được đúc sử dụng.

value  | dataType 
----------------------- 
"1"   | int 
"Completed" | string 

Trong khi dữ liệu được gửi không phải do người dùng tạo, tôi biết có một dấu hiệu xác định ở đâu đó trong phương pháp này. Lý do duy nhất để làm điều này là chúng tôi không biết khóa nào: cặp sẽ được gửi (ngoài ngày và id) và cố gắng tránh nhiều hơn một vài cột.

Câu hỏi SO How to Handle Unknown Data Type in one Table sử dụng ý tưởng tương tự.

OPTION 2:

Các giải pháp khác là phải có 140 cột - một cho mỗi phím. Tuy nhiên, lượng dữ liệu được tạo ra là rất lớn (hàng tỷ hàng) để gọi dữ liệu này sẽ không đủ nhanh - tôi không nghĩ vậy.

Chi tiết kỹ thuật: Điều này đang sử dụng SQL Server 2008 - không phải R2 với DotNet C# và Dịch vụ báo cáo.

Tôi có thiếu thứ gì đó ở đây không - cách tốt nhất để tạo bảng này cho hiệu suất là gì?

Answer 1

Phân đoạn theo chiều dọc dữ liệu của bạn. Đặt 20 phím cần thiết cho điều khiển điều hướng trong một bảng, tất cả 20 trong một hàng, với PK xác định tương tác của người dùng (Callit say, InteractionId). Đặt 120 giá trị khác trong một bảng khác, với khóa chính hỗn hợp, dựa trên PK của bảng đầu tiên (InteractionId, cộng với số KeyTypeId xác định giá trị nào trong số 120 cặp giá trị khóa có thể có giá trị đó. Lưu trữ tất cả các giá trị trong bảng thứ hai này Trong bảng tìm kiếm thứ ba có tên là KeyTypes, hãy lưu KeyTypeId, KeyTypeName và KeyValueDataType để cho phép mã của bạn biết cách truyền giá trị chuỗi để xuất ra đúng như chuỗi, ngày giờ, số nguyên hoặc giá trị thập phân hoặc bất cứ điều gì ...

Bảng đầu tiên sẽ được truy cập thường xuyên hơn và chỉ chứa các giá trị mà chức năng điều hướng của ứng dụng cần truy cập thường xuyên hơn, giữ cho các hàng hẹp hơn, cho phép nhiều hàng hơn trên mỗi trang và giảm thiểu IO đĩa. Đặt tất cả 20 giá trị trong một hàng sẽ giữ cho hàng đếm nhỏ hơn (~ 1/20 là lớn), giảm thiểu độ sâu của chỉ mục tìm kiếm sẽ cần phải được thực hiện cho mỗi lần truy cập.

Bảng khác với tất cả 120 khóa-giá trị khác sẽ không được truy cập thường xuyên, vì vậy cấu trúc của nó có thể được tối ưu hóa cho sự đơn giản hợp lý hơn là cho hiệu suất.

Answer 2

Cũng cần đủ đơn giản để kiểm tra cả hai ý tưởng, nhưng một biến thể về tùy chọn 1 có vẻ phù hợp với tôi. Các RDBMS như SQL Server thích các bảng dài, hẹp (tức là ít cột hơn nhưng có nhiều hàng).

Tôi sẽ không đi thêm nữa bởi vì nó xuất hiện Charles đã đánh bại nó, với một gợi ý hoàn toàn hợp lý.

Answer 3

Trên thực tế, bạn có thể hợp nhất những đề nghị cung cấp cho đến nay:

Tạo một bảng với 20 phím cần thiết để kiểm soát hàng hải, cộng thêm một cột cho một Primary Key, cộng với một cột đó là một kiểu dữ liệu XML để lưu trữ phần còn lại của dữ liệu có thể. Sau đó bạn có thể tạo một DTD xử lý các kiểu dữ liệu cho mỗi khóa, cộng với các ràng buộc trên các khóa nhất định khi cần thiết.