Làm thế nào để phiên bản động kinh doanh Đối tượng/Dữ liệu?

Chúng tôi đang phát triển một ứng dụng lớn có liên quan đến kinh doanh. Bạn có thể tìm thấy các ứng dụng này tương tự như một số ứng dụng ERP, CRM, v.v.Làm thế nào để phiên bản động kinh doanh Đối tượng/Dữ liệu?

Bây giờ, chúng tôi cần tất cả dữ liệu được người dùng nhập vào để được phiên bản.

Ví dụ: tại một số thời điểm, người dùng sẽ cần phải xem lịch sử thay đổi của một Đơn mua hàng cụ thể là gì?

Tôi đang tìm trình xử lý phiên bản rất phổ biến (không cứng nhắc), có thể xử lý ngay cả trường hợp nếu một số thuộc tính dữ liệu nghiệp vụ bị thay đổi. Trình xử lý phiên bản duy nhất này sẽ có thể làm việc với hầu hết mọi loại đối tượng/dữ liệu nghiệp vụ.

Điều gì sẽ là thiết kế lập trình/cơ sở dữ liệu tốt nhất để xử lý chúng.

Bất kỳ ý tưởng hoặc ý kiến nào?

PS: Tôi đã thêm một số thẻ lập trình khi tôi muốn các lập trình viên giải trí chuỗi này và đưa ra ý tưởng của họ.

EDIT: Tôi đang tìm kiếm một cách rất tối ưu hóa, hơi giống với việc lưu trữ chúng khác thay vì lưu trữ các đối tượng theo cách được tuần tự hóa/bán phá giá.

Nguồn

2011-10-17 linuxeasy

Tôi đã xóa thẻ generics. Vui lòng đọc mô tả thẻ generics. – Saintali

Giải pháp phụ thuộc rất nhiều vào cách đối tượng của bạn được lưu trữ ở nơi đầu tiên. Bạn đang sử dụng một cơ sở dữ liệu quan hệ? Điểm cơ bản khác là các đối tượng được phiên bản sẽ được sử dụng như thế nào? Đây có phải chỉ là một nhật ký hay bạn cần để có thể trình bày các trạng thái cũ của ứng dụng giống như cách bạn thực hiện đối với ứng dụng hiện tại? –

@Nicola Musatti -> Có điều này sẽ là một cơ sở dữ liệu quan hệ. Có, chúng tôi sẽ yêu cầu có thể trình bày các trạng thái cũ. Và các đối tượng là với các thuộc tính của nó, mà thậm chí có thể là các đối tượng con hơn nữa. – linuxeasy

Đây có thể là thời điểm thích hợp để áp dụng cấu trúc dữ liệu lười biếng purely functional.

Tóm lại, điều này đòi hỏi phải cấm bất kỳ hoạt động đột biến nào trên Đối tượng của bạn, tức là tạo tất cả các phiên bản Object của bạn immutable. Sau đó, bạn thiết kế lại tất cả các hoạt động thay đổi đối tượng hiện có để tạo đối tượng Object mới dựa trên trên phiên bản cũ.

Ví dụ: cho phép bạn có một phiên bản Order chứa danh sách OrderItem giây và bạn cần thêm OrderItem cụ thể vào danh sách đó.Việc bạn làm trong trường hợp này là tạo phiên bản mới Order bằng cách thay thế danh sách các mục của danh sách mới theo danh sách mới, do đó được tạo ra bởi cons 'vào OrderItem mới vào danh sách cũ.

Hãy để tôi minh họa ví dụ đó thêm trong hình ảnh. Hãy tưởng tượng một lưu trữ của các đối tượng (để cho nó được RAM hoặc cơ sở dữ liệu quan hệ, bất cứ điều gì):

 
Address | Object    | Created by 
--------+--------------------+------------------------------------------ 
    1000 | list of OrderItems | empty list constructor 
    1001 | Order    | Order constructor, uses address 1000 
        ...   
    1300 | OrderItem   | ... 
    1501 | list of OrderItems | cons of addr 1300 to addr 1000 
    1502 | Order    | replace order_items in addr 1001 by addr 1501

Cấu trúc rất lưu trữ dữ liệu theo cách này là dai dẳng (Chris Okasaki trau chuốt về vấn đề này trong his thesis, ví dụ). Bạn có thể khôi phục bất kỳ phiên bản nào của một đối tượng bằng cách chỉ theo lịch sử tạo của nó; phiên bản trở nên tầm thường. Chỉ cần nhớ điểm chính: không thay đổi dữ liệu, tạo các cá thể mới thay thế.

Nguồn

2011-10-25 14:55:09 ulidtko

Nếu bạn không làm xâm lấn (tôi thấy chung chung là cạnh tranh với xâm lấn), thì tôi nghĩ tùy chọn của bạn là thực hiện tuần tự hóa đầy đủ. Ở mỗi phiên bản, bạn chỉ cần chụp nhanh đối tượng và sắp xếp nó theo bất kỳ thứ gì phù hợp.

Nếu bạn bị giới hạn trong cơ sở dữ liệu chẳng hạn, chỉ cần lưu nó bằng dấu thời gian và lấy dấu thời gian gần đây nhất hiện tại. Tôi sẽ tránh suy nghĩ về nó như là chỉ là một vấn đề cơ sở dữ liệu mặc dù. Bạn nên được phép serialize bên ngoài của hệ thống cho những thứ như kết quả một phần, kiểm tra, sanity, vv

