Máy chủ SQL - Hiệu suất/Kích thước Nhược điểm của các Cột Null

Question

Tôi đang làm việc trên một thiết kế bảng có thể liên quan đến nhiều giá trị NULL trong khoảng 10 trường có thể 75% thời gian các trường sẽ không được sử dụng.

Tôi vừa tạo một số dữ liệu giả (một triệu bản ghi) và không thể cảm nhận được bất kỳ tác động nào lên SQL Server 2005. Sự khác biệt về kích thước nằm trong KB. Hiệu suất - không có sự khác biệt có thể đo lường được sau khi thêm chỉ mục vào 3 cột không có giá trị.

Tôi biết SQL Server 2008 có tính năng cột thưa thớt (mà tôi giả định sẽ được sử dụng trên bảng UserData của SharePoint tiếp theo). Tôi muốn mã của tôi để làm việc trên 2005 mặc dù. Nhưng nhiều giá trị NULL tồn tại trong thiết kế bảng SharePoint UserData hiện tại. Vì vậy, nếu nó đủ tốt cho Microsoft ...

Bất kỳ bài viết hay, liên kết, giấy trắng trên mặt hạn chế hoặc điểm đau xung quanh nhiều giá trị NULL trong bảng SQL Server? Bất cứ ai có bất kỳ kinh nghiệm về những gì sẽ xảy ra khi bạn quy mô đến 10 triệu hoặc 100 triệu hồ sơ?

Answer 1

Tôi chưa bao giờ gặp sự cố với hiệu suất trên nhiều cột trống, ngay cả trên cơ sở dữ liệu trong 100 giây kích thước biểu diễn. Tôi tưởng tượng bạn có thể kết thúc với các vấn đề nếu bạn đang chạy các chỉ mục trên các trường này và sau đó sử dụng null trong truy vấn, nhưng tôi đã không thấy vấn đề này là một vấn đề cá nhân. Sau đó, một lần nữa, tôi đã không tạo ra các bảng cơ sở dữ liệu trong đó mỗi trường ngoại trừ 3 là vô giá trị.

Mặt khác, tôi thấy một vấn đề kiến ​​trúc khi phần lớn dữ liệu là rỗng. lý do chung là a) một cơ sở dữ liệu chuẩn hóa không đúng hoặc b) một nỗ lực để cho phép người dùng dữ liệu giai đoạn trong bảng kết thúc thay vì tạo các bảng riêng biệt để "xây dựng" dữ liệu trước khi cam kết với cơ sở dữ liệu.

Bạn có thể xác định kiến ​​trúc tốt nhất của cơ sở dữ liệu của mình.

Answer 2

Không tạo bảng với 75% cột không sử dụng. Làm cho nó với các cột của bạn sẽ sử dụng tất cả các thời gian và nhìn vào sử dụng một cái gì đó như EAV cho các cột khác, hoặc đặt chúng trong một bảng khác nhau.

Answer 3

Các vấn đề tôi đã có trong thỏa thuận trước đây với các tác động lập trình có giá trị NULL. Ví dụ các vấn đề với khách hàng, hoặc các vấn đề không có trong các truy vấn trả về dữ liệu khi không được mong đợi vì một giá trị null nằm trong đó.

Answer 4

Vâng, NULL luôn là một chút kỳ quặc trong cơ sở dữ liệu. Tôi không nghĩ rằng nó có quá nhiều tác động về hiệu suất trong trường hợp của bạn - nhưng tất nhiên, bạn sẽ phải xử lý tất cả các giá trị NULL một cách riêng biệt.

Bất cứ khi nào có thể, tôi cố gắng sử dụng giá trị mặc định thay thế, vì vậy nếu bạn có, ví dụ: một số giá trị ID của loại INT, bạn có thể sử dụng 0 hoặc -1 làm chỉ báo "không có giá trị hiện tại". Bằng cách đó, bạn có thể tránh phải kiểm tra giá trị (trường < 0) và kiểm tra NULL riêng biệt (trường IS NULL hoặc IS NOT NULL).

Marc

Answer 5

Chỉ có một cách để đảm bảo. Tiếp tục và chèn 100 triệu bản ghi rồi đo hiệu suất từ ​​đầu đến cuối.

Answer 6

Những gì tôi làm trong tình huống này, đó là rất phổ biến, là để phân chia các dữ liệu thành hai bảng:

• Yêu cầu dữ liệu
• Tùy chọn dữ liệu

Ví dụ, tôi m hiện đang viết một trang web cộng đồng và một trong các bảng rõ ràng sẽ là một bảng người dùng. Tôi đang thu âm một số lượng lớn các thông tin về người dùng và vì vậy tôi đã chia dữ liệu tôi thu thập vào hai bảng:

• Người dùng
• UserDetails

Các Người dùng bảng chứa các thông tin cơ bản mà tôi sẽ cần tất cả thời gian như Tên người dùng, Tên và Thông tin phiên.

Bảng UserDetails chứa thông tin bổ sung mà tôi không cần thường xuyên như Trang tiểu sử, Địa chỉ email, Mật khẩu, Địa chỉ trang web, Ngày sinh vv.

Điều này được gọi là vertical partitioning.

Answer 7

Xác suất cao hơn của NULL trong cột, càng gần đến cuối bản ghi cột phải ở trong bảng (đến cột cột trong bảng).
Các NULLS ở cuối hàng không được phân bổ bất kỳ không gian, chúng được xác định bởi NULL BITMAP liên kết với mỗi bản ghi (nó là 2 byte, mỗi bit trong số đó nói về (không) NULL-ness của một trong các giá trị cột trong hồ sơ).

Bây giờ, giá trị NULL không được đọc từ cột, chúng được đọc từ bitmap NULL. Khi NULL được phát hiện việc đọc giá trị thực được bỏ qua

Tính năng thưa thớt nên được sử dụng với cảnh báo vì nó gọi overhead trong thời gian và không gian cho các giá trị khác null Để đạt hiệu quả, bạn có thể tham gia vào filtered indexing on non-null part of a column