Cái nào hiệu quả hơn: Nhiều bảng MySQL hoặc một bảng lớn?

Question

Tôi lưu trữ các chi tiết người dùng khác nhau trong cơ sở dữ liệu MySQL của tôi. Ban đầu nó được thiết lập trong các bảng khác nhau có nghĩa là dữ liệu được liên kết với UserIds và xuất ra thông qua các cuộc gọi phức tạp đôi khi hiển thị và thao tác dữ liệu theo yêu cầu. Thiết lập một hệ thống mới, nó gần như hợp lý để kết hợp tất cả các bảng này thành một bảng lớn có nội dung liên quan.

• Đây có phải là trợ giúp hay cản trở không?
• Cân nhắc tốc độ trong việc gọi, cập nhật hoặc tìm kiếm/thao tác?

Dưới đây là một ví dụ về một số cấu trúc của tôi bảng (s):

• người dùng - UserId, tên người dùng, email, mật khẩu được mã hóa, ngày đăng ký, ip
• user_details - dữ liệu cookie, tên, địa chỉ, thông tin liên lạc, liên kết, dữ liệu nhân khẩu học
• user_activity - đóng góp, trực tuyến cuối cùng, xem cuối cùng
• user_settings - hiển thị hồ sơ thiết lập
• user_interests - biến nhắm mục tiêu quảng cáo
• user_levels - quyền truy cập
• user_stats - hits, trả khớp

---

Edit: Tôi đã bỏ phiếu tán tất cả các câu trả lời cho đến nay, tất cả họ đều có những yếu tố mà chủ yếu trả lời câu hỏi của tôi.

Hầu hết các bảng đều có mối quan hệ 1: 1 là lý do chính khiến chúng không chuẩn hóa chúng.

Sẽ có vấn đề gì nếu bảng trải dài trên hơn 100 cột khi một phần lớn các ô này có thể vẫn còn trống?

Answer 1

Nhiều bảng giúp đỡ trong những cách/trường hợp sau đây:

(a) nếu những người khác nhau sẽ được phát triển các ứng dụng liên quan đến các bảng khác nhau, nó làm cho tinh thần để chia rẽ họ.

(b) Nếu bạn muốn cung cấp các loại quyền hạn khác nhau cho những người khác nhau cho một phần khác nhau của việc thu thập dữ liệu, việc phân chia dữ liệu có thể thuận tiện hơn. (Tất nhiên, bạn có thể xem xét định nghĩa lượt xem và cho phép chúng một cách thích hợp).

(c) Để di chuyển dữ liệu đến các địa điểm khác nhau, đặc biệt là trong quá trình phát triển, có thể có ý nghĩa khi sử dụng các bảng dẫn đến kích thước tệp nhỏ hơn.

(d) Bản in chân nhỏ hơn có thể mang lại sự thoải mái khi bạn phát triển các ứng dụng về thu thập dữ liệu cụ thể của một thực thể duy nhất.

(e) Đó là một khả năng: những gì bạn nghĩ là một dữ liệu giá trị duy nhất có thể trở thành nhiều giá trị thực sự trong tương lai. ví dụ. hạn mức tín dụng là một trường giá trị duy nhất kể từ bây giờ. Nhưng ngày mai, bạn có thể quyết định thay đổi các giá trị như (ngày, ngày, giá trị tín dụng). Bảng phân chia có thể có ích ngay bây giờ.

Phiếu bầu của tôi sẽ dành cho nhiều bảng - với dữ liệu được phân tách một cách thích hợp.

Chúc may mắn.

Answer 2

Kết hợp các bảng được gọi là không chuẩn hóa.

Có thể (hoặc có thể không) giúp thực hiện một số truy vấn (tạo nhiều số JOIN s) để chạy nhanh hơn với chi phí tạo địa ngục bảo trì.

MySQL chỉ có thể sử dụng phương pháp JOIN, cụ thể là NESTED LOOPS.

Điều này có nghĩa là đối với mỗi bản ghi trong bảng điều khiển, MySQL sẽ tìm một bản ghi phù hợp trong bảng được định hướng trong một vòng lặp.

Định vị bản ghi là hoạt động khá tốn kém, có thể mất hàng chục lần miễn là quét bản ghi thuần túy.

