Nhúng cấu trúc dữ liệu vào một trường có thể hoạt động đối với các trường hợp đơn giản nhưng nó ngăn bạn tận dụng cơ sở dữ liệu quan hệ. Cơ sở dữ liệu quan hệ được thiết kế để tìm, cập nhật, xóa và bảo vệ dữ liệu của bạn. Với một trường được nhúng có chứa dữ liệu wad-o của riêng nó (mảng, JSON, xml, v.v.), bạn có thể viết tất cả mã để tự mình thực hiện việc này.
Có những trường hợp trường nhúng có thể phù hợp hơn, nhưng đối với câu hỏi này làm ví dụ, tôi sẽ sử dụng một trường hợp nêu bật những ưu điểm của phương pháp tiếp cận bảng có liên quan.
Hãy tưởng tượng ví dụ về Người dùng và Bài đăng cho blog.
Đối với giải pháp bài đăng được nhúng, bạn sẽ có một bảng như thế này (mã psuedocode - đây có thể không phải là ddl hợp lệ):
create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}
Với các bảng có liên quan, bạn sẽ làm điều gì đó như
create table Users {
id int auto_increment,
name varchar(200)
}
create table Posts {
id auto_increment,
user_id int,
content text
}
Công cụ lập bản đồ quan hệ đối tượng (ORM) :Với bài đăng được nhúng, bạn sẽ viết mã theo cách thủ công để thêm bài đăng cho người dùng, điều hướng qua các bài đăng hiện có, xác thực chúng, xóa chúng, v.v. Với thiết kế bảng riêng biệt, bạn có thể tận dụng ActiveRecord (hoặc bất kỳ hệ thống quan hệ đối tượng nào mà bạn đang sử dụng) các công cụ cho việc này sẽ giúp mã của bạn đơn giản hơn nhiều.
Tính linh hoạt :Hãy tưởng tượng bạn muốn thêm trường ngày vào bài đăng. Bạn có thể làm điều đó với một trường nhúng, nhưng bạn sẽ phải viết mã để phân tích mảng của mình, xác thực các trường, cập nhật các bài đăng được nhúng hiện có, v.v. Với bảng riêng, việc này đơn giản hơn nhiều. Ngoài ra, giả sử bạn muốn thêm một Biên tập viên vào hệ thống của mình, người phê duyệt tất cả các bài đăng. Với ví dụ quan hệ, điều này thật dễ dàng. Như một ví dụ để tìm tất cả các bài đăng được chỉnh sửa bởi 'Bob' bằng ActiveRecord, bạn chỉ cần:
Editor.where(name: 'Bob').posts
Đối với mặt được nhúng, bạn sẽ phải viết mã để xem qua mọi người dùng trong cơ sở dữ liệu, phân tích cú pháp từng bài đăng của họ và tìm kiếm 'Bob' trong trường trình chỉnh sửa.
Hiệu suất :Hãy tưởng tượng rằng bạn có 10.000 người dùng với trung bình 100 bài đăng cho mỗi người. Bây giờ bạn muốn tìm tất cả các bài viết được thực hiện vào một ngày nhất định. Với trường được nhúng, bạn phải lặp lại mọi bản ghi, phân tích cú pháp toàn bộ mảng của tất cả các bài đăng, trích xuất ngày tháng và kiểm tra xem có phải bản ghi bạn muốn không. Điều này sẽ nhai cả cpu và ổ đĩa i / 0. Đối với cơ sở dữ liệu, bạn có thể dễ dàng lập chỉ mục trường ngày tháng và lấy ra các bản ghi chính xác mà bạn cần mà không cần phân tích cú pháp mọi bài đăng từ mọi người dùng.
Tiêu chuẩn :Sử dụng cấu trúc dữ liệu cụ thể của nhà cung cấp có nghĩa là việc di chuyển ứng dụng của bạn sang một cơ sở dữ liệu khác có thể là một khó khăn. Postgres dường như có một tập hợp các kiểu dữ liệu phong phú, nhưng chúng không giống như MySQL, Oracle, SQL Server, v.v. Nếu bạn gắn bó với các kiểu dữ liệu tiêu chuẩn, bạn sẽ có thời gian dễ dàng hơn nhiều khi hoán đổi các phần phụ trợ.
Đây là những vấn đề chính mà tôi đề cập ở trên. Tôi đã phạm phải sai lầm này và phải trả giá cho nó, vì vậy nếu không có lý do siêu thuyết phục, tôi làm khác đi, tôi sẽ sử dụng bảng riêng.
