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

Vì vậy, đây là nhiều hơn một câu hỏi thiết kế.

Tôi có một khóa chính (giả sử ID người dùng) và tôi có hàng tấn thông tin liên quan đến người dùng đó.

Tôi có nên chia nhiều bảng thành các loại theo thông tin hay tôi chỉ nên có một bảng có nhiều cột?

Cách tôi thường làm là có nhiều bảng, giả sử, 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 đầu cuối, v.v. để giữ mọi thứ có tổ chức.

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 theo cách đó và có một bảng có nhiều cột là tốt. Vấn đề là, tất cả các cột có cùng khóa chính.

Tôi khá mới với thiết kế cơ sở dữ liệu vì vậy 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ì?

Bất kỳ thời gian nào thông tin là một (một người dùng có một tên và mật khẩu), thì có lẽ nên có một bảng, vì nó làm giảm số lượng tham gia mà cơ sở dữ liệu sẽ cần phải thực hiện để lấy kết quả. Tôi nghĩ rằng một số cơ sở dữ liệu có giới hạn về số lượng cột trên mỗi bảng, nhưng tôi sẽ không lo lắng về nó trong các trường hợp thông thường và bạn luôn có thể phân tách nó sau 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 ngàn hàng thông tin sử dụng), thì nó nên đượ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 gây lãng phí không gian lưu trữ, không gian bộ nhớ cache và khiến cơ sở dữ liệu khó bảo trì hơn ).

Bạn có thể thấy bài viết Wikipedia về bình thường hóa cơ sở dữ liệu rất thú vị, vì nó thảo luận về lý do cho điều này sâu hơn:

Chuẩn hóa cơ sở dữ liệu là quá trình tổ chức các trường và bảng của cơ sở dữ liệu quan hệ để giảm thiểu sự dư thừa và 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ự phòng 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 sao cho việc 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ệ được xác định.

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

Một bàn lớn thường là một lựa chọn kém. 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 và biết cách viết các truy vấn hiệu suất, chúng sẽ hoạt động tốt.

Khi các bảng có quá nhiều cột, thì bạn có thể gặp vấn đề với kích thước thực của trang mà cơ sở dữ liệu đang lưu trữ thông tin. Bản ghi có thể quá lớn đối với trang, trong đó bạn có thể cuối cùng 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 ít nhất bạn có thể (trong SQL Server) kiểu dữ liệu (với một bộ quy tắc bạn cần tra cứu nếu bạn đang làm điều này) nhưng nếu nhiều bản ghi sẽ tràn kích thước trang, bạn có thể tạo ra các vấn đề hiệu suất run rẩy. Bây giờ cách MYSQL xử lý các trang và liệu bạn có gặp sự cố khi kích thước trang tiềm năng quá lớn hay không là điều bạn sẽ phải tìm trong tài liệu cho cơ sở dữ liệu đó.

Tôi có một ví dụ tốt. Cơ sở dữ liệu quá chuẩn hóa với tập hợp các mối quan hệ sau:

people -> rel_p2staff -> staff

và

people -> rel_p2prosp -> prospects

Trường hợp mọi người có chi tiết về tên và người, nhân viên chỉ có chi tiết hồ sơ nhân viên, khách hàng tiềm năng chỉ có chi tiết về khách hàng tiềm năng và các bảng rel 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.

Kiểu 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 quan hệ này, đó là tham gia nhiều bảng mỗi lần, đôi khi 8 và nhiều hơn tham gia bảng. Nó đã hoạt động tốt cho đến giữa năm nay, khi nó bắt đầu trở nên rất chậm khi chúng tôi vượt qua 40000 hồ sơ của mọi người.

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 thiết kế và quản lý được chuẩn hóa cụ thể hiện đã phê duyệt việc 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. $$$$ Ouch.

Giải pháp sẽ là có một mối quan hệ trực tiếp cho people -> staffvàpeople -> prospect

Đã xem qua điều này và là một người đã từng sử dụng MySQL rất nhiều và sau đó chuyển sang Postgres gần đây, một trong những lợi thế lớn là bạn có thể thêm các đối tượng JSON vào một trường trong Postgres.

Vì vậy, nếu bạn ở trong tình huống này, bạn không nhất thiết phải quyết định giữa một bảng lớn có nhiều cột và tách nó ra, nhưng bạn có thể hợp nhất các cột thành các đối tượng JSON để giảm nó, thay vì địa chỉ là 5 cột, nó chỉ có thể trở thành một. Bạn cũng có thể truy vấn đối tượng đó.

Hãy 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 sẽ có nhiều hàng cho người dùng đó chứ? Nếu bạn phải cập nhật một người dùng, bạn có muốn giữ một dấu vết kiểm toán không? Người dùng có thể có nhiều hơn một phiên bản của một thành phần dữ liệu không? (ví dụ như số điện thoại) bạn sẽ có trường hợp bạn muốn thêm một yếu tố hoặc tập hợp các yếu tố sau? nếu bạn trả lời có thì rất có thể bạn muốn có các bảng con 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ũng có thể làm điều đó trên bảng phẳng) và IMO dễ duy trì hơn nếu bạn cần thêm một trường sau đó, đặc biệt nếu đó sẽ là trường bắt buộc.

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

Nhưng, có nhiều trường hợp một bàn phẳng lớn sẽ phù hợp để bạn phải xem xét tình huống của mình để quyết định.

Tôi đã hoàn thành 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; Vâng, đúng là chỉ có dữ liệu duy nhất ở một nơi nhưng thực sự rất khó để thực hiện các truy vấn với cơ sở dữ liệu được chuẩn hóa quá mức với nhiều bản ghi. 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 khó duy trì giống như facebook, gmail, v.v. và sử dụng bảng khác nhau cho một bộ bản ghi 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 đó ... :)

Cách thông thường để làm điều này sẽ 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 thành 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, ở đó cho lược đồ mà 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à bộ BI, cách tiếp cận cột sẽ rất có lợi vì nó hỗ trợ nhiều hơn cho nhu cầu báo cáo. Các cách tiếp cận theo cột như những phương pháp với infobright.org có hiệu suất và nén hiệu suất rất lớn khiến việc sử dụng cả hai cách tiếp cận này vô cùng hữu ích. Rất nhiều công ty 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 thực hiện cả khái niệm có nhiều kiến ​​trúc cơ sở dữ liệu.

Tôi nghĩ rằng có một bảng duy nhất 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 nó thể hiện 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 của học sinh, bạn nên sắp xếp bảng theo cách cảm ơn người ghi bàn cao nhất được phân biệt rõ 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 là thậm chí.