MySQL: nhiều bảng hoặc một bảng có nhiều cột?

Question

Vì vậy, đây là một câu hỏi thiết kế. Tôi có một khóa chính nói ID của người dùng và tôi có rất nhiều thông tin liên quan đến người dùng đó. Tôi có liên quan nên tôi có nhiều bảng được chia thành các loại theo thông tin hay tôi chỉ nên có một bảng với nhiều cột? Cách thức tôi sử dụng để làm điều đó là có nhiều bảng, vì vậy hãy nói một bảng cho dữ liệu sử dụng ứng dụng, một bảng cho thông tin hồ sơ, một bảng cho mã thông báo kết thúc và v.v., để giữ cho mọi thứ được sắp xếp gọn gàng. Gần đây một số người nói với tôi rằng tốt hơn là không làm điều đó và có một bảng với rất nhiều cột là tốt. Vấn đề là tất cả các cột đó đều có khóa chính giống nhau.

Tôi khá mới với thiết kế cơ sở dữ liệu để cách tiếp cận nào tốt hơn và ưu và nhược điểm là gì? Cách thông thường để làm điều đó là gì?

Answer 1

Bất kỳ thông tin thời gian nào là một (một người dùng có một tên và mật khẩu), thì tốt hơn nên có một bảng, vì nó làm giảm số lần kết nối cơ sở dữ liệu sẽ cần thực hiện để truy xuất kết quả. Tôi nghĩ rằng một số cơ sở dữ liệu có một giới hạn về số cột trên mỗi bảng, nhưng tôi sẽ không lo lắng về nó trong trường hợp bình thường, và bạn luôn có thể chia nó sau này nếu bạn cần.

Nếu dữ liệu là một-nhiều (mỗi người dùng có hàng nghìn thông tin sử dụng), thì nó sẽ được chia thành các bảng riêng biệt để giảm dữ liệu trùng lặp (dữ liệu trùng lặp lãng phí dung lượng lưu trữ, không gian bộ nhớ cache và làm cho cơ sở dữ liệu khó duy trì hơn).

Bạn có thể tìm thấy các bài viết Wikipedia trên database normalization thú vị, vì nó thảo luận về lý do cho điều này trong chiều sâu:

Cơ sở dữ liệu bình thường là quá trình tổ chức thực hiện các lĩnh vực và các bảng cơ sở dữ liệu quan hệ để giảm thiểu sự dư thừa và sự phụ thuộc . Bình thường hóa thường bao gồm việc chia các bảng lớn thành các bảng nhỏ hơn (và ít dư thừa hơn) và xác định mối quan hệ giữa chúng. Mục tiêu là cô lập dữ liệu để bổ sung, xóa và sửa đổi một trường có thể được thực hiện chỉ trong một bảng và sau đó được truyền qua phần còn lại của cơ sở dữ liệu thông qua các mối quan hệ đã xác định.

Denormalization cũng là điều cần lưu ý, vì có trường hợp dữ liệu lặp lại tốt hơn (vì nó làm giảm số lượng cơ sở dữ liệu cần làm khi đọc dữ liệu). Tôi khuyên bạn nên làm cho dữ liệu của bạn được bình thường hóa càng tốt để bắt đầu, và chỉ không chuẩn hóa nếu bạn biết về các vấn đề hiệu năng trong các truy vấn cụ thể.

Answer 2

Cách thông thường để thực hiện việc này là sử dụng các bảng khác nhau như trong lược đồ sao hoặc lược đồ bông tuyết. Howeevr, tôi sẽ căn cứ chiến lược này là hai lần. Tôi tin vào lý thuyết rằng dữ liệu chỉ nên tồn tại ở một nơi, ở đó đối với lược đồ tôi đã đề cập sẽ hoạt động tốt. Tuy nhiên, tôi cũng tin rằng đối với các công cụ báo cáo và BI, một phương pháp tiếp cận cột sẽ cực kỳ có lợi vì nó hỗ trợ nhiều hơn cho nhu cầu báo cáo. Các phương pháp tiếp cận cột như những người có infobright.org có mức tăng hiệu suất và nén khổng lồ khiến cho việc sử dụng cả hai cách tiếp cận cực kỳ hữu ích. Rất nhiều công ty đang bắt đầu nhận ra rằng chỉ có một kiến ​​trúc cơ sở dữ liệu trong tổ chức không hỗ trợ đầy đủ các nhu cầu của họ. Rất nhiều công ty đang triển khai cả hai khái niệm về việc có nhiều hơn một kiến ​​trúc cơ sở dữ liệu.

Answer 3

tự hỏi mình những câu hỏi này nếu bạn đặt mọi thứ vào một bảng, bạn có nhiều hàng cho người dùng đó không? Nếu bạn phải cập nhật một người dùng, bạn có muốn giữ một đường mòn kiểm toán không? Người dùng có thể có nhiều trường hợp của một phần tử dữ liệu không? (ví dụ như số điện thoại), bạn có trường hợp bạn có thể muốn thêm phần tử hoặc tập hợp các phần tử sau này không? nếu bạn trả lời có thì rất có thể bạn muốn có bảng con với các mối quan hệ khóa ngoại. Ưu điểm của bảng cha/con là tính toàn vẹn dữ liệu, hiệu suất thông qua các chỉ mục (có, bạn có thể thực hiện nó trên một bảng phẳng) và IMO dễ bảo trì hơn nếu bạn cần thêm một trường sau này, đặc biệt nếu nó là một yêu cầu cánh đồng.

