電子賀卡程式的資料庫結構。(這僅代表我個人的在某一段時間的看法)。
表ECARD
賀卡的編號 ID 自動編號欄位
賀卡的標題TITLE
賀卡的作者author
賀卡的大類別catalog1
賀卡的二級類別catalog2
賀卡的類型cardtype 標明是flash卡，還是圖片(可能還有JAVA卡)
大圖片的名稱image 當然可以是flash或是其他檔案的名稱，可以包括路徑
小圖片的名稱simage
表order_card，用來存放預定的賀卡。
預定賀卡的id 經過編碼後產生提取卡片的key
大圖片的名稱image
模板的名稱template 用來存放模板的名稱
寄卡人名稱sender
寄卡人郵件sendermail
收卡人名稱receiver
收卡人的郵件receivermail
是否收件確認confirm 寄卡人用來選擇是否要回執（我覺得這是最不必要的，還不如都給他回複）
寄卡時間senddate 可以選用日期型的資料，我認為日期是一個需要認真對待的問題，特別是在前段時間我在日期格式不斷遇到問題。
接下來的分類列出賀卡，分頁顯示的問題，我想這裡所有的人瞭解的要比我深很多。關於整個程式的演算法實現，我還有一些想法，不知是否能構簡化操作，請大家幫我看一下。
1、賀卡的大數別和二級類別最好存放在另一張表中，產生一個自動編號的值存放在ecard表中，我這樣做是因為我認為對一個欄位進行判斷，要比對二個欄位進行判斷要快很多。在sql server中是不是這樣我不明白，我在access中這種差距是很明顯的。這樣子在對賀卡進行管理時可能比較麻煩，但畢竟次數不是很多。
2、顯示分類的頁就不要從庫裡取了,可以用手工作好，更好的方法用程式一次性產生了。各類別的分頁顯示，具體的賀卡頁面可以用程式產生，也可以用asp動態從庫中去取。在前一端時間我狂熱的迷上了靜態頁面，將所有的賀卡頁面和鏈結頁面都產生了靜態網頁，但隨之出現了一些問題，要在靜態頁面中產生一些動態網頁面的效果所付出的努力要大很多。同時由於程式的複雜性變大，頁面產生不夠自動，變成許多時候要停下手邊的工作去更新賀卡頁面，而且這樣做系統的複雜性變高，或許你會說這沒什麼難的，但想到如果另一個人接手這一工作，如果要對伺服器進行遷移，涉及的工作就會變得比較多了。由此我得出一個結論，如果你不是專職於這個賀卡程式，或者專門負責幾樣工作，如果你工作的不是一個專職的賀卡網站，我想動態網頁面是一個比較好的選擇，當然如果你有更好的演算法來實現那就另當別論了。
3、如果你使用的是動態網頁面，在分頁顯示所有賀卡時，在鏈結中可以包含template,image等參數，而不是僅僅傳遞一個id值，因為具體顯示賀卡資訊的頁有了這些值就可以顯示特定的賀卡，而不要再次操作資料庫了。
4、這裡我們使用wsh來實現定時發卡功能，至於如何使用wsh來發卡我們在另一章來專門敘述。
5、由於使用了wsh來實現定時發卡，我們可以配合jmail或其他任何一個發信組件來發送html格式的信件而不像sql mail只能傳送檔案格式的信件。在html格式的信中我們可以嵌入javascript <script src=http://*.*/confirm.asp?reveiver=****&sendermail=*****></script>這樣在comfirm.asp中取到這幾個值，不要操作任何資料庫就可以產生確認信了。如果你還要什麼其他參數讓它一併送回來給你就行了。
6、還有一個問題，純屬個人看法。如果我們直接發送賀卡給使用者，使用者就可以在一段時間內收藏賀卡，現在幾乎所有的賀卡網站都是發送一個鏈結讓人去提取賀卡，這樣的話收藏的就很不方便了,只能看過就算了。為什麼網頁設計者會選擇這麼做呢，我想想法不外乎增加網站的訪問量，讓我們假設一下，如果每一位收卡人我們都要求他成為我們的會員才能閱覽賀卡，這樣不是更增加訪問量嗎，結果會怎樣呢？我個人的想法，一個網站應站在訪問者的角度上去看待問題，才能留住訪問者。
7、如果發送html格式的賀卡給收件者，庫中的記錄就可以刪除了。但保守一點考慮，如果收件者採用web方式收信，不能正確瀏覽賀卡時，應提供一個功能讓收信人可以通過輸入一個key來提取賀卡，這樣我們可能就不能刪除記錄，而應將它儲存至一個時限。
8、如果採用發給收件者一個key的方法，這個key可以通過對ID進行簡單的可逆的編碼產生一個key。
9、刪除賀卡時應先作標記，在一段時間後再進行刪除，以保證鏈結的完整性。
10、記住簡單就是美，在有限的步驟中完成所有的操作，讓每一步都完成一個特定的操作，再用一條紅線將它們連在一起，少用判斷，少用假設。
最後祝大家成功
事情總比你想像的要好。
TinTin
