2010-03-26 64 views
14

Ưu điểm của việc sử dụng mối quan hệ một-một với trái ngược với việc lưu trữ tất cả dữ liệu trong một bảng là gì? Tôi hiểu và tận dụng từng người một, nhiều người và nhiều người, nhưng việc thực hiện mối quan hệ một-một có vẻ như một công việc tẻ nhạt và không cần thiết, đặc biệt nếu bạn sử dụng đặt tên quy ước đối với các đối tượng liên quan (php) đối với các bảng cơ sở dữ liệu.Ưu điểm của việc sử dụng mối quan hệ một-một là gì? (MySQL)

Tôi không thể tìm thấy bất kỳ thứ gì trên mạng hoặc trên trang web này có thể cung cấp ví dụ thực tế tốt về mối quan hệ một-một. Lúc đầu, tôi nghĩ rằng có thể hợp lý để tách 'người dùng' thành hai bảng, một bảng chứa thông tin công khai như 'về tôi' cho các trang hồ sơ và một thông tin cá nhân như đăng nhập/mật khẩu, v.v. thông qua tất cả các rắc rối của việc sử dụng JOINS không cần thiết khi bạn chỉ có thể chọn trường nào để chọn từ bảng đó? Nếu tôi đang hiển thị trang hồ sơ của người dùng, rõ ràng tôi sẽ chỉ SELECT id, tên người dùng, email, aboutme, vv và không phải là các trường có chứa thông tin cá nhân của họ.

Bất cứ ai quan tâm đến việc khai sáng cho tôi một số ví dụ thực tế về mối quan hệ một-một?

Trả lời

6

Tôi đã sử dụng mối quan hệ 1-1 để mở rộng một số tính năng trong các ứng dụng hiện có mà không ảnh hưởng đến cấu trúc db của ứng dụng. Đây là cách không phô trương để mở rộng các bảng db hiện tại.

Lý do khác để sử dụng mối quan hệ một đối một là triển khai Thừa kế bảng lớp, trong đó mỗi lớp trong cấu trúc phân cấp có bảng và đối tượng có hàng tương ứng trong lớp bảng của mình bảng, trong bảng ông bà lớp và vân vân.

Xem, ví dụ, thuyết 2 Class Table Inheritance Page

+1

-1 để nói rằng sử dụng các mẫu trang trí trong cơ sở dữ liệu quan hệ là một ý tưởng hay. – symcbean

+5

Có, tôi có nghĩa là mở rộng theo ý nghĩa được đưa ra bởi byronh. Tuy nhiên, tôi không nói đó là "một ý tưởng hay", tôi chỉ nói đó có thể là một lý do. Nếu một điều tốt hay không nó cũng phụ thuộc vào ngữ cảnh. Đôi khi tôi không muốn và tôi không thể thay đổi db của bên thứ ba, vì vậy tôi "mở rộng" các bảng đó với mối quan hệ một đến một –

+0

Có, cũng lưu ý rằng ALTER TABLE trên các bảng lớn (hàng chục triệu hàng) để thêm cột, có thể mất rất nhiều thời gian (giờ). Trong khi đó bảng bị khóa và các quản trị viên hệ thống có thể tỉnh táo trong đêm ... – Qlimax

9

Có thể sử dụng khi một phần thông tin là tùy chọn. Bằng cách này, bạn không cần phải có một loạt các trường nullable trong một bảng lớn, nhưng có thể tách nó một cách hợp lý vào bảng bắt buộc và một bảng tùy chọn.

Sử dụng khác là khi một số dữ liệu được chia sẻ với các bảng khác nhau. Ví dụ: giả sử bạn có một trang web nơi bạn bán các bộ phận máy tính. Bạn có thể đặt các chi tiết mà tất cả các thành phần chia sẻ thành ví dụ. "bộ phận" bảng, nhưng đặt các chi tiết cụ thể trong "bo mạch chủ", "cpus", vv mà sẽ chỉ sử dụng bảng phần với mối quan hệ một-một.

1

Công cụ cơ sở dữ liệu có thể phải tải toàn bộ hàng vào bộ nhớ để lấy dữ liệu từ chúng, ngay cả khi chỉ có một nhóm nhỏ các trường đang được đọc. Ít trường hơn mỗi hàng nghĩa là nhiều hàng hơn trên mỗi trang có nghĩa là ít quyền truy cập đĩa hơn.

+0

Nếu bạn sử dụng một công cụ cơ sở dữ liệu thích hợp, và bạn soạn sql và chỉ mục của bạn một cách khôn ngoan, điều này không phải là trường hợp. – Whakkee

+0

Nếu bạn sử dụng MySQL (MyISAM/InnoDB) hiệu suất sẽ được thực hiện cho bất kỳ điều gì khác hơn là chỉ một phím SELECT.Vùng bảng càng lớn, càng cần nhiều bộ nhớ để tìm nạp dữ liệu được yêu cầu. Cũng UPDATE hiệu suất mất một hit lớn. – Jacco

6

Dưới đây là hai, tôi chắc chắn rằng những người khác sẽ gửi hơn

  • bạn muốn mở rộng một bảng hiện có mà không thực sự thay đổi bàn. Có lẽ nó đã được cung cấp bởi một nhà cung cấp bên thứ ba và bạn muốn giữ cho các phần mở rộng của bạn được phân tách bằng cách đơn giản có một bảng thứ hai chia sẻ cùng một khóa.
  • có thể có các cột chiều rộng cố định trong bảng được truy cập thường xuyên và các cột biến không. Trong trường hợp này, có thể có hiệu quả đạt được từ việc có một bảng với độ dài hàng cố định cho các công cụ thường xuyên, với một bảng phụ cho mọi thứ khác.

