Thiết kế lược đồ & ORM

Jan 05 2023
Bất kỳ cơ sở dữ liệu nào cũng có 2 loại bảng — kích thước và dữ kiện: Khi thiết kế lược đồ cơ sở dữ liệu, một số nguyên tắc sau đây sẽ giúp thực hiện đúng. Đầu tiên bình thường Bất kể cơ sở dữ liệu sẽ là SQL hay NoSQL, sẽ rất hữu ích khi nghĩ về Thực thể/Đối tượng & do đó, các bảng một lần từ phối cảnh lược đồ được chuẩn hóa.

Bất kỳ cơ sở dữ liệu nào cũng có 2 loại bảng - kích thước và sự kiện:

  1. Kích thước là các bảng cấu hình. Các bảng này không được thay đổi thường xuyên và thường là một giá trị ảnh chụp nhanh hiện tại duy nhất (có thể có một số thay đổi trong lịch sử - được trình bày chi tiết bên dưới). Các hoạt động phổ biến nhất là chỉnh sửa bảng. Người ta cũng có thể coi đây là Config hoặc Masters.
  2. Sự kiện là các bảng tăng gần như tuyến tính theo thời gian. Thông thường, các thực thể này được tạo thường xuyên theo thời gian, các bản cập nhật cho các sự kiện được tạo không phổ biến và thường tham khảo Thứ nguyên để biết thêm ngữ cảnh.

Khi thiết kế lược đồ cơ sở dữ liệu, một số hướng dẫn sau đây sẽ giúp bạn thực hiện đúng.

bình thường đầu tiên

Bất kể cơ sở dữ liệu sẽ là SQL hay NoSQL, sẽ rất hữu ích khi nghĩ về Thực thể/Đối tượng & do đó, các bảng một lần từ phối cảnh lược đồ được chuẩn hóa. Lược đồ được chuẩn hóa mang lại sự rõ ràng về các thực thể, mối quan hệ và trường. Việc không chuẩn hóa hoặc chuyển đổi sang NoSQL từ điều này có thể đơn giản và có thể là một thiết kế có ý thức.

Phản chiếu các thực thể trong thế giới thực

Ngay cả khi trường hợp sử dụng/báo cáo không rõ ràng, các thực thể lược đồ phải phản ánh trường hợp sử dụng trong thế giới thực. Một lược đồ như vậy thường mạnh mẽ.

Bất kỳ trường hợp nào sau đây thường là các trường hợp để xác định và tạo các thực thể khác nhau và do đó là các bảng:

  1. Các thực thể riêng biệt một cách hợp lý có thể tồn tại độc lập & có khả năng không có bất kỳ liên kết nào với nhau — ví dụ: bộ dữ liệu & trạm
  2. Có mối quan hệ nhiều-nhiều hoặc mối quan hệ một-nhiều với nhau — ví dụ: đối với một công ty thương mại điện tử, đơn đặt hàng & khách hàng.

Nếu có một trường đang được sử dụng trong truy vấn, tìm kiếm hoặc sắp xếp, hãy thêm chỉ mục cho trường đó theo mặc định. Các chỉ mục đơn giản nên được bật cho các trường này theo mặc định vì chúng có lợi ích tối đa. Việc không thêm chỉ mục phải là lựa chọn có ý thức, không phải trạng thái mặc định.

Sử dụng đúng loại trường

  1. Kiểu liệt kê so với kiểu chuỗi đối với các trường có tập giá trị tùy chọn cố định: Kiểu liệt kê được triển khai dưới dạng byte, do đó chiếm ít dung lượng hơn (ví dụ: byte dài 1–4 byte/byte dài/int so với chuỗi 128 byte), nhanh hơn/nhanh hơn trên các chỉ mục & tìm kiếm. Đối với các bảng lớn, các yêu cầu về không gian và hiệu suất cộng lại. Sử dụng kiểu liệt kê theo mặc định.
  2. Loại khóa chính (ID): Hiệu suất & lưu trữ khôn ngoan — bạn luôn nên sử dụng khóa có kích thước cố định — tức là số nguyên hoặc UUID.
  3. Các trường bảng chung: Một số trường được đề xuất trong tất cả các thực thể ORM có thể thay đổi — tức là created_at, updated_at, created_by, updated_by. Ngoài ra, đối với các thực thể thường có liên kết khóa ngoài và hiếm khi bị xóa, chúng tôi đề xuất sử dụng xóa mềm.

Truy vấn của Drishti có thể phức tạp, liên quan đến nhiều phép nối. Cơ sở dữ liệu được tối ưu hóa để kết nối và tính toán trong bộ nhớ. Bất cứ khi nào có thể, hãy chạy các phép nối hoặc tính toán này trong cơ sở dữ liệu — thông qua các bổ sung cho lớp ORM, truy vấn phù hợp hoặc thiết kế lại lược đồ. Theo nguyên tắc ngón tay cái, người ta chỉ nên xem xét các phép nối kết quả lớn trong mã ứng dụng khi cơ sở dữ liệu không thể thực hiện việc đó trong bộ nhớ — ví dụ: đối với các phép nối cơ sở dữ liệu chéo.

Khi nào thêm bảng lịch sử?

Bất kỳ hệ thống dựa trên giao dịch nào cũng cần ghi nhật ký cơ bản về tất cả các thay đổi đối với các thực thể chính. Điều này đặc biệt áp dụng cho các bảng Thứ nguyên, vì chúng được định cấu hình/sửa đổi thông qua API.

Có 2 cách để duy trì chúng:

  1. Duy trì một bản tóm tắt chung cho thay đổi thuộc tính, trong đó mọi hàng trong lịch sử thay đổi này trỏ đến loại thực thể, thuộc tính, id thực thể, giá trị cũ và giá trị mới. Ưu điểm: Không yêu cầu bảng mới cho mỗi thực thể.
  2. Duy trì bảng lịch sử thực thể cho mọi thay đổi về giá trị. Ưu điểm: Ghi lại dưới dạng các giao dịch nguyên tử thay đổi nhiều trường, hiển thị thay đổi đó cho khách hàng. Do đó, khái niệm về một giao dịch được thực hiện bởi người dùng trên giao diện người dùng hoặc cách khác được giữ nguyên.