mysql có quá nhiều cột?

Question

Tôi đang tạo một bảng có 30-50 cột. Có khoảng 200 nghìn hàng. Có nên lưu trữ dữ liệu này trong các bảng riêng biệt không? Có vấn đề về hiệu suất khi bạn có nhiều cột này không.

Tôi sẽ giải thích một chút về bảng. Tôi phải lưu trữ tất cả các trò chơi thể thao trong 10 năm qua (bóng rổ, bóng chày, bóng đá, khúc côn cầu). Đối với mỗi trong số này, tôi cần phải giữ dữ liệu bổ sung. Một số dữ liệu này cho phép tôi sử dụng lại các trường trên các môn thể thao. Ví dụ, mỗi đội có một đội nhà và đội khách và một ngày sự kiện.

Tuy nhiên, đối với mỗi trò chơi trong số này, tôi cũng lưu trữ những thứ như số lần giảm đầu tiên, số lượng cảnh báo và ba con trỏ. Rõ ràng, dữ liệu này chỉ liên quan đến một số hàng trong bảng. Cuối cùng tôi có rất nhiều trường NULL trong mỗi hàng.

Tôi có thể cung cấp thêm chi tiết cụ thể nếu cần. Cảm ơn trước vì bất kỳ lời khuyên chung nào.

Answer 1

Để xây dựng trên câu trả lời RichardOD 's, bạn nói chung có ba tùy chọn khi giao dịch với phân loại phụ và bạn chọn tùy thuộc vào những gì bạn cần làm với dữ liệu được đề cập.

Tùy chọn đầu tiên là tùy chọn bạn đang sử dụng: giữ tất cả các cột liên quan đến các loại khác nhau trong một bảng, với cờ và số trống được sử dụng để biểu thị loại bản ghi đã cho. Đây là cách đơn giản nhất để quản lý phân loại phụ, và nó thường hoạt động tốt khi bạn chỉ có một vài loại hoặc nếu các loại khác nhau không phải là rất khác nhau. Trong trường hợp của bạn, có vẻ như các loại có thể thay đổi một chút.

Tùy chọn thứ hai là giữ một bảng trung tâm chứa tất cả các cột chung giữa các loại phụ và có mối quan hệ một-một với các bảng khác chứa chi tiết cụ thể về loại đó.

Tùy chọn thứ ba là không nghĩ về các loại khác nhau dưới dạng kiểu phụ và chỉ giữ tất cả các loại bản ghi trong các bảng riêng biệt. Vì vậy, bạn không có bảng chung giữa các loại giữ dữ liệu chung và mỗi bảng sẽ có một số cột được lặp lại trên các bảng.

Hiện tại, mỗi tùy chọn đều có vị trí của nó. Bạn sẽ sử dụng tùy chọn đầu tiên khi không có nhiều khác biệt giữa các loại khác nhau. Bạn sẽ sử dụng tùy chọn thứ hai nếu bạn cần thao tác các trường chung một cách độc lập với các trường loại cụ thể; ví dụ: nếu bạn muốn liệt kê tất cả các trò chơi thể thao trong một mạng lưới lớn có thông tin chung và sau đó cho phép người dùng nhấp để xem chi tiết cụ thể về loại trò chơi đó. Bạn sẽ sử dụng tùy chọn thứ ba khi các loại thực sự không liên quan lắm và bạn chỉ lưu trữ chúng với nhau một cách thuận tiện; các lược đồ không giống nhau, ngay cả khi nó chia sẻ một vài trường, không nên hợp nhất.

Vì vậy, hãy suy nghĩ về những gì bạn cần làm với dữ liệu và cách dữ liệu phù hợp với ba tùy chọn và tự quyết định điều tốt nhất. Nếu bạn không thể quyết định, hãy cập nhật câu hỏi của bạn với các chi tiết về cách bạn định sử dụng dữ liệu và tôi hoặc người khác sẽ có thể giúp bạn nhiều hơn.

Answer 2

Tôi nghĩ rằng vấn đề là bạn có một model like this (cửa hàng tất cả mọi thứ trong một cách tiếp cận bảng). This approach và cũng là this approach là hai trong số các lựa chọn thay thế mà bạn có thể chọn - tôi chắc chắn rằng những người khác sẽ có thêm một số đề xuất.

