我曾經用兩個表做備份。不知道各位朋友還有別的辦法沒有。
就是用戶修改自己的資料時，把用戶原始記錄保存起來。
用一個bit類型的值做標識信息，修改前的標識爲0，修改後的標識爲1
個人資料數據量不大的話，可以考慮給表增加字段。
數據量大，增加一個備份表
就拿樓上兩個例子：電動自行車 的原始模型無疑是 機械，但是人腦所賦予的特性規則是“電子化，環保”
電子報警門：的原始模型無疑是“門”，人腦附加的特性是“具有報警功能”
在我看來兩派並沒有區別，只要有足夠多的原子就成，唯一的區別是 “還原派”附加了人的因素，就像還原現象學的鼻祖海德格爾的那個著名的“煩”，煩-----煩有現實的模型物理上的“抽象煩”（吃不飽，穿不暖），也就人腦中的“接口煩”（思不得，求不得）
我只能這樣說，你的思路是沒有問題的，我也非常同意先學面向對象設計，然後纔有不同語言的不同實現方式。樓主這個問題是從編程語言的技術角度去提的，也就是我在上面所說的，兩者在技術角度沒有什麼明顯區別。唯一需要注意的就是c#這種面嚮對象語言跟c++這種面嚮對象語言不一樣，它不支持類的多重繼承。
我們現在只是把問題提高到面向對象上，而不僅僅是技術上。那麼既然是設計，各有各的做法，沒有什麼完全可以或者完全不可以。電子報警門，讓他就繼承於“門”，當然可以，讓他繼承於“門”，並實現“可報警”的接口，當然可以，你甚至可以什麼都別去繼承，直接定義一個“電子報警門”的類，這樣我也不會有什麼問題。
爲什麼我會這麼說？因爲你的設計不僅僅是面向對象上的東西，你需要考慮你究竟要去解決什麼樣的問題，這纔是合理設計的參考標準。我認爲，合理的設計應該是面向對象+需要解決的問題，而成功的項目則是需求+合理的設計。不知朋友您對我的這個看法有何高見，很希望您能夠指點一二。呵呵，我們都扯遠了。
我覺得，軟件設計上的事情，每個人的意見都是不會有錯的，因爲大家都能夠擺事實，說理由。我只能說設計是合理還是不合理的。合理或者不合理也是在一個界定的上下文中，脫離了這個環境，合理的設計就會變得不合理。
對你說的一點沒錯，這也是“現象學”，當初分爲兩派的原因，並且後一派給前一派加上了“先驗”倆個字，而強調的自己這派“還原”的意義。
1 是原子是很難拆乾淨的
2 拆出來的是“先驗的”，也就是目前他是合適的，可誰知道以後合適不
所以，後一派強調還原，不要求拆出所有的，只要求還原現有的，並把人腦中的概念獨立出來（因爲人腦的概念都是通用的概念）
編程就是編程，用特定一種編程機制來解析有着將近30年曆史的OO軟件設計技術，反對倒是根本沒有拋析出細節，也就不能面向編程的未來。
事事都有個目的性，目的性不同也許結果看似相似但是看得遠一點就大相徑庭了。也許5年前我說“月亮是白的”，但是5年之後我可以把話往回說：月亮其實沒有顏色。
當然，我（至少）5年來在面向對象技術上的觀點始終是這樣的：
. 面向對象分析與設計技術根本不是編程技術，不但可以給編程者使用，更是給廣大的非編程者使用的。只是教育、教材的問題而已。
. 優秀的面向對象編程語言其實有很多種，例如Effiel、Smalltalk等都是。
. 我最有成就感的面向對象編程是很早以前使用純c來全面實現的OO程序。不是使用非OOPL讓我知道OO的本質用法而不糾纏於語言。
. 我注重架構設計，希望編程越少越好。
來源：足球世界