Phản vật chất?
Trong trường hợp phổ biến, bảng thứ hai là chống mẫu trong bối cảnh thiết kế cơ sở dữ liệu. Và, thậm chí, nó có tên cụ thể: Thực thể-Thuộc tính-Giá trị (EAV). Có một số trường hợp, khi sử dụng thiết kế này là hợp lý, nhưng đó là những trường hợp hiếm hoi - và thậm chí có thể tránh được.
Tại sao EAV kém
Hỗ trợ toàn vẹn dữ liệu
Mặc dù thực tế, cấu trúc như vậy có vẻ "linh hoạt" hoặc "tiên tiến" hơn, thiết kế này có điểm yếu.
- Không thể tạo thuộc tính bắt buộc . Bạn không thể đặt một số thuộc tính là bắt buộc, vì thuộc tính hiện được lưu trữ dưới dạng hàng - và dấu hiệu duy nhất cho thấy thuộc tính chưa được đặt - là hàng tương ứng không có trong bảng. SQL sẽ không cho phép bạn tạo ràng buộc như vậy một cách nguyên bản - do đó, bạn sẽ phải kiểm tra điều đó trong ứng dụng - và vâng, truy vấn bảng của bạn mỗi lần
- Kết hợp các loại dữ liệu . Bạn sẽ không thể sử dụng các kiểu dữ liệu chuẩn SQL. Bởi vì cột giá trị của bạn phải là "siêu loại" cho tất cả các giá trị được lưu trữ trong đó. Điều đó có nghĩa là - nói chung, bạn sẽ phải lưu trữ tất cả dữ liệu dưới dạng chuỗi thô . Sau đó, bạn sẽ thấy khó khăn như thế nào khi làm việc với ngày tháng như với chuỗi, truyền kiểu dữ liệu mỗi lần, kiểm tra tính toàn vẹn của dữ liệu, chẳng hạn
- Không thể thực thi quyền xâm nhập tham chiếu . Trong tình huống bình thường, bạn có thể sử dụng khóa ngoại để hạn chế các giá trị của mình theo những giá trị đó, được xác định trong bảng mẹ. Nhưng không phải trong trường hợp này - đó là vì tính toàn vẹn tham chiếu được áp dụng cho mỗi hàng trong bảng, nhưng không áp dụng cho các giá trị hàng. Vì vậy - bạn sẽ mất lợi thế này - và đó là một trong những điều cơ bản trong mối quan hệ DB
- Không thể đặt tên thuộc tính . Điều đó có nghĩa là - bạn không thể hạn chế tên thuộc tính ở cấp DB một cách chính xác. Ví dụ:bạn sẽ viết
"customer_name"làm tên thuộc tính trong trường hợp đầu tiên - và một nhà phát triển khác sẽ quên điều đó và sử dụng"name_of_customer". Và .. không sao cả, DB sẽ vượt qua điều đó và bạn sẽ kết thúc với hàng giờ đồng hồ để gỡ lỗi trường hợp này.
Tái tạo hàng
Ngoài ra, việc tái cấu trúc hàng sẽ rất tệ trong trường hợp phổ biến. Ví dụ:nếu bạn có 5 thuộc tính - đó sẽ là 5 bảng tự JOIN -S. Quá tệ cho trường hợp đơn giản - thoạt nhìn - như vậy. Vì vậy, tôi thậm chí không muốn tưởng tượng bạn sẽ duy trì 20 thuộc tính như thế nào.
Nó có thể được biện minh không?
Quan điểm của tôi là - không. Trong RDBMS sẽ luôn có cách để tránh điều này. Thật kinh khủng. Và nếu EAV được dự định sử dụng, thì lựa chọn tốt nhất có thể là không quan hệ cơ sở dữ liệu.
