Có ví dụ về phương pháp không CRUD?

Tôi là một lập trình viên nhưng cũng đã làm việc như một nhà lưu trữ. Là nhà lưu trữ, rất nhiều về việc giữ dữ liệu.

Tôi thường tranh cãi với các đồng nghiệp khi nói đến hoạt động trên dữ liệu. Tôi không thích chữ U và chữ D trong CRUD quá nhiều. Thay vào đó, cập nhật một bản ghi tôi thích thêm một bản ghi mới và có một tham chiếu đến bản ghi cũ. Bằng cách đó bạn xây dựng một lịch sử thay đổi. Tôi cũng không thích xóa hồ sơ mà chỉ đánh dấu chúng là không hoạt động.

Có một thuật ngữ cho điều này? Về cơ bản chỉ tạo và đọc dữ liệu? Có ví dụ về phương pháp này?

Đánh dấu một bản ghi là đã xóa được gọi là xóa mềm . Tôi chưa bao giờ nghe một cụm từ thay thế để cập nhật, nhưng tôi đoán đó là nguyên nhân khiến bạn xóa mềm bản ghi cũ và tạo một bản ghi mới.

Cần lưu ý, đây là một kỹ thuật gây tranh cãi. Xem liên kết: Con vs Pro .

Một trong những vấn đề với việc giữ lại lịch sử thay đổi là nó làm xáo trộn cơ sở dữ liệu và có thể tăng đáng kể kích thước của nó (tùy thuộc vào mô hình sử dụng). Vì vậy, một ý tưởng tốt sẽ là lưu trữ dấu vết kiểm toán ở một nơi riêng biệt và giữ cho các bảng ứng dụng thực tế chỉ được điền với dữ liệu liên quan. Vì vậy, mỗi lần thao tác CRUD được ứng dụng thực hiện, thay đổi được ghi lại trong các bảng kiểm toán và thao tác CRUD được thực hiện trên các bảng ứng dụng (không xóa mềm).

Bằng cách tách riêng đường kiểm toán sẽ cung cấp cho bạn một kho lưu trữ dữ liệu nguyên sơ để ứng dụng của bạn tương tác, trong khi vẫn giữ lại lịch sử thay đổi nếu bạn cần. Bây giờ bạn cũng có thể lưu trữ dấu vết kiểm toán một cách riêng biệt hoặc thậm chí phá hủy nó, tùy thuộc vào yêu cầu kinh doanh của bạn.

EventSourcing âm thanh thích mẫu mà bạn có thể tìm kiếm.