Di chuyển tất cả các bản ghi của bạn vào một bảng sẽ giúp bạn loại bỏ hoạt động này, nhưng bản thân bảng phát triển lớn hơn và quá trình quét bảng mất nhiều thời gian hơn.

Nếu bạn có nhiều bản ghi trong các bảng khác, thì tăng khả năng quét bảng có thể thừa hưởng lợi ích của các bản ghi được quét tuần tự.

Địa chỉ bảo trì, mặt khác, được đảm bảo.

Answer 3

Tạo một bảng lớn đi ngược lại các hiệu trưởng cơ sở dữ liệu quan hệ. Tôi sẽ không kết hợp tất cả chúng thành một cái bàn. Bạn sẽ nhận được nhiều trường hợp dữ liệu lặp lại. Ví dụ: nếu người dùng của bạn có ba sở thích, bạn sẽ có 3 hàng, với cùng một dữ liệu người dùng chỉ để lưu trữ ba sở thích khác nhau. Definatly đi cho phương pháp tiếp cận nhiều 'bình thường hóa' bảng. Xem this trang Wiki để chuẩn hóa cơ sở dữ liệu.

Edit: Tôi đã cập nhật câu trả lời của tôi, như bạn đã cập nhật câu hỏi của bạn ... Tôi đồng ý với câu trả lời ban đầu của tôi ngay cả bây giờ hơn vì ...

một phần lớn của các tế bào này là có thể vẫn còn trống

Nếu ví dụ, người dùng không có bất kỳ sở thích nào, nếu bạn bình thường thì bạn sẽ không có hàng trong bảng quan tâm cho người dùng đó. Nếu bạn có tất cả mọi thứ trong một bảng lớn, sau đó bạn sẽ có cột (và dường như rất nhiều trong số họ) có chứa chỉ NULL.

Tôi đã làm việc cho một công ty điện thoại nơi có rất nhiều bảng, việc nhận dữ liệu có thể yêu cầu nhiều lần tham gia. Khi hiệu năng đọc từ các bảng này là rất quan trọng thì các thủ tục được tạo ra có thể tạo ra một bảng phẳng (tức là một bảng không chuẩn hóa) sẽ không yêu cầu tham gia, tính toán vv mà các báo cáo có thể trỏ tới. Những nơi này sau đó được sử dụng kết hợp với một đại lý máy chủ SQL để chạy công việc tại các khoảng nhất định (tức là một lượt xem hàng tuần của một số số liệu thống kê sẽ chạy một lần một tuần và vv).

Answer 4

Tôi nghĩ đây là một trong những tình huống "phụ thuộc". Có nhiều bảng là sạch hơn và có lẽ về lý thuyết tốt hơn. Nhưng khi bạn phải tham gia 6-7 bảng để nhận thông tin về một người dùng, bạn có thể bắt đầu suy nghĩ lại cách tiếp cận đó.

Answer 5

Làm tất cả các bảng đó có mối quan hệ 1-to-1 không? Ví dụ: mỗi hàng của người dùng chỉ có một hàng tương ứng trong user_stats hoặc user_levels? Nếu có, có thể kết hợp chúng thành một bảng. Nếu mối quan hệ không phải là1 to 1, có thể sẽ không có ý nghĩa khi kết hợp (không chuẩn hóa) chúng.

Việc đặt chúng trong các bảng riêng biệt so với một bảng có thể sẽ có ít ảnh hưởng đến hiệu suất mặc dù trừ khi bạn có hàng trăm nghìn hoặc hàng triệu bản ghi người dùng. Việc đạt được thực sự duy nhất bạn sẽ nhận được là từ việc đơn giản hóa các truy vấn của bạn bằng cách kết hợp chúng.

ETA:

Nếu bạn mối quan tâm là về việc có quá nhiều cột, sau đó suy nghĩ về những thứ bạn thường sử dụng với nhau và kết hợp những, để lại phần còn lại trong một bảng riêng biệt (hoặc một vài riêng nếu cần).