Ngoài ra, khi bình thường hóa cơ sở dữ liệu, hãy nói đến 3rd Normal Form (3NF) bạn có thể thấy các cột không thực sự "về" khóa và cần được kéo ra một bảng riêng biệt.

0

Chúng tôi đã sử dụng "một mối quan hệ" khi chúng tôi cần mở rộng một trong các bảng của chúng tôi với too many fields (96 trường!); vì vậy, chúng tôi tạo ra một bảng khác và đặt mọi lĩnh vực mới bên trong nó.

Dù sao, một cách tiếp cận tôi thích là:

Table_Base: 
    ID 
    MANDATORY_FIELD 
Table_Option: 
    ID 
    OPTIONAL_FIELD 
5

Cụ thể ví dụ của bạn: Bạn không muốn thông tin người dùng như tên và địa chỉ lưu trữ trong bảng tương tự như các thông tin đăng nhập và mật khẩu, bởi vì đây cách bạn có thể cấp cho ai đó quyền trong tổ chức của bạn trên bảng thông tin người dùng chứ không phải trên bảng dữ liệu đăng nhập.Tôi không đồng ý với những người khác về chủ đề "quá nhiều trường cho một bảng". Nếu có nhiều trường và bạn không cần tất cả chúng trong biểu mẫu hoặc báo cáo của mình, bạn có thể chọn chỉ các trường bạn cần với sql hoặc thậm chí sử dụng chế độ xem để đảm bảo bạn không nhận được quá nhiều dữ liệu.

+0

Bạn cũng có thể cấp quyền truy cập vào các cột cụ thể thay vì toàn bộ bảng. Nhưng bảng (không chỉ là tế bào) có một hit hiệu suất. Nếu bạn không chọn tất cả các trường, vùng bảng sẽ vẫn phải được nạp vào bộ nhớ; điều này không khác biệt đối với lượt xem. Ngoại lệ duy nhất cho quy tắc này là nếu dữ liệu được yêu cầu có thể được truy lục trực tiếp từ chỉ mục khóa. – Jacco

1

Trong OO bạn có kế thừa. Vì vậy, bạn có thể có một bảng chứa dữ liệu của đối tượng cha và các bảng khác có chứa các trường dành riêng cho trẻ em.

4

Lý do phổ biến nhất là rằng mối quan hệ có thể không bắt buộc. tức là có một tập hợp các thuộc tính áp dụng cho mọi thực thể cơ sở nhưng một số thuộc tính chỉ áp dụng cho một tập hợp con. Một lý do hợp lệ khác để thực hiện điều này là kiểm soát quyền truy cập - bạn có thể có một bảng khách hàng được sử dụng trong suốt ứng dụng của bạn, và mặc dù mỗi khách hàng đều có mật khẩu và thẻ tín dụng, bạn có thể muốn hạn chế quyền hiển thị/cập nhật.

Nhận xét của Marga Keuvelaar về câu trả lời của Ignacio Vazquez-Abrams là sai. Bạn có thể làm giảm tác động bằng cách sử dụng DML/DDL tốt hơn nhưng không phải trong mọi trường hợp. Tuy nhiên, bạn đang giao dịch một cách minh bạch về mô hình dữ liệu chống lại các lợi ích hiệu suất - mà luôn luôn cần được xem xét cẩn thận.

C.

+0

Nhận xét được đề cập trong câu trả lời này hiện đã biến mất. – Cypher

0

Ngoài những gì đã được nói,

một số cột có thể có khác nhau "giải phóng mặt bằng an ninh" yêu cầu hơn những người khác. Ví dụ. tên của một nhân viên có thể "công khai hơn một chút" so với mức lương của anh ta. Bây giờ, bảo mật cấp cột thường không được thực thi bởi DBMS, nhưng bảo mật mức bảng thường là.

Vì vậy, bằng cách chọn ra mức lương trong một bảng riêng, bạn tự mình mua khả năng thực hiện các yêu cầu bảo mật của người dùng bằng cách sử dụng các cơ sở bảo mật của DBMS.

0

Một điều nữa dựa trên kinh nghiệm của tôi chưa được đề cập:

Tách thành hai bảng cũng giúp tạo lớp Mô hình của bạn. Cho phép nói rằng bạn có bảng khách hàng và bảng DriverLicense và mối quan hệ một-một giữa chúng. Nếu bạn sử dụng khung thực thể, tôi đặt cược nó sẽ tốt hơn nếu bạn có hai bảng riêng biệt, vì bạn có thể có hai lớp mô hình trong ứng dụng của bạn, lớp Customer và DriverLicense. Bằng cách này, khung thực thể sẽ giúp bạn thêm thông tin Giấy phép Trình điều khiển mới sau này cho một khách hàng hiện có hoặc xóa và cập nhật nó. Tóm lại, xem xét khía cạnh Phát triển Web, tôi tin rằng nếu họ là hai thực thể riêng biệt, họ nên có bảng riêng của họ ngay cả khi họ có mối quan hệ một-một.

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