数据库分割

本文探讨了通过合理设计数据库来提升系统性能的方法,包括列分割、行分割、实例分割及物理部署分割等策略,并提供了具体的案例分析。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

转载自:https://blog.youkuaiyun.com/stuartjing/article/details/6459826

本文介绍一些关于提高系统性能方面的知识,列分割,行分割,实例分割,物理存储分割等技术。

这篇主要讲解一下数据库的设计,因为一个好的数据结构,对整体系统的运作太重要了,请看看本文的内容。

提到程序性能,大家都知道时间复杂度的公式O(f(n))。在提高性能的这个迷局中,很多人都会想尽办法降低算法函数f的复杂度,或者是提高函数f的运行 速度。但是这些都是没有办法的办法,是舍本求末的办法。如果基数n巨大,这类方法都不会有很好的效果,因为问题的本身在于基数 n。千方百计减少基数n的数量才能获取质的提高。

如何才能达到降低基数n的效果呢?假设你一个杂货店的老板,你有一个杂志货柜。可是杂志的种类越来越多,货柜放不下了,这时你会怎么做?是延长货柜的长度 还是把杂志分类后,再增加一个货柜?我更愿意增加一个货柜,而不是无限制的延长原来的货柜。从杂货店货柜的启示,我觉得降低基数 n的数量的有效办法是分而治之:

一、 列分割

