2010-02-16 35 views
13

Tôi đang làm việc với Ruby on Rails, nhưng câu hỏi này tôi nghĩ rộng hơn và áp dụng cho thiết kế cơ sở dữ liệu nói chung.Khi nào cần chia nhỏ mô hình thành nhiều bảng cơ sở dữ liệu?

Khi nào thì nên chia nhỏ một mô hình thành nhiều bảng? Ví dụ: giả sử tôi có mô hình Người dùng và số trường trong mô hình thực sự bắt đầu tăng lên. Ví dụ: Người dùng có thể nhập trang web, ngày sinh của anh ấy, múi giờ của anh ấy, v.v. của anh ấy, v.v.

Có lợi thế hay bất lợi khi chia nhỏ mô hình, có thể bảng Người dùng chỉ có thông tin cơ bản như đăng nhập và email, và sau đó có một bảng mà mỗi người dùng có đó là một cái gì đó như UserInfo, và một người khác đó là UserPermissions, và một người khác là UserPrivacySettings hoặc một cái gì đó như thế?

Chỉnh sửa: Để thêm độ bóng bổ sung cho điều này, hầu hết các trường hiếm khi được truy cập, ngoại trừ trên các trang cụ thể cho chúng. Ví dụ: những thứ như sinh nhật chỉ được truy cập nếu ai đó nhấp qua hồ sơ của người dùng. Hơn nữa, một số trường (hiếm khi được truy cập) có tiềm năng cực kỳ lớn. Hầu hết các trường có khả năng được đặt thành trống hoặc không.

+0

Có bao nhiêu trường mà chúng ta thực sự đang nói đến trong bảng Người dùng? – inkedmn

Trả lời

3

Đây sẽ là một tình huống để phân tích.

Khi bạn thấy rằng nhiều trường trong bảng như vậy là NULL và có thể được nhóm lại với nhau (ví dụ: UserContactInfo), đã đến lúc xem trích xuất thông tin vào bảng của riêng nó.

Bạn muốn tránh có bảng có hàng chục/hàng trăm trường chỉ có dữ liệu được nhập sai.

Thay vì cố gắng nhóm dữ liệu một cách hợp lý và hủy bỏ bảng chính, hãy tiếp tục các trường hầu hết được điền. Sau đó, bạn có thể tạo tập con dữ liệu, hầu như bạn sẽ đại diện cho chúng trên giao diện người dùng, (Thông tin liên hệ, Sở thích cá nhân, Thông tin liên quan đến công việc, v.v.) thành các bảng riêng biệt.

+1

Các nhược điểm liên quan đến bảng có dữ liệu được nhập thưa thớt là gì? –

3

Việc truy xuất một hàng sẽ đắt hơn nếu có nhiều cột, đặc biệt nếu bạn thường chỉ cần một số trường. Ngoài ra, lưu trữ các công cụ như các thành phần của một địa chỉ trong một lớp riêng biệt là một trường hợp của DRY. Mặt khác, nếu bạn cần tất cả các trường của đối tượng, sẽ mất nhiều thời gian hơn để thực hiện truy vấn ghép.

Tôi thường không bận tâm phân phối các lớp học qua nhiều bảng chỉ để làm cho mã dễ đọc hơn (tức là không có các bộ phận tái sử dụng như địa chỉ).

+1

Việc tìm một hàng có nhiều cột cũng đắt hơn khi bạn chỉ chọn các cột được yêu cầu? Hoặc sẽ thực hiện trong cùng một thời gian như nếu có ít cột hơn. –

7

Nói chung, bạn nên đặt mọi thứ có mối quan hệ một-một trong cùng một bảng. Trừ khi userbase của bạn bao gồm Queen hoặc Paddington Bear, người dùng chỉ có một sinh nhật, vì vậy đó phải là một thuộc tính của bảng USERS. Những thứ có mối quan hệ một-nhiều nên ở trong các bảng riêng biệt. Vì vậy, nếu người dùng có thể có nhiều cài đặt bảo mật bằng mọi cách, hãy tách chúng ra.

Tách một bảng thành nhiều bảng có thể khiến truy vấn phức tạp hơn hoặc chậm hơn, nếu chúng tôi muốn truy xuất tất cả thông tin của người dùng cùng một lúc. Mặt khác, nếu chúng ta có một tập hợp các thuộc tính mà chỉ được truy vấn hoặc cập nhật theo một cách rời rạc thì có một bảng riêng biệt để giữ dữ liệu đó là một ý tưởng âm thanh.

Các vấn đề liên quan