Nguồn

2011-10-17 14:32:36

serializing là ok, nhưng không phải là một giải pháp rất tối ưu tôi cảm thấy. Nếu nó là một cái gì đó gần gũi hơn để có diffs của phiên bản khác nhau được lưu trữ, sẽ là thú vị. – linuxeasy

@linuxeasy Bạn sẽ tốn nhiều thời gian hơn để cố gắng tìm ra những gì cần lưu trữ hơn là bạn sẽ lưu trữ nó. Knuth sẽ làm gì? –

Chúng tôi sẽ lưu trữ sự khác biệt giữa các đối tượng kinh doanh trước đó và các đối tượng kinh doanh hiện tại. Chúng tôi sẽ không cố gắng tìm ra những gì để lưu trữ và những gì không, nhưng chúng tôi đang tìm kiếm hướng tới phát triển một khuôn khổ chung mà sẽ làm điều này tự động. Và do đó, câu hỏi, thuật toán chung chung hiệu quả nhất là gì. Lưu trữ khác biệt cũng có một số lợi thế như làm nổi bật sự khác biệt. Vì vậy, mặc dù nó hơi phức tạp hơn là bán phá giá, nó cũng có những ưu điểm về bộ nhớ được lưu và làm nổi bật sự khác biệt. – linuxeasy

Về cơ bản bạn sẽ có thể so sánh các trường của đối tượng hiện có và đối tượng mới và duy trì sự khác biệt.

Thông thường việc này sẽ được thực hiện cho các thực thể có độ nhạy cao để theo dõi số lượng thay đổi đối với hàng/tài khoản cụ thể đó. Nó sẽ là một overkill nếu nó được thực hiện cho tất cả các bảng. Sự khác biệt có thể được duy trì không đồng bộ trong một bảng lịch sử riêng biệt phù hợp với cùng một thiết kế của các bảng trực tuyến.

Nguồn

2011-10-20 16:15:11 r0ast3d

Phương thức equals có thể lấy một đối số và so sánh các trường cho mục đích này. http://en.wikibooks.org/wiki/Java_Programming/Comparing_Objects Trước khi kiên trì nếu chúng ta có thể so sánh với thực thể hiện tại, chúng ta có thể lưu sự khác biệt như lịch sử riêng biệt. – r0ast3d

Ok, điều đầu tiên, nếu bạn có thể xác định như những gì nên là cách tốt nhất để làm điều đó. Thứ hai, hãy xem xét các đối tượng phức tạp như một đối tượng bao gồm các đối tượng con. Ví dụ: Purchase-Order là một Object và Purchase-Order-Items là Object con. Sự khác biệt của các thuộc tính trực tiếp của đơn đặt hàng có thể được thực hiện. Điều gì về sự khác biệt trong các mặt hàng mua hàng? chúng sẽ có các thuộc tính riêng của chúng. Và sẽ không chỉ có 1 mà là nhiều mặt hàng đặt mua. Cấu trúc db nào bạn sẽ xem là tốt nhất để sử dụng nó?Cũng đi qua các liên kết, tôi không cảm thấy nó là một giải pháp rất chung chung. – linuxeasy

Các mặt hàng mua hàng có thể không được so sánh như một phần của bằng để xác định thay đổi không? Tôi sẽ nghĩ rằng các mặt hàng mua hàng là một phần của thực thể đặt hàng pruchase. Thực thể con cũng có thể thực hiện bằng. Hoặc đối với một giải pháp chung chung hơn một tiện ích phản chiếu đơn giản cũng có thể giúp so sánh các trường và một lần nữa cố gắng đệ quy. – r0ast3d

Điều gì đó dọc theo các dòng Hibernate Envers - một giải pháp Kiểm tra thực thể, có vẻ phù hợp với yêu cầu của bạn.

Nguồn

2011-10-20 16:39:56

Tôi đã phải làm điều gì đó tương tự như vậy trong quá khứ.

Tôi thấy rằng cách dễ nhất, nếu bắt đầu từ đầu là thêm cột phụ vào bảng dữ liệu đối tượng đã giữ chỉ mục của đối tượng thay thế. Nếu giá trị được giữ bằng 0 thì tôi biết đó là phiên bản mới nhất. Điều này cũng có nghĩa là các đối tượng không bao giờ bị xóa, mặc dù sau này tôi đã thêm tính năng chấm câu cho phép xóa lịch sử trong quá khứ.

Hiệu quả chỉ mục trở thành số phiên bản của đối tượng được đề cập và bất kỳ truy vấn nào đối với DB cho phiên bản mới nhất sẽ sử dụng vòng loại WHERE NextVersionIndex=0.

Nếu không bắt đầu từ đầu, điều này có thể được triển khai vào hệ thống trực tiếp bằng cách thêm bảng phụ để lưu các giá trị này - Chỉ mục đối tượng, Chỉ mục phiên bản trước, chỉ mục phiên bản tiếp theo.

Nguồn

2011-10-26 07:35:30 ChrisBD

Làm thế nào để phiên bản động kinh doanh Đối tượng/Dữ liệu?

Trả lời

Các vấn đề liên quan