2009-11-09 25 views
8

Tôi đang học Rails bằng cách xây dựng một trang web đơn giản nơi người dùng có thể tạo bài viết và nhận xét về các bài viết đó. Tôi có chế độ xem liệt kê các bài viết và nhận xét gần đây nhất của người dùng. Bây giờ tôi muốn thêm hồ sơ người dùng ', nơi người dùng có thể nhập thông tin như vị trí, tuổi tác và tiểu sử ngắn của họ. Tôi tự hỏi nếu cấu hình này phải là một mô hình/tài nguyên riêng biệt (tôi đã có khá nhiều trường trong mô hình người dùng của mình vì tôi đang sử dụng Authlogic và hầu hết các trường tùy chọn này).Tiểu sử của người dùng có phải là một mô hình riêng biệt không?

Ưu và khuyết điểm của việc sử dụng tài nguyên riêng biệt là gì?

+0

Xem thêm: http://softwareengineering.stackexchange.com/questions/241089/keep-user-and-user-profile-in-different-tables – Jon

Trả lời

2

Tôi sẽ giữ riêng biệt. Không phải tất cả người dùng của bạn đều muốn điền vào một tiểu sử, vì vậy, những người đó sẽ là các trường trống nằm trong bảng người dùng của bạn. Nó cũng có nghĩa là bạn có thể thay đổi các trường hồ sơ mà không thay đổi bất kỳ logic nào của mô hình người dùng của bạn.

4
  • Ưu điểm: Nó đơn giản hoá mỗi mô hình
  • Nhược điểm: Quản lý 2 cùng một lúc là một chút khó khăn hơn

Về cơ bản nó đi xuống đến lớn như thế nào người sử dụng và hồ sơ đang có. Nếu người dùng là 5 trường, và hồ sơ 3, không có điểm. Nhưng nếu người dùng là 12 lĩnh vực, và hồ sơ 20, sau đó bạn chắc chắn nên.

+0

Tại sao bạn nên "chắc chắn" chia chúng nếu chúng có nhiều lĩnh vực? – Aaron

0

Phụ thuộc vào chiều rộng của bảng người dùng hiện tại. Cơ sở dữ liệu thường giới hạn havea với số byte mà một recird có thể chứa. Tôi fyou là gần (hoặc trên mà bạn thường có thể làm gì nếu bạn có rất nhiều lĩnh vực với giá trị null) giới hạn, tôi sẽ thêm một bảng với một mối quan hệ một-to-một cho hiệu suất tốt hơn và ít khả năng của một kỷ lục đột nhiên không thể chèn được vì có quá nhiều dữ liệu cho kích thước hàng. Nếu bạn không ở gần giới hạn, thì thêm vào bảng exisiting.

4

Tôi nghĩ bạn sẽ được phục vụ tốt nhất khi đưa vào một mô hình riêng biệt. Hãy suy nghĩ về cách các mô hình tương ứng với các bảng cơ sở dữ liệu, và sau đó cách bạn đọc các mô hình đó cho các trường hợp sử dụng khác nhau mà ứng dụng của bạn hỗ trợ.

Nếu người dùng chỉ nhúng vào hồ sơ thực tế của mình một lần trong một lần nhưng mô hình Người dùng được truy cập thường xuyên, bạn chắc chắn nên biến nó thành một đối tượng riêng biệt với mối quan hệ một-một. Nếu dữ liệu hồ sơ là cần thiết mỗi khi dữ liệu Người dùng là cần thiết, bạn có thể muốn gắn chúng vào cùng một bảng.

Có thể vị trí là cần thiết mỗi khi bạn hiển thị người dùng (nói về nhận xét họ để lại), nhưng tiểu sử phải là một mô hình khác? Bạn sẽ phải tìm ra phân tích đúng, nhưng quy tắc chung là cấu trúc mọi thứ để bạn không phải lấy dữ liệu không được sử dụng ngay lập tức.

4

Tôi khuyên bạn nên giữ các cột hồ sơ trong Mô hình người dùng để rõ ràng và đơn giản. Nếu bạn thấy rằng bạn chỉ sử dụng một số trường nhất định, chỉ chọn các cột bạn cần sử dụng: chọn.

Nếu sau đó bạn thấy rằng bạn cần một bảng riêng biệt vì một số lý do (ví dụ: một người dùng có thể có nhiều tiểu sử) thì không cần nhiều công việc để tách chúng ra.

Tôi đã mắc sai lầm khi có hai bảng và không mua cho tôi bất kỳ thứ gì ngoài độ phức tạp bổ sung.

+0

Tôi đã có trải nghiệm giống hệt nhau. – Aaron

3

Người dùng "sở hữu" nhiều tài nguyên khác nhau trên trang web của bạn, chẳng hạn như nhận xét, v.v. Nếu bạn tách riêng tiểu sử khỏi người dùng thì đó chỉ là một tài nguyên nữa. Người dùng là tĩnh, trong khi hồ sơ sẽ thay đổi theo thời gian.

Tách nó ra cũng sẽ cho phép bạn dễ dàng duy trì lịch sử tiểu sử.

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