通常,随着开发过程的推进,系统中主表的字段数会越来越多。但是一个表的字段个数,是受数据库规范和性能限制的。例如,SQL Server 数据库中一个表最多可以包含1024个字段,而实际应用中一般不能超过246个字段,每行数据可以存储8060字节。(参见 http://msdn.microsoft.com/zh-cn/library/ms143432.aspx)

另外,对于大数据表来说,列的数量直接影响存取速度。数据的存储结构对行的存取更加优化,而不是列的存取。下面,提出几种分割存储列的情形。

1、  列数太多时。

我在2004年曾经做过一个失败的项目。在设计一个5年的采购计划表时,我把每个月的采购计划设计成列,这样表的列说增加了60 列,这张表最终达到120个列。这种设计导致的结果是,当表有100万条记录时,采购计划的计算要花费2.5小时。改进方案是把列改成行存储,增加一个计 划年份字段,这样,总的列数减少了近40%,表的行数增加了增加到了500万条,但是存取速度提高了很多,使采购计划的计算时间降低到0.5小时。

所以,我给出的意见是

l         表的列数最好不要超过80个

l         行存储比列存储的存取速度更快

2、  表中列的数据相对较大或不经常用到时

表中存在下面的字段时需要隔离出去:

l         图片对象

l         附件(文件等)

l         大量的备注信息

l         几乎不被查询的列

3、  表中的字段,可以按照业务逻辑分类时。

按照数据库的设计规范,一个同一个对象的属性应该属于一张表。可是,实际情况是,如果按照业务逻辑来划分表,能获得更好的性能。

二、行分割

对于记录行数巨大的表来说,最好的办法是按分类进行行分割,让数据存储在多个表内。自然界有一个放之四海皆准的“二八”定律,把它应用到数据上,就可以这样解释:在所有的数据中有20%的数据是可以满足我们80%的需求的。“ 

根据这个原理,通常有两种分类方法:

1、  按时间分类

如果数据的时效性很强,我们可以认为所有数据中,20%近期更新的数据能够满足业务80%的需求。例如,如果我们有5年的历史数据,那么就可以认为 其中在1年内(20%)更新过的数据(也可以是1年内创建的数据),能满足80%的业务需求;所以我们可以把这张表拆成两个表,分别存储20%和80%的 数据,以达到提高效率的目的。如果两张表仍然没有有效的提高性能,还可以利用“二八”定律再次分割。

实效性数据量和使用量关系:

2、  按索引分类

当数据的时效性不明显时,可以按索引分类数据。所谓索引可以是任何可以用于分类的字段,比如部门编号,员工编号,工艺编号等等。我们可以这样假设, 表中存储了所有零件的信息,但是在80%的情况下,1号生产车间只会存取自己部门用到的零件。于是,我们可以按照部门编号,把表分成多个。  

三、数据库实例分割

一般情况下,开发人员习惯于给每个项目配置一个数据库。但是实际上我们可以给一个应用程序更多的数据库实例。比如,在一个网络游戏服务器中,经常会 有账户数据库(用于认证)、存储数据库(用于存储状态)、日志数据库(用于存储监控状态)、地图数据库(用于存储地图状态)等等。类比到ERP系统中,我 们可以把许多项目共同的部分抽象出来,分别存储在不同的数据库实例中。例如,用户信息、部门信息、系统日志信息等可以定制成通用的数据库,每个软件项目都 可以去使用。

四、数据库实例物理部署的分割

表分割、数据库实例的分割,为物理部署带来了灵活性。例如,我们对物料表按照不同的品目,进行了表分割;又对这些表部署在了不同的数据库实例中;这 样我们就有条件把这些数据库实例分别部署在不同的物理数据库服务器上。这种部署给我们带来的好处是,物料计算时,我们可以指令所有的数据库服务器分布式计 算,大大提高运算速度。

<think>好的,用户现在想了解如何对Access数据库分割或拆分的方法。之前我已经给过他们一个比较详细的回答,现在他们又再次提问,并且引用了三个参考资料。我需要结合这些引用信息,同时参考之前的回答,提供更准确的解决方案。 首先,我需要理解用户提供的引用内容。引用1提到分表存储、数据库分区、分表、分库、分片,强调设计物理分区结构时不要保存冗余数据,否则会影响水平分区的功能。这可能是在提醒拆分时要注意数据结构的合理性,避免冗余。引用2说明拆分的主要用途是共享数据库,尤其是多用户环境下,通过拆分前端和后端减少网络传输的数据量。引用3看起来是关于数据库系统的基础知识,可能和ER模型、规范化理论相关,但具体内容不明确,可能用户误引用了。 接下来,用户的问题是如何对Access数据库分割或拆分。根据之前的回答,我提到了前端和后端拆分的方法,包括创建后端数据库文件、链接表、权限控制等步骤。现在需要结合引用中的信息,补充相关内容,比如避免冗余数据、分区的注意事项等。 用户可能在实际操作中遇到了问题,或者在拆分后遇到了性能或数据冗余的问题,所以需要更详细的指导。需要注意引用1中提到的水平分区和冗余数据的问题,拆分时确保数据结构的合理性,避免不同表中有重复的父表数据,或者通过视图联结导致分区失效。 引用2强调拆分后前端包含用户界面对象,后端存储数据,这样多用户共享时每个用户有自己的前端副本,减少网络传输。这点在之前的回答中也提到了,可以进一步强调。 需要检查之前的步骤是否有遗漏,比如是否提到了拆分前的备份、如何检查冗余数据、如何维护拆分后的数据库等。可能还需要补充关于分区的设计,如何规划表的结构,避免引用1中提到的问题。 另外,用户可能对如何具体实施拆分步骤还有疑问,比如手动拆分和使用向导的区别,或者如何验证拆分后的数据库是否正常工作。需要确保步骤清晰,可能分点说明手动和自动方法。 还要注意用户提到的引用3可能不太相关,但可能需要提及数据库设计过程中的规范化理论,确保表结构合理,避免冗余,符合引用1的建议。 总结来说,回答需要整合之前的步骤,结合引用中的注意事项,强调避免冗余数据和合理设计分区结构,同时详细说明拆分方法,包括手动和使用数据库拆分向导的不同步骤,以及拆分后的维护和管理要点。这样用户能全面了解如何正确拆分Access数据库,避免常见问题。</think>### 如何对 Access 数据库分割或拆分? 分割 Access 数据库的核心目标是优化性能(尤其是多用户环境)和简化管理,具体方法分为 **前端与后端分离** 和 **数据分区设计**。以下是详细步骤和注意事项: --- #### **方法一:前端与后端分离(推荐)** 这是 Microsoft Access 官方支持的拆分方式,适用于多用户共享场景[^2]。 **实现步骤:** 1. **创建后端数据库** - 新建一个空数据库文件(如 `Backend.accdb`),仅保留数据表。 - 通过 **Access 拆分向导**(菜单栏 > 数据库工具 > 拆分数据库)自动迁移数据表到后端,并生成前端链接。 - *手动操作*:导出原数据库中的表到后端文件,删除原表,再通过“外部数据 > 链接表管理器”重新链接。 2. **前端保留界面对象** - 前端仅包含查询、表单、报表、宏和模块,所有数据操作均通过链接表访问后端[^2]。 - 每个用户本地安装前端副本,避免多人同时编辑界面对象导致的冲突。 3. **优化网络传输** - 拆分后,网络仅传输表数据(如查询结果),而非界面对象(如复杂的报表设计)[^2]。 - 示例代码(Python 访问链接表): ```python import pyodbc conn_str = r'DRIVER={Microsoft Access Driver (*.accdb)};DBQ=FrontEnd.accdb;' conn = pyodbc.connect(conn_str) cursor = conn.cursor() cursor.execute("SELECT * FROM LinkedTable WHERE ID=1") print(cursor.fetchone()) ``` **注意事项:** - **避免数据冗余**:确保后端表中不存储重复数据,如多个子表同时包含父表字段(违反引用[1]中的分区设计原则)。 - **权限控制**:通过文件系统权限限制后端文件的写入操作,仅允许授权用户修改数据[^2]。 --- #### **方法二:数据分区设计(高级)** 若需进一步优化查询性能,可结合 **水平分区** 或 **垂直分区** 策略[^1]: 1. **水平分区** - 将同一表按条件(如日期、地区)拆分到不同物理表中。 - 例如:`Sales_2023` 和 `Sales_2024`,通过联合查询合并数据。 - **注意**:需避免冗余存储父表数据(如客户信息),否则分区失效[^1]。 2. **垂直分区** - 将宽表按字段使用频率拆分,例如将不常用的大字段(如备注)分离到单独表。 - 示例:主表 `Employees` 包含基本信息,扩展表 `EmployeeDetails` 存储照片和简历。 **实现工具:** - 使用 Access 查询设计器创建联合查询或视图,逻辑上整合分区数据。 - 通过 VBA 动态切换数据源: ```vba CurrentDb.TableDefs("LinkedTable").Connect = "Database=Partition2023.accdb" CurrentDb.TableDefs("LinkedTable").RefreshLink ``` --- #### **关键问题与解决方案** 1. **何时选择拆分?** - 多用户频繁访问、界面修改频繁、网络带宽有限时优先拆分前端和后端[^2]。 2. **拆分后的性能瓶颈** - 后端数据库过大(>2GB)或并发写入高时,需迁移到 SQL Server 等企业级数据库[^1]。 3. **数据一致性风险** - 定期使用 `Compact & Repair` 工具维护后端文件,避免损坏。 --- ### 相关问题 1. 如何监控拆分后的 Access 数据库性能? 2. 拆分后的数据库如何实现自动化备份? 3. Access 水平分区的具体应用场景有哪些?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值