kích thước trường quá mức trong thiết kế cơ sở dữ liệu


11

Tôi có một số trường cho các bảng của mình là các chuỗi và hiện tại, hầu hết kích thước trường có giới hạn ký tự khá cao. Ví dụ: 100 char cho tên đường phố. Có một hình phạt cho việc sử dụng kích thước trường lớn? Nếu tôi thay đổi giới hạn thành 30 char cho trường này chẳng hạn, liệu sẽ có hiệu suất tăng hay hiệu quả với kích thước? Sẽ có khoảng 50 lĩnh vực có thể là ứng cử viên cho thu hẹp.

Cảm ơn lời đề nghị của bạn.


Đối với char, không gian luôn được sử dụng trong cơ sở dữ liệu, nhưng đối với varchar, trong khi hình phạt sẽ ít hơn, cần phải có không gian lớn hơn được đặt sang một bên trong các hoạt động mà bạn thực sự cần vẫn có thể làm cho nó kém hiệu quả hơn một chút. Tôi sẽ không lo lắng về các cột varchar trừ khi chúng rất lớn - như luôn luôn sử dụng varchar (max) hoặc varchar (1000).
Cade Roux

Bạn nên chú ý đến việc vượt quá kích thước của một trang (8k) vì nó sẽ ảnh hưởng đến hiệu suất. Kiểm tra bài đăng này: stackoverflow.com/questions/2518922/ Ấn

Với chi phí thấp của ổ đĩa cứng, tôi không lo lắng về hiệu quả lưu trữ trong những ngày này. Như JNK nói, có một tác động đến việc lập chỉ mục cho các lĩnh vực rất lớn - điều đó chắc chắn đáng để lưu tâm. Nỗi đau của việc thay đổi một ứng dụng vì bạn đã phân bổ quá ít không gian lớn hơn nhiều so với chi phí của một vài byte bổ sung trong bảng cơ sở dữ liệu của bạn.
Neville Kuyt

3
Tôi nghĩ bỏ qua lưu trữ vì nó rẻ là một ý tưởng tồi. Mỗi byte trên đĩa cần phải được tìm nạp và xử lý, và phần chậm nhất trong hầu hết mọi cài đặt SQL Server là bộ lưu trữ đĩa. Ít byte hơn = truy vấn nhanh hơn.
JNK

1
Nếu 100 MB khiến dữ liệu ít hơn 20% phù hợp với bộ đệm của bộ điều khiển đĩa 512 MB, điều đó hoàn toàn quan trọng (tiếng nói của kinh nghiệm).
Eric J.

Câu trả lời:


16

Nếu bạn đang nói về varcharnvarcharsau đó thì không, sẽ không bị phạt nếu cho phép độ dài trường cao hơn.


Một số hãy cẩn thận, mặc dù:

  • Có 2 byte trên mỗi hàng cho các trường có chiều dài thay đổi (mỗi trường). Nếu bạn có một trường rất ngắn, nó có thể có ý nghĩa hơn để sử dụng a CHAR. Varchar(2)ví dụ thực sự sử dụng từ 2-4 byte mỗi hàng, trong khi CHAR(2)luôn sử dụng 2.
  • Các trường rất dài không thể được lập chỉ mục. Độ dài tối đa cho tất cả các trường trong bộ khóa chỉ mục là 900 byte.
  • Nếu bạn cho phép nhiều dữ liệu hơn bạn mong đợi, cuối cùng bạn sẽ nhận được kết quả không mong muốn. Nếu bạn cho phép 100 ký tự cho một tên phố, tại một số điểm, dữ liệu khác có thể vào trường đó mà bạn không biết về nó (ví dụ như toàn bộ địa chỉ). Nếu bạn có kích thước phù hợp, bạn có thể sẽ gặp lỗi khi chèn.
  • Cho phép các hàng rất rộng có thể dẫn đến phân chia trang và phân mảnh. Nếu bạn có một hàng dài hơn 8k, nó sẽ cần được chia thành nhiều trang dữ liệu. Rất nhiều trong số này thực sự có thể làm tổn thương hiệu suất. Nói chung là hiệu quả hơn.

1
Bạn cũng có thể thêm cảnh báo để rút ngắn câu trả lời này, ví dụ: đảm bảo rằng cột đó ít nhất đủ lớn: địa chỉ varchar (30) không thể đối phó với Bolderwood Arboretum Or Cảnh Drive hoặc Khu công nghiệp Đông Bắc Kentucky .

