电子贺卡程序的数据库结构。
表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表中，我这样做是因为我认为对一个字段进行判断，要比对二个字段进行判断要快很多。
在sqlserver中是不是这样我不明白，我在Access中这种差距是很明显的。这样子在对贺卡进行管理时可能比较麻烦，但毕竟次数不是很多。
2、显示分类的页就不要从库里取了,可以用手工作好，更好的方法用程序一次性生成了。各类别的分页显示，具体的贺卡页面可以用程序生成，也可以用ASP动态从库中去取。在前一端时间我狂热的迷上了静态页面，将所有的贺卡页面和链结页面都生成了静态的网页，但随之出现了一些问题，要在静态页面中产生一些动态页面的效果所付出的努力要大很多。同时由于程序的复杂性变大，页面生成不够自动，变成许多时候要停下手边的工作去更新贺卡页面，而且这样做系统的复杂性变高，或许你会说这没什么难的，但想到如果另一个人接手这一工作，如果要对服务器进行迁移，涉及的工作就会变得比较多了。由此我得出一个结论，如果你不是专职于这个贺卡程序，或者专门负责几样工作，如果你工作的不是一个专职的贺卡网站，我想动态页面是一个比较好的选择，当然如果你有更好的算法来实现那就另当别论了。
3、如果你使用的是动态页面，在分页显示所有贺卡时，在链结中可以包含template,image等参数，而不是仅仅传递一个id值，因为具体显示贺卡信息的页有了这些值就可以显示特定的贺卡，而不要再次操作数据库了。
4、这里我们使用wsh来实现定时发卡功能，至于如何使用wsh来发卡我们在另一章来专门叙述。
5、由于使用了wsh来实现定时发卡，我们可以配合jmail或其他任何一个发信组件来发送HTML格式的信件而不像sqlmail只能发送文件格式的信件。在html格式的信中我们可以嵌入t这样在comfirm.asp中取到这几个值，不要操作任何数据库就可以生成确认信了。如果你还要什么其他参数让它一并送回来给你就行了。
6、还有一个问题，纯属个人看法。如果我们直接发送贺卡给用户，用户就可以在一段时间内收藏贺卡，现在几乎所有的贺卡网站都是发送一个链结让人去提取贺卡，这样的话收藏的就很不方便了,只能看过就算了。为什么网页设计者会选择这么做呢，我想想法不外乎增加网站的访问量，让我们假设一下，如果每一位收卡人我们都要求他成为我们的会员才能阅览贺卡，这样不是更增加访问量吗，结果会怎样呢？我个人的想法，一个网站应站在访问者的角度上去看待问题，才能留住访问者。
7、如果发送html格式的贺卡给收件人，库中的记录就可以删除了。但保守一点考虑，如果收件人采用web方式收信，不能正确浏览贺卡时，应提供一个功能让收信人可以通过输入一个key来提取贺卡，这样我们可能就不能删除记录，而应将它保存至一个时限。
8、如果采用发给收件人一个key的方法，这个key可以通过对ID进行简单的可逆的编码产生一个key。
9、删除贺卡时应先作标记，在一段时间后再进行删除，以保证链结的完整性。
10、记住简单就是美，在有限的步骤中完成所有的操作，让每一步都完成一个特定的操作，再用一条红线将它们连在一起，少用判断，少用假设。
更新时间：2009-07-10
