Tôi có 2 bảng sau trong MySQL: khách hàng (Id, FirstName, LastName ...) Bonus (Id, ID khách hàng, giá trị gia tăng, ...)Trong mối quan hệ One to One, tôi có nên bỏ một cột id của bảng không?
Mối quan hệ là một To-One-, mỗi khách hàng chỉ có một phần thưởng. (CustomerId là duy nhất trong Bảng Bonus)
Q: Tôi có nên bỏ cột Id của bảng Tiền thưởng không? (Tôi muốn biết lý do tại sao hoặc tại sao không)
tôi sẽ loại bỏ các coulmn Bonus.Id và tạo Bonus.CustomerId PK. Việc làm này sẽ loại bỏ sự cần thiết phải có một ràng buộc duy nhất trên cột Bonus.CustomerId, vì nó sẽ là một PK. Bất cứ ai nhìn vào bảng sẽ thấy rõ ràng từng người một mà không có tiền thưởng Bonus.Id coulmn. Bạn sẽ không cần một chỉ mục trên Bonus.CustomerId, chỉ mục PK sẽ là tất cả những gì bạn cần, vì vậy không gian đĩa và bộ nhớ cache bị lãng phí. Ngoài ra, nếu bạn cần FK vào bảng Tiền thưởng, bạn sẽ sử dụng giá trị CustomerId (PK mới), có thể được sử dụng để lấy lại bảng Khách hàng hoặc Tiền thưởng, không chỉ là Tiền thưởng.
nếu đó là một lần, tại sao lại có thêm bất kỳ bảng nào? thay vào đó, bạn có thể đặt "tiền thưởng" vào bảng khách hàng của mình.
(khác: yes, bạn có thể thả id của tiền thưởng-bảng, khách hàng-id là khóa chính và "id" là hoàn toàn không cần thiết)
mối quan hệ một-một là tốt khi hầu hết các hàng của bảng chính không cần một hàng nào cả trong bảng thứ hai. Ví dụ, bạn có một bảng "Person" chính và sau đó là bảng "DoctorInfo" một và một "StudentInfo" khác, vv .. bạn sẽ không muốn bao gồm tất cả các cột DoctorInfo hoặc StudentInfo trong "Người"? không phải tôi, tôi chia chúng ra thành một bảng một. –
Bạn cũng chia bảng thành một một khi độ dài hàng của bảng quá lớn để truy cập hiệu quả. Hoặc nếu dữ liệu sẽ hiếm khi được truy vấn và bảng chính sẽ được truy vấn thường xuyên. Hoặc bạn muốn giới hạn mức độ hiển thị của dữ liệu. – HLGEM
Đó là dư thừa, nhưng tôi không đồng ý với việc đưa mọi thứ vào một bảng, còn địa chỉ, ngay cả khi đó là một. Tôi thích làm cho bàn của tôi như tôi làm đối tượng của tôi, chỉ cần có. Như nhiều lớp/bảng như tôi cần. – Vlad
Tôi cho rằng đó không thực sự là một sự kiện trực tiếp bởi vì bạn có thể có Khách hàng mà không cần hàng thưởng. Các ràng buộc khóa ngoài kiểu SQL luôn là tùy chọn ở bên tham chiếu của bất kỳ mối quan hệ nào.
Tôi đồng ý cột Bonus.Id dường như hoàn toàn dư thừa.
Bạn nói đúng, không phải tất cả khách hàng đều có tiền thưởng. – Vlad
Cảm ơn bạn đã phản hồi, tôi thường thêm một cột id cho tất cả các bảng tôi tạo và tôi không nghĩ về nó quá nhiều, nhưng tôi bắt đầu tranh luận về nó với một đồng nghiệp của tôi, người đề nghị tôi thả nó. Tôi muốn có thêm ý kiến về vấn đề này trước khi tôi làm điều đó. – Vlad