Chúng ta hãy lấy một ví dụ bằng cách sử dụng một đối tượng "xe hơi" đơn giản mà chúng ta muốn theo dõi màu sắc của (mã giả C # sau).

public class Car {
  public string Color { get; set; }
  public Car() { this.Color = "Blue"; }
}

Với việc thực hiện CRUD khi chúng tôi cập nhật màu xe, màu trước đó sẽ bị mất.

MyCar.Color = "Red";
MyCar.Save();  // Persist the update to the database and lose the previous data

Việc mất thông tin này đối với tôi giống như những gì bạn muốn tránh nhất (do đó không thích cập nhật và xóa một phần của mẫu CRUD).

Nếu chúng ta viết lại lớp xe thay vì trả lời các sự kiện khi cập nhật thay đổi thì nó có thể giống như thế này:

public class Car {
    public string Color { get; private set; } // Cannot be set from outside the class

    public void ApplyEvent(CarColorChangedEvent e) {
      this.Color = e.Color;
    }
}

Bây giờ chúng ta sẽ cập nhật màu sắc của đối tượng này như thế nào? Chúng tôi có thể tạo một sự kiện CarColorChanged !

var evnt = new CarColorChangedEvent("Red");
MyEventStore.save(evnt);
MyCar.ApplyEvent(evnt);

Lưu ý thiếu lưu trữ trên đối tượng mô hình thực tế? Đó là bởi vì thay vì duy trì mô hình trực tiếp, chúng tôi vẫn duy trì các sự kiện đưa mô hình về trạng thái hiện tại. Những sự kiện này nên được bất biến .

Bây giờ, hãy nhanh chóng chuyển tiếp và thay đổi màu sắc thêm một vài lần nữa:

var evnt = new CarColorChangedEvent("Green");
MyEventStore.save(evnt);
MyCar.ApplyEvent(evnt);

var evnt = new CarColorChangedEvent("Purple");
MyEventStore.save(evnt);
MyCar.ApplyEvent(evnt);

Nếu chúng ta xem xét bộ lưu trữ sự kiện của chúng tôi (có thể là cơ sở dữ liệu quan hệ, dựa trên tệp, v.v.), chúng ta sẽ thấy một loạt các sự kiện liên quan đến đối tượng xe hơi của mình:

CarColorChangedEvent => Red
CarColorChangedEvent => Green
CarColorChangedEvent => Purple

Nếu chúng ta muốn xây dựng lại đối tượng xe hơi đó, chúng ta có thể làm điều đó chỉ bằng cách tạo một đối tượng xe mới và áp dụng các sự kiện từ cửa hàng sự kiện của chúng ta vào đối tượng nói trên.

var MyCar = new Car();
var events = MyDatabase.SelectEventsForCar("CarIdentifierHere");
foreach(var e in events) {
  MyCar.ApplyEvent(e);
}
Console.WriteLine(MyCar.Color); // Purple

Với luồng sự kiện, chúng ta có thể đưa trạng thái của xe về khoảng thời gian trước đó chỉ bằng cách tạo một đối tượng xe mới và chỉ áp dụng các sự kiện mà chúng ta muốn:

var MyCar = new Car();
var event = MyDatabase.GetFirstEventForCar("CarIdentifierHere");
MyCar.ApplyEvent(e);
Console.WriteLine(MyCar.Color); // Red

Tìm nguồn cung ứng sự kiện là con đường để đi, và bạn nên xem Greg Young nói gì về điều đó.

http://goodenoughsoftware.net/

Ngoài ra hãy xem bản trình bày này trên Cơ sở dữ liệu của anh ấy (Cửa hàng sự kiện). Bạn có thể tìm thấy các video khác là tốt.

http://oredev.org/2012/simes/a-deep-look-into-the-event-store

Tôi sẽ không đi đến câu trả lời "xóa mềm" trừ khi bạn đặc biệt cần có thể tìm kiếm các mục đã bị xóa, nhưng sau đó bạn không nên nghĩ chúng là đã xóa mà được lưu trữ. Tôi nghĩ thuật ngữ này khá quan trọng ở đây.

Tôi cũng không muốn duy trì "bảng phiên bản". Tất cả các "bảng phiên bản" tôi từng thấy (bao gồm cả tôi đang cố gắng dọn dẹp vào lúc này - 7 năm dữ liệu bị hỏng vì lỗi ... và không có cách nào lấy lại được mặc dù chúng tôi có dữ liệu lịch sử .. . bởi vì điều đó cũng giống như tham nhũng) cuối cùng bị hỏng do lỗi trong mã và cuối cùng bạn vẫn bị mất dữ liệu vì bạn không thể quay lại và tạo lại dữ liệu mà tham nhũng gây rối.

Với mô hình tìm nguồn cung ứng sự kiện, đây không phải là trường hợp. Bạn luôn có thể phát lại chính xác những gì người dùng đã làm. Đây là sự khác biệt rất quan trọng giữa CRUD và Tìm nguồn sự kiện. Kiến trúc Tìm nguồn sự kiện lưu các sự kiện trong kho lưu trữ sự kiện và không phải đối tượng dữ liệu hoặc đối tượng mô hình miền. Một sự kiện có thể dễ dàng tác động đến nhiều đối tượng. Chỉ cần nghĩ về một giải pháp giỏ hàng nơi bạn chuyển đổi từng mặt hàng trong giỏ hàng thành một đơn đặt hàng thực tế. Một sự kiện tác động đến tất cả các đối tượng vật phẩm cũng như các đối tượng giỏ hàng, được chuyển thành đối tượng đặt hàng.

Nếu bạn giữ một bản sao được phiên bản của mỗi hàng trong mỗi bảng trong cơ sở dữ liệu, thì hãy tưởng tượng sự kinh hoàng của việc phải tua lại theo dấu thời gian cụ thể, chưa kể đến lượng không gian điên rồ và chi phí hiệu năng trong việc duy trì bảng phiên bản đó.

Với Tìm nguồn sự kiện, bạn có thể dễ dàng tua lại, chỉ bằng cách phát lại các sự kiện cho đến một thời điểm nhất định. Chuyển tiếp nhanh có thể được đặt đúng chỗ bằng cách sử dụng ảnh chụp nhanh, nhưng đó hoàn toàn là vấn đề thực hiện.

Nhưng lợi thế thực sự mà tôi nghĩ bạn sẽ thích, vì bạn đặc biệt quan tâm đến việc không mất dữ liệu, là nếu bạn phát hiện ra một lỗi trong mã lưu dữ liệu này, thì bạn không cần phải quay lại và làm sạch dữ liệu (điều này thường không thể vì dữ liệu gần như không bao giờ hoàn thành). Thay vào đó chỉ cần sửa lỗi, và phát lại tất cả các sự kiện. Sau đó, bạn sẽ có một cơ sở dữ liệu với dữ liệu chính xác tốt đẹp.

Trong trường hợp gỡ lỗi, tần suất bạn yêu cầu người dùng cho bạn biết họ đã làm gì ... tại sao không chỉ phát lại những gì họ đã làm và sau đó bước qua mã! Khá tiện lợi nhỉ.

Hi vọng điêu nay co ich.

Không chính xác ví dụ của bạn, nhưng trong các hệ thống tài chính cũ hơn, bạn đã có bộ lưu trữ WORM . Nếu bạn cần "cập nhật", bạn đã viết một bản ghi mới và bạn luôn gọi bản ghi cuối cùng là hiện tại nhưng không có dữ liệu cam kết nào có thể bị ghi đè.

Rất nhiều người mang ý tưởng đó vào các hệ thống sau này. Tôi đã nghe những gì bạn đang mô tả được gọi là bảng WORM, nhưng chỉ trong các vòng tròn đó.

Có, nó khá phổ biến trong các hệ thống doanh nghiệp về cơ bản có hai cách tiếp cận: -

• "bi - tạm thời" trong đó mọi bản ghi đều có giá trị từ và hợp lệ theo dấu thời gian (bản ghi "hiện tại" có giá trị đến ngày "mãi mãi" - null, "9999-12-31" hoặc một số giá trị cao như vậy). Các bản ghi không bao giờ bị xóa thay vào đó ngày "hợp lệ thành" được đặt thành thời gian hiện tại và trong trường hợp cập nhật, một bản ghi mới được chèn với giá trị từ thời điểm hiện tại và mãi mãi là hợp lệ cho đến ngày.
• "bảng lịch sử" - mỗi khi bản ghi bị thay đổi, một bản sao của bản ghi cũ sẽ được đổ vào bảng lịch sử / nhật ký với dấu thời gian cho sự kiện.

Có sự khác biệt lớn về độ chi tiết cho cả hai phương pháp. ví dụ: Nếu số lượng vật dụng trên một mặt hàng được thay đổi, bạn có duy trì lịch sử cho toàn bộ đơn hàng hay chỉ một mặt hàng đó không?

Nói chung, "hai thời gian" là rất nhiều công việc làm thêm và chỉ có giá trị nếu bạn có nhiều trường hợp sử dụng như "kiểm toán viên có được trạng thái đơn hàng vào ngày 31 tháng 12".

Bạn có thể sử dụng "xóa mềm" như pdr đề xuất . Đối với các bản cập nhật, bạn có thể lưu lại lịch sử của các bản ghi, giống như câu trả lời của tôi ở đây: /dba/28195/save-history-editable-data-rdbms/28201#28201 nơi OP muốn có thể theo dõi tất cả các phiên bản của một số loại dữ liệu.

về cơ bản, crud không thể được hoàn thành mà không có 4 điều này. Crud có nghĩa là Tạo, Đọc, Cập nhật và xóa để khi bạn chỉ cố đọc dữ liệu, bạn có thể sử dụng truy vấn đơn giản cho điều đó nhưng tất cả ba điều này được gắn với một và các khái niệm cơ sở dữ liệu đơn giản và khác