网站的数据库如何设计?

网站的数据库如何设计?,第1张

什么是好的数据库设计?

一些原则可为数据库设计过程提供指导。第一个原则是,重复信息(也称为冗余数据)很糟糕,因为重复信息会浪费空间,并会增加出错和不一致的可能性。第二个原则是,信息的正确性和完整性非常重要。如果数据库中包含不正确的信息,任何从数据库中提取信息的报表也将包含不正确的信息。因此,基于这些报表所做的任何决策都将提供错误信息。

所以,良好的数据库设计应该是这样的:

将信息划分到基于主题的表中,以减少冗余数据。

向 Access 提供根据需要联接表中信息时所需的信息。

可帮助支持和确保信息的准确性和完整性。

可满足数据处理和报表需求。

设计过程

设计过程包括以下步骤:

确定数据库的用途:这可帮助进行其他步骤的准备工作。

查找和组织所需的信息:收集可能希望在数据库中记录的各种信息,如产品名称和订单号。

划分到表中的信息:将信息项划分到主要的实体或主题中,如“产品”或“订单”。每个主题即构成一个表。

关闭信息项目导入的列 确定希望在每个表中存储哪些信息。每个项将成为一个字段,并作为列显示在表中。例如,“雇员”表中可能包含“姓氏”和“聘用日期”等字段。

指定为主键:选择每个表的主键。主键是一个用于唯一标识每个行的列。例如,主键可以为“产品 ID”或“订单 ID”。

设置表关系:查看每个表,并确定各个表中的数据如何彼此关联。根据需要,将字段添加到表中或创建新表,以便清楚地表达这些关系。

优化您的设计:分析设计中是否存在错误。创建表并添加几条示例数据记录。确定是否可以从表中获得期望的结果。根据需要对设计进行调整。

应用规范化规则:应用数据规范化规则,以确定表的结构是否正确。根据需要对表进行调整。

参考:数据库设计基础

1) 不应该针对整个系统进行数据库设计,而应该根据系统架构中的组件划分,针对每个组件所处理的业务进行组件单元的数据库设计;不同组件间所对应的数据库表之 间的关联应尽可能减少,如果不同组件间的表需要外键关联也尽量不要创建外键关联,而只是记录关联表的一个主键,确保组件对应的表之间的独立性,为系统或表 结构的重构提供可能性。2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计,首先分析系统业务,根据职责定义对象。对象要符合封 装的特性,确保与职责相关的数据项被定义在一个对象之内,这些数据项能够完整描述该职责,不会出现职责描述缺失。并且一个对象有且只有一项职责,如果一个 对象要负责两个或两个以上的职责,应进行分拆。3)根据建立的领域模型进行数据库表的映射,此时应参考数据库设计第二范式:一个表中的所 有非关键字属性都依赖于整个关键字。关键字可以是一个属性,也可以是多个属性的集合,不论那种方式,都应确保关键字能够保证唯一性。在确定关键字时,应保 证关键字不会参与业务且不会出现更新异常,这时,最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。4)由于第一点所述的领域模型驱动的方式设计数据库表结构,领域模型中的每一个对象只有一项职责,所以对象中的数据项不存在传递依赖,所以,这种思路的数据库表结构设计从一开始即满足第三范式:一个表应满足第二范式,且属性间不存在传递依赖。5)同样,由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系,所以在领域模型中的对象存在主对象和从对象之分,从对象是从1-N 或N-N的角度进一步主对象的业务逻辑,所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。6) 在映射后得出的数据库表结构中,应再根据第四范式进行进一步修改,确保不存在多值依赖。这时,应根据反向工程的思路反馈给领域模型。如果表结构中存在多值 依赖,则证明领域模型中的对象具有至少两个以上的职责,应根据第一条进行设计修正。第四范式:一个表如果满足BCNF,不应存在多值依赖。7) 在经过分析后确认所有的表都满足二、三、四范式的情况下,表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。并且,我认为数据库中的表 是用来持久化一个对象实例在特定时间及特定条件下的状态的,只是一个存储介质,所以,表和表之间也不应用强关联来表述业务(数据间的一致性),这一职责应 由系统的逻辑层来保证,这种方式也确保了系统对于不正确数据(脏数据)的兼容性。当然,从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数 据,单从另一个角度来说,脏数据的产生在一定程度上也是不可避免的,我们也要保证系统对这种情况的容错性。这是一个折中的方案。8)应针 对所有表的主键和外键建立索引,有针对性的(针对一些大数据量和常用检索方式)建立组合属性的索引,提高检索效率。虽然建立索引会消耗部分系统资源,但比 较起在检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响,以及无索引时的排序 *** 作所带来的性能影响,这种方式仍然是值得提倡的。9) 尽量少采用存储过程,目前已经有很多技术可以替代存储过程的功能如“对象/关系映射”等,将数据一致性的保证放在数据库中,无论对于版本控制、开发和部 署、以及数据库的迁移都会带来很大的影响。但不可否认,存储过程具有性能上的优势,所以,当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性 时,可经过平衡考虑选用存储过程。10)当处理表间的关联约束所付出的代价(常常是使用性上的代价)超过了保证不会出现修改、删除、更改 异常所付出的代价,并且数据冗余也不是主要的问题时,表设计可以不符合四个范式。四个范式确保了不会出现异常,但也可能由此导致过于纯洁的设计,使得表结 构难于使用,所以在设计时需要进行综合判断,但首先确保符合四个范式,然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法。11)设计出的表要具有较好的使用性,主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧。12)设计出的表要尽可能减少数据冗余,确保数据的准确性,有效的控制冗余有助于提高数据库的性能。

就是二级分类呗,频道数据结构可以这样设计:ClassID

ParentID

ClassName,这是最简单的,还有比较复杂的,有接点路径,深度,子结点个数等;如果一条新闻属于多个频道,可以在新闻列表里面加两个字段,一个在大类ID,一个是小类ID,里面存储分类ID,用竖线“|”或者逗号“,”隔开。


欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/sjk/6911338.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-03-30
下一篇2023-03-30

发表评论

登录后才能评论

评论列表(0条)

    保存