Nhược điểm thiết kế là khó khăn hơn, các truy vấn trở nên hơi phức tạp

hơn Nhưng, có rất nhiều trường hợp một bảng phẳng lớn sẽ phù hợp, do đó bạn phải nhìn vào tình hình của bạn để quyết định.

Answer 4

Một bảng lớn thường là lựa chọn không tốt. Các bảng liên quan là những gì cơ sở dữ liệu quan hệ được thiết kế để làm việc với. Nếu bạn lập chỉ mục đúng cách và biết cách viết các truy vấn thực hiện, chúng sẽ hoạt động tốt.

Khi bảng nhận quá nhiều cột, bạn có thể gặp sự cố với kích thước thực của trang mà cơ sở dữ liệu lưu trữ thông tin. Hoặc bản ghi có thể kết thúc quá lớn cho trang, trong đó bạn có thể kết thúc không thể tạo hoặc cập nhật một bản ghi cụ thể khiến người dùng không hài lòng hoặc bạn có thể (trong SQL Server ít nhất) được cho phép một số tràn datatypes (với một bộ quy tắc bạn cần phải tìm kiếm nếu bạn đang làm điều này) nhưng nếu nhiều hồ sơ sẽ tràn kích thước trang, bạn có thể tạo ra các vấn đề hiệu suất run. Bây giờ làm thế nào MYSQL xử lý các trang và cho dù bạn có một vấn đề khi kích thước trang tiềm năng quá lớn là một cái gì đó bạn sẽ phải tìm trong tài liệu cho cơ sở dữ liệu đó.

Answer 5

Tôi đã thực hiện xong một số loại thiết kế cơ sở dữ liệu. đối với tôi, nó phụ thuộc vào độ khó của hệ thống với quản lý cơ sở dữ liệu; yeah nó là đúng để có dữ liệu duy nhất ở một nơi duy nhất nhưng nó thực sự là khó khăn để làm cho các truy vấn với cơ sở dữ liệu quá bình thường với rất nhiều hồ sơ. Chỉ cần kết hợp hai lược đồ; sử dụng một bảng lớn nếu bạn cảm thấy rằng bạn sẽ có một hồ sơ lớn mà khó có thể duy trì giống như facebook, gmail, v.v. và sử dụng bảng khác nhau cho một bộ hồ sơ cho hệ thống đơn giản ... đây chỉ là ý kiến ​​của tôi .. tôi hy vọng nó có thể giúp .. chỉ cần làm điều đó .. bạn có thể làm điều đó ... :)

Answer 6

Tôi có một ví dụ tốt. cơ sở dữ liệu quá bình thường hóa với các thiết lập sau đây của các mối quan hệ:

people -> rel_p2staff -> staff 

và

people -> rel_p2prosp -> prospects 

Nơi mọi người có cái tên và những người chi tiết, nhân viên chỉ có các chi tiết ghi lại nhân viên, triển vọng chỉ có triển vọng chi tiết, và rel bảng là các bảng quan hệ với các khóa ngoại từ những người liên kết với nhân viên và khách hàng tiềm năng.

Loại thiết kế này mang trên toàn bộ cơ sở dữ liệu.

Bây giờ để truy vấn tập hợp các mối quan hệ này, mỗi lần tham gia nhiều bảng, đôi khi 8 bảng trở lên. Nó đã được làm việc tốt lên đến giữa năm nay, khi nó bắt đầu nhận được rất chậm bây giờ mà chúng tôi qua 40000 hồ sơ của người dân.

Lập chỉ mục và tất cả các loại trái cây treo thấp đã được sử dụng hết năm ngoái, tất cả các truy vấn được tối ưu hóa để hoàn thiện. Đây là phần cuối của con đường cho thiết kế chuẩn hóa cụ thể và quản lý hiện đã được phê duyệt xây dựng lại toàn bộ ứng dụng phụ thuộc vào nó cũng như cơ cấu lại cơ sở dữ liệu, trong thời hạn 6 tháng. Bỏ qua Ouch.

Các giải pháp sẽ có một mối quan hệ trực tiếp cho people -> staff và people -> prospect

Answer 7

tôi nghĩ rằng có một bảng duy nhất có hiệu quả hơn nhưng bạn nên chắc chắn rằng bảng được tổ chức theo cách mà nó cho thấy mối quan hệ, xu hướng cũng như sự khác biệt trong các biến của cùng một hàng. Ví dụ: nếu bảng hiển thị độ tuổi và điểm số của học sinh, bạn nên sắp xếp bảng theo cách mà cảm ơn người ghi bàn cao nhất cũng được phân biệt với người ghi bàn thấp nhất và sự khác biệt về độ tuổi của học sinh.