电子贺卡程序的数据库结构
(这仅代表我个人的在某一段时间的看法)
表ECARD
贺卡的编号 ID 自动编号字段贺卡的标题TvLE 贺卡的作者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
删除贺卡时应先作标记在一段时间后再进行删除以保证链结的完整性
记住简单就是美在有限的步骤中完成所有的操作让每一步都完成一个特定的操作再用一条红线将它们连在一起少用判断少用假设
最后祝大家成功
事情总比你想像的要好
