好的表结构分的比较细致,个人理解大概主要分为主表、明细、历史记录表、中间表,辅助表结构应该分为:类型表、状态表、统计表、统计明细表等。为了一个功能加那么多表实在是多余,如果写一个非常复杂的业务逻辑还是很有必要的,因为要做到物帐联动。这可能不是一个明智的选择,还有一种方案是尽可能的压缩表结构,少分一些表结构出来这样可能有利于sql优化,服务器的负担更轻一些。如果一条sql连了二十几张表,三分之一是主表,其它是次表。那么它和三分之一的主表+多添加的字段进行比较,哪个跑的更快,会是一件很有趣的事情,第二种很可能跑的快但它不利于重用性、习惯性的分层更加有利于阅读。也可能它跑的并没有想像中的那么快,因为相对于第一种它增了次表的负担,在百万数据量面前条件越多速度越快,科学的讲速度还受表结构字段的长度的影响。当然第二种只是推测,因为在相等条件下,没有做过测试。
相关文章
- SQL Server 2014里的针对基数估计的新设计(New Design for Cardinality Estimation)
- 大数据:Hadoop(HDFS 的设计思路、设计目标、架构、副本机制、副本存放策略)
- 团体程序设计天梯赛(CCCC) L3013 非常弹的球 不同思路
- golang sql动态查询where构造,入参构造和结构体构造两种方式的实现思路
- 在一个千万级的数据库查寻中,如何提高查询效率?分别说出在数据库设计、SQL语句、java等层面的解决方案。
- 梳理你的思路(从OOP到架构设计)_介绍GoF设计模式
- MySQL学习-数据库设计以及sql的进阶语句
- 梳理你的思路(从OOP到架构设计)_基本OOP知识01
- 商城系统商品属性的数据库设计思路
- 【SQL】在 SQL Server 中创建一个视图,而该视图的数据源是 MySQL 数据表,实现方法