Tất cả đều có ưu và khuyết điểm của họ. Tôi không thể bình luận về các đặc tính hiệu suất của chúng trong MySql, nhưng chắc chắn các phương pháp tiếp cận khác làm giảm việc sử dụng các null, mà chỉ có thể là một điều tốt.

Nếu bạn thực sự quan tâm đến sự khác biệt giữa 3 phương pháp tiếp cận, tôi khuyên bạn nên mua cuốn sách Kiến trúc ứng dụng doanh nghiệp của Martin Fowler.

Xét về đặc điểm hiệu suất - bạn có thể muốn xem các câu hỏi like this one và also this one.

Bạn có thể đọc khoảng vertical partitioning in MySql here.

Answer 3

Tôi chắc chắn sẽ xem normalizing the table. Mặc dù tôi không chắc chắn về lợi ích hiệu suất, rất có thể sẽ là một lợi ích lưu trữ với số lượng lớn mục nhập.

sự thay đổi đầu tiên của tôi là nên có bất kỳ dữ liệu có liên quan đến chỉ có 1 hoặc 2 môn thể thao và có chúng trong các bảng riêng biệt với một khóa ngoại từ bảng chính

Answer 4

Có, sử dụng nhiều cột nếu điều đó có ý nghĩa. Miễn là bạn không sử dụng một antipattern như "field1, field2, field3" vv, sau đó nó là tốt.

Rất nhiều NULL là tốt, chúng không bị tổn thương nhiều. Ngoài ra 200k là một số lượng nhỏ các hàng bạn không thể thấy nhiều vấn đề về hiệu suất. Tôi không biết bạn đang lên kế hoạch bao nhiêu lần chèn vào bảng này, nhưng nếu nó là < 100 mỗi giây, tôi không thấy bất cứ điều gì là một vấn đề.

Bạn sẽ muốn lập chỉ mục bằng cách nào đó. Số lượng chỉ mục sẽ ảnh hưởng đến hiệu suất chèn, nhưng tôi tưởng tượng rằng hầu hết các cột của bạn sẽ không cần được lập chỉ mục.

Với một bảng nhỏ như vậy nó không thực sự quan trọng quá nhiều - không ai trong số đó. Bạn có thể sao chép dữ liệu của bạn nhiều lần mà không gặp phải bất kỳ vấn đề nào về không gian - bạn đang ở vị trí đặc quyền.

Answer 5

200K lần 50 giá trị không phải là một bảng lớn. Đừng lo lắng về hiệu suất cho đến khi bạn có những thứ như dễ sử dụng và tự do khỏi sự mâu thuẫn trong tầm kiểm soát.

Có nhiều lý do để phân hủy bảng. Phân tách một bảng có nghĩa là chia nó thành hai hoặc nhiều bảng với hầu hết các cột chỉ đi vào một bảng, và các cột khác đi vào nhiều hơn một bảng (khóa ngoài).

Farell đề cập đến quá trình chuẩn hóa. Lợi ích chính để bình thường hóa là nó loại trừ một số loại dị thường cập nhật nhất định, bao gồm cả những loại cho phép sự kiện mâu thuẫn được lưu trữ trong cùng một bảng. Lợi ích lưu trữ là thứ yếu. Lợi ích hiệu suất, nếu có, có thể là nhỏ. Có nói rằng, bình thường hóa là điều quan trọng nhất bạn có thể tìm hiểu về thiết kế bảng. Nếu bạn vi phạm các quy tắc bình thường hóa mà không hiểu hậu quả, bạn sẽ bị mù.

Nếu tôi được giới thiệu vào bảng cơ sở dữ liệu có 40 cột trở lên và có bất kỳ sự cố nào trong databse (hiệu suất, tham nhũng hoặc bất kỳ thứ gì), tôi sẽ xem liệu bảng đó có thể được chuẩn hóa hơn nữa không các chi phí/benfits làm như vậy là gì.

Có nhiều lý do để phân vùng bảng. Như Reinerpost đã nói, đừng lo lắng về các phần cho đến khi bạn có sự kiểm soát bình thường.