Không, điều đó làm cho quan hệ "một đến không hoặc một". Đó có phải là thứ bạn thực sự cần?
Nếu có , thì "giải pháp thứ hai" của bạn tốt hơn:
- nó đơn giản hơn,
- chiếm ít bộ nhớ hơn (và do đó làm cho bộ nhớ cache "lớn hơn")
- anh ta ít lập chỉ mục hơn để duy trì, điều này có lợi cho việc thao tác dữ liệu,
- và (vì bạn đang sử dụng InnoDB) tự nhiên cụm dữ liệu, vì vậy những người dùng ở gần nhau cũng sẽ có tài khoản của họ được lưu trữ gần nhau, điều này có thể có lợi cho việc định vị bộ nhớ cache và một số loại quét phạm vi nhất định.
BTW, bạn sẽ cần tạo accounts.id một số nguyên bình thường (không tự động tăng) để số này hoạt động.
Nếu không , xem bên dưới ...
Chà, "tốt nhất" là một từ bị quá tải, nhưng giải pháp "tiêu chuẩn" sẽ giống như trong bất kỳ cơ sở dữ liệu nào khác:đặt cả hai thực thể (người dùng và tài khoản trong trường hợp của bạn) trong cùng một bảng vật lý.
Về mặt lý thuyết, bạn có thể tạo FK vòng tròn giữa hai PK, nhưng điều đó sẽ yêu cầu hoãn lại các ràng buộc để giải quyết vấn đề con gà và quả trứng, rất tiếc không được hỗ trợ trong MySQL.
Tôi không có nhiều kinh nghiệm thực tế với công cụ tạo mô hình cụ thể đó, nhưng tôi đoán đó là vì nó là "một đến nhiều" nơi "nhiều" được giới hạn ở 1 bằng cách làm cho nó trở nên độc nhất. Hãy nhớ rằng "nhiều" không có nghĩa là "1 hoặc nhiều", nó có nghĩa là "0 hoặc nhiều", vì vậy phiên bản "giới hạn" thực sự có nghĩa là "0 hoặc 1".
Không chỉ trong chi phí lưu trữ cho trường bổ sung, mà còn cho chỉ mục phụ. Và vì bạn đang sử dụng InnoDB mà luôn nhóm các bảng , hãy cẩn thận rằng các chỉ mục phụ thậm chí còn đắt hơn trong các bảng được phân nhóm so với chúng trong các bảng dựa trên đống.
InnoDB yêu cầu chỉ mục trên các khóa ngoại.