@Aleksi - rất đúng. Tuy nhiên, tôi nghĩ đó là những điều rõ ràng hơn, đó là lý do tại sao OP đang sử dụng các lĩnh vực rộng để bắt đầu.
JNK

"Tại một số điểm, dữ liệu khác có khả năng xâm nhập vào lĩnh vực đó mà bạn không biết về nó" Một điểm thú vị. Tôi đã thấy rất nhiều hệ thống trong đó người dùng lấy bất kỳ trường nào không áp dụng cho hồ sơ hiện tại làm trường nhận xét cho mục đích chung.


2

Nếu bạn muốn nói, "Có hình phạt nào khi khai báo kích thước trường lớn hơn bất kỳ giá trị nào thực sự được lưu trữ trong đó không?", Thì miễn là nó được khai báo varchar, câu trả lời là không. Mỗi công cụ SQL DB mà tôi biết chỉ lưu trữ số lượng ký tự thực sự được cung cấp trong dữ liệu (cộng với giá trị độ dài). Vì vậy, nếu bạn xác định trường là varchar (100) nhưng chỉ lưu trữ 10 ký tự trong đó, thì nó sẽ chỉ chiếm 10 ký tự trên đĩa (cộng thêm 2 byte hoặc hơn cho chiều dài). Khi nghi ngờ, tôi thường xuyên làm cho các trường varchar của tôi lớn một cách lố bịch.

Nếu bạn muốn nói, "Có bị phạt khi lưu trữ các trường ký tự dài không", câu trả lời là có. Dung lượng đĩa ngày nay rẻ, nhưng nó không miễn phí, vì vậy bạn không muốn lãng phí nó mà không có lý do. Có lẽ quan trọng hơn, cần có thời gian để đọc dữ liệu ra khỏi đĩa, vì vậy các trường dữ liệu của bạn càng dài thì chương trình càng chậm. Nếu trường được lập chỉ mục, điều này thực sự có thể làm chậm quá trình truy xuất của bạn, vì mỗi lần đọc sẽ phải so sánh giá trị khóa với trường dài lớn này.

Hãy nhớ rằng nếu bạn cung cấp cho người dùng một trường nhập dữ liệu lớn, họ sẽ sử dụng nó, sớm hay muộn.

Tất cả những gì đã nói, tôi sai ở phía quá lớn thay vì quá nhỏ. Dung lượng ổ đĩa đủ rẻ để bạn không muốn buộc người dùng phát minh ra các chữ viết tắt một cách nhanh chóng vì chúng không thể vừa với dữ liệu thực vào trường có sẵn. Hệ thống tôi đang làm việc hôm nay có trường mô tả sản phẩm quá nhỏ so với nhiều tên thật của sản phẩm, vì vậy người dùng phải viết tắt. Và tất nhiên mỗi người dùng viết tắt khác nhau, vì vậy chúng tôi có hai mươi cách khác nhau để nói cùng một điều.


2

Bất cứ ai tuyên bố rằng không có hình phạt nào khi tuyên bố kích thước trường lớn hơn những gì thực sự sẽ được lưu trữ trong bảng là không chính xác. Kích thước thực của dữ liệu (cộng với 2 byte trên không) là những gì thực sự được lưu trữ, nhưng đó là định nghĩa cột được sử dụng để xác định ước tính cho đến khi kế hoạch thực hiện đi. Vì vậy, trong khi khai báo varchar (1000) để lưu trữ giá trị 10 ký tự sẽ chỉ ăn hết 12 ký tự không gian đĩa, ước tính kế hoạch thực hiện sẽ kém hiệu quả hơn và làm lệch kết quả, cho cả bộ nhớ để cấp cho hoạt động và hoạt động có thể được thực hiện chỉ trong bộ nhớ hay không hoặc nó cũng sẽ yêu cầu dung lượng ổ đĩa tempdb. Bạn có thể tạo cột varchar (1000), nhưng công cụ không biết rằng tất cả các giá trị được lưu trữ của bạn thực sự nhỏ hơn varchar (10),


0

Kiểm tra độ dài trường là thứ bạn nhận được 'miễn phí', nghĩa là bạn không phải sử dụng một CHECKràng buộc để làm điều tương tự. Và bạn không muốn các giá trị dữ liệu quá khổ khi, ví dụ, khi bạn phải tải dữ liệu của mình lên một cơ sở dữ liệu khác đã giới hạn cùng một yếu tố dữ liệu ở 35 ký tự phù hợp với địa chỉ tiêu chuẩn quốc tế.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.