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