Làm cho các mối quan hệ trong Cơ sở dữ liệu làm cho chúng chậm lại

Question

Tôi vừa bắt đầu thực tập tại một nhà phần mềm nhỏ và tôi đang làm việc trên một hệ thống ERP. Đội trưởng của tôi đã cấm tôi tạo ra bất kỳ mối quan hệ nào trong cơ sở dữ liệu. Vì đây là bài tập của tôi nên tôi đã bị sốc vì cho đến bây giờ tôi đã đọc rằng các mối quan hệ là cần thiết để đảm bảo tính toàn vẹn của dữ liệu. Đội trưởng của tôi nói với tôi rằng chúng tôi có thể thực thi tính toàn vẹn dữ liệu ở giao diện người dùng. Sau khi một số nghiên cứu tôi phát hiện ra rằng các phím nước ngoài làm cho db chậm hơn nhưng lập chỉ mục các phím nước ngoài có thể tăng hiệu suất.

Câu hỏi

• Làm thế nào làm cho các phím nước ngoài chi phí hiệu suất?
• Đảm bảo tính toàn vẹn dữ liệu ở giao diện người dùng không hiệu quả về chi phí? Nếu có thì điều gì sẽ là sự khác biệt giữa chi phí hiệu suất của các khóa ngoại tệ cơ sở dữ liệu và chi phí bằng cách đảm bảo các quy tắc toàn vẹn dữ liệu ở mặt trước?
• Nếu các khóa ngoài của cơ sở dữ liệu làm cho cơ sở dữ liệu chậm hơn, và các quy tắc toàn vẹn ở lớp ứng dụng là một cách tiếp cận tốt hơn thì tại sao cơ sở dữ liệu quan hệ của chúng ta được phép có khóa ngoài? Sau khi thực hiện một số nghiên cứu và đọc các mối quan hệ làm cho db chậm hơn, tôi đã cố gắng nghĩ về một kịch bản đảm bảo tính toàn vẹn dữ liệu ở lớp ứng dụng là không thể, nhưng tôi không thể nghĩ ra được, Nếu ai đó có thể giải thích điều này, .

• Nếu indexing phím nước ngoài tăng hiệu suất sau đó điều gì sẽ tốt hơn ra khỏi hai dưới đây:

  1.) Bảo đảm nguyên tắc toàn vẹn dữ liệu ở lớp ứng dụng

  2.) Indexing Keys nước ngoài

Cảm ơn bạn đã trợ giúp.

Answer 1

Nói chung, mô hình dữ liệu của bạn càng phức tạp, hiệu suất của bạn càng lớn. Tuy nhiên, trừ khi cơ sở dữ liệu của bạn rất lớn, tài nguyên phần cứng của bạn rất tối thiểu, hoặc các truy vấn của bạn rất phức tạp, có thể bạn sẽ không bị cản trở bằng cách thêm các mối quan hệ được thực thi vào cơ sở dữ liệu của mình. Đó rõ ràng là một tuyên bố chủ quan, nhưng "hiệu suất chấp nhận được" là một khái niệm rất chủ quan sẽ thay đổi từ dự án đến dự án.

Trái tim của lập luận của đồng nghiệp của bạn là đúng, tuy nhiên, và dưới đây là một vài lý do tại sao:

• Mỗi khi bạn viết một kỷ lục mới chứa một chìa khóa nước ngoài hoặc tiểu học, cơ sở dữ liệu phải xem xét rằng không ai trong số các ràng buộc của khóa bị vi phạm. Các cột chính cũng được lập chỉ mục, vì vậy các chỉ mục phải được cập nhật khi các bản ghi được thêm vào.
• Mỗi khi bạn xóa bản ghi chứa hoặc tham chiếu bằng khóa ngoại, các ràng buộc được kiểm tra và việc xóa có thể xếp vào các bảng được tham chiếu. Các chỉ mục cũng phải được cập nhật khi các bản ghi bị xóa.
• Hoạt động CRUD của tất cả các loại chậm đáng kể khi ngày càng có nhiều bảng được tham gia vào các truy vấn. Các bảng lớn hơn, càng nhiều bản ghi phải được tham gia và việc thực thi càng chậm.

Điều đó nói rằng, đây là lý do tại sao những lập luận chủ yếu là không quan trọng:

• Indexing cắt xuống đáng kể thời gian thực hiện truy vấn, đặc biệt là nếu thực hiện tốt.Điều quan trọng là lập chỉ mục các bảng theo cách tận dụng cấu trúc của các truy vấn sẽ chạy với nó. Trừ khi phần cứng cơ sở dữ liệu của bạn là xương trần, các hoạt động cần thiết để thực thi toàn vẹn dữ liệu và ràng buộc mối quan hệ có thể sẽ chạy nhanh hơn nhiều ở mặt sau so với giao diện người dùng. Điều này đặc biệt đúng nếu kiểm tra ràng buộc đang xảy ra trong một ứng dụng khách hơn là trên một máy chủ.
• Kiểm tra tính toàn vẹn dữ liệu dựa trên khách hàng dễ bị lỗi hơn nhiều so với các ràng buộc về cơ sở dữ liệu. Có, nếu mã của bạn là hoàn hảo nó sẽ chạy chỉ là tốt, nhưng phần mềm RDBMS được thiết kế cho loại điều này và nó là vô cùng đơn giản để thực hiện.
• Kiểm tra tính toàn vẹn dữ liệu dựa trên khách hàng có thể dẫn đến các sự cố đồng bộ hóa dữ liệu. Hãy suy nghĩ hai người tại các địa điểm khác nhau cố gắng sửa đổi một kỷ lục duy nhất. Nhưng có lẽ đồng thời dữ liệu cuối cùng sẽ đủ nếu tốc độ làm sáng nhanh là mối quan tâm chính của bạn.

Tất cả đều phụ thuộc vào các đặc điểm của RDBMS và dự án của bạn, nhưng là các quy tắc chung của ngón tay cái. Nói chung, tôi sẽ nói rằng trừ khi cơ sở dữ liệu của bạn quá lớn để thực thi các mối quan hệ trở nên chậm chạp, hoặc mô hình của bạn đơn giản đến mức các mối quan hệ là vô nghĩa (trong trường hợp này, tại sao bạn lại sử dụng RDBMS?), Tốt hơn là cho phép dữ liệu các ràng buộc về tính toàn vẹn và mối quan hệ.