Nếu bạn nhìn vào cách bạn sử dụng dữ liệu, tôi đoán rằng bạn sẽ thấy rằng 80% truy vấn của bạn sử dụng 20% ​​dữ liệu đó với 80% dữ liệu còn lại chỉ được sử dụng thỉnh thoảng. Kết hợp thường xuyên sử dụng 20% ​​vào một bảng, và để lại 80% mà bạn không thường xuyên sử dụng trong các bảng riêng biệt và có thể bạn sẽ có một sự thỏa hiệp tốt.

Answer 6

Tôi sẽ nói điều đó phụ thuộc vào những gì các bảng khác thực sự có ý nghĩa. Có một user_details chứa nhiều hơn sau đó thêm 1/người dùng và vân vân. Mức độ chuẩn hóa phù hợp nhất với nhu cầu của bạn phụ thuộc vào nhu cầu của bạn.

Nếu bạn có một bảng có chỉ mục tốt có thể sẽ nhanh hơn. Nhưng mặt khác có lẽ khó khăn hơn để duy trì.

Đối với tôi, có vẻ như bạn có thể bỏ qua User_Details vì nó có thể là mối quan hệ 1-1 với Người dùng. Nhưng phần còn lại có thể là rất nhiều hàng cho mỗi người dùng?

Answer 7

Tất cả các mối quan hệ đó có phải là 1: 1 không? Ý tôi là, nếu người dùng có thể thuộc về cấp độ người dùng khác nhau hoặc nếu sở thích của người dùng được thể hiện dưới dạng một số bản ghi trong bảng sở thích của người dùng thì việc hợp nhất các bảng đó sẽ không nằm trong câu hỏi ngay lập tức.

Về câu trả lời trước về bình thường hóa, phải nói rằng các quy tắc chuẩn hóa cơ sở dữ liệu đã hoàn toàn bỏ qua hiệu suất và chỉ xem xét thiết kế cơ sở dữ liệu gọn gàng là gì. Đó thường là những gì bạn muốn đạt được, nhưng có những lúc nó có ý nghĩa để tích cực denormalize trong việc theo đuổi hiệu suất.

Tất cả trong tất cả, tôi muốn nói câu hỏi có bao nhiêu trường có trong bảng và tần suất chúng được truy cập. Nếu hoạt động của người dùng thường không thú vị, thì nó có thể chỉ là một mối phiền toái khi luôn có nó trên cùng một bản ghi, vì lý do bảo trì và. Nếu một số dữ liệu, như cài đặt, nói, được truy cập rất thường xuyên, nhưng chỉ đơn giản là chứa quá nhiều trường, nó cũng có thể không thuận tiện để hợp nhất các bảng. Nếu bạn chỉ quan tâm đến hiệu suất, bạn có thể xem xét các cách tiếp cận khác, chẳng hạn như giữ các cài đặt riêng biệt, nhưng lưu chúng trong một biến phiên của riêng chúng để bạn không phải truy vấn cơ sở dữ liệu cho chúng rất thường xuyên.

Answer 8

Tại sao không sử dụng phương pháp tương tự Wordpress không bằng việc có một bảng cho người dùng với thông tin người dùng cơ bản mà mọi người đều có và sau đó thêm một "user_meta" bảng mà về cơ bản có thể được bất kỳ cặp khóa, giá trị liên kết với id người dùng. Vì vậy, nếu bạn cần tìm tất cả thông tin meta cho người dùng, bạn chỉ có thể thêm thông tin đó vào truy vấn của mình. Bạn cũng sẽ không phải luôn luôn thêm truy vấn phụ nếu không cần thiết cho những thứ như đăng nhập.Lợi ích của phương pháp này cũng khiến bảng của bạn mở rộng để thêm các tính năng mới cho người dùng của bạn như lưu trữ xử lý twitter của họ hoặc từng sở thích cá nhân. Bạn cũng sẽ không phải đối phó với một mê cung của ID được liên kết vì bạn có một bảng quy định tất cả siêu dữ liệu và bạn sẽ giới hạn chỉ một liên kết thay vì 50.

Wordpress thực hiện điều này để cho phép các tính năng được bổ sung thông qua các plugin, do đó cho phép dự án của bạn có khả năng mở rộng hơn và sẽ không yêu cầu đại tu cơ sở dữ liệu hoàn chỉnh nếu bạn cần thêm một tính năng mới.