Tôi đã quen nhìn thấy các hàng của bảng có các cột như 'DeletingDate' trong đó và tôi không thích chúng. Khái niệm 'bị xóa' là mục nhập không nên được thực hiện ngay từ đầu. Thực tế, chúng không thể bị xóa khỏi cơ sở dữ liệu nhưng tôi không muốn chúng vào với dữ liệu nóng của tôi. Theo định nghĩa, các hàng bị xóa là dữ liệu lạnh trừ khi có người đặc biệt muốn xem dữ liệu bị xóa.
Hơn nữa, mọi truy vấn được viết phải loại trừ chúng một cách cụ thể và các chỉ mục cũng cần phải xem xét chúng.
Những gì tôi muốn thấy là một sự thay đổi ở cấp kiến trúc cơ sở dữ liệu và cấp độ ứng dụng: tạo một lược đồ có tên là 'đã xóa'. Mỗi bảng do người dùng xác định có một tương đương giống hệt nhau trong lược đồ 'đã xóa' với một siêu dữ liệu giữ trường bổ sung - người dùng đã xóa nó và khi nào. Khóa ngoại được yêu cầu phải được tạo.
Tiếp theo, xóa sẽ trở thành chèn-xóa. Đầu tiên, hàng cần xóa sẽ được chèn vào đối tác lược đồ 'đã xóa. Hàng trong câu hỏi trong bảng chính sau đó có thể bị xóa. Logic bổ sung, tuy nhiên, cần phải được thêm vào ở đâu đó dọc theo dòng. Vi phạm khóa nước ngoài có thể được xử lý.
Khóa ngoại phải được xử lý đúng. Đó là một thực tế xấu khi có một hàng bị xóa một cách hợp lý nhưng có chính / duy nhất có các cột trong các bảng khác đề cập đến nó. Điều này không nên xảy ra. Một công việc thông thường có thể loại bỏ các hàng góa phụ (các hàng có khóa chính không có tham chiếu trong các bảng khác mặc dù có khóa ngoại. Tuy nhiên, đây là logic nghiệp vụ.
Lợi ích tổng thể là giảm siêu dữ liệu trong bảng và cải thiện hiệu suất mà nó mang lại. Cột 'removeDate' nói rằng hàng này thực sự không nên ở đây, nhưng để thuận tiện, chúng tôi để nó ở đó và để truy vấn SQL xử lý nó. Nếu một bản sao của hàng đã xóa được giữ trong lược đồ 'đã xóa, thì bảng chính có dữ liệu nóng có tỷ lệ dữ liệu nóng cao hơn (giả sử nó được lưu trữ theo cách kịp thời) và ít cột siêu dữ liệu không cần thiết. Chỉ mục & truy vấn không còn cần phải xem xét lĩnh vực này. Kích thước hàng càng ngắn, càng có nhiều hàng được trang bị trên một trang, SQL Server có thể hoạt động nhanh hơn.
Nhược điểm chính là kích thước của hoạt động. Bây giờ có hai hoạt động thay vì một cũng như xử lý logic và xử lý lỗi bổ sung. Nó có thể dẫn đến khóa nhiều hơn so với cập nhật một cột nếu không sẽ mất. Giao dịch giữ các khóa trên bàn lâu hơn và có hai bảng liên quan. Xóa dữ liệu sản xuất, ít nhất là theo kinh nghiệm của tôi, là điều hiếm khi được thực hiện. Thậm chí, trong một trong các bảng chính, 7,5% trong số gần 100 triệu mục có một mục trong cột 'DeletingDate'.
Để trả lời cho câu hỏi, ứng dụng sẽ phải nhận thức được 'không phục hồi. Đơn giản chỉ cần thực hiện tương tự theo thứ tự ngược lại: chèn hàng từ lược đồ 'đã xóa' vào bảng chính và sau đó xóa hàng khỏi 'lược đồ đã xóa. Một lần nữa, một số xử lý logic & lỗi bổ sung là cần thiết để đảm bảo tránh các lỗi, sự cố với khóa ngoại và tương tự.