什么是数据库开发，是只写存储过程，函数，触发器吗

数据库开发不仅仅是写存储过程，函数，触发器。包括很多内容。

1掌握数据库技术的基本概念、原理、方法和技术；

2能够使用SQL语言实现数据库 *** 作；

3具备数据库系统安装、配置及数据库管理与维护的基本技能；

4掌握数据库管理与维护的基本方法；

5掌握数据库性能优化的基本方法；

6了解数据库应用系统的生命周期及其设计、开发过程；

7熟悉常用的数据库管理和开发工具，具备用指定的工具管理和开发简单数据库应用系统的能力；

8了解数据库技术的最新发展。

一、数据库应用系统分析及规划

1软件工程与软件生命周期。

2数据库系统生命周期。

3数据库开发方法与工具。

4数据库应用体系结构。

5数据库应用接口。

二、数据库设计及实现

1．概念设计。

2逻辑设计。

3物理设计。

4数据库对象实现及 *** 作。

三、数据库存储技术

1．存储与文件结构。

2 索引技术。

四、并发控制技术

1．事务管理。

2并发控制技术。

3死锁处理。

五、数据库管理与维护

1、数据完整性。

2、数据库安全性。

3、数据库可靠性。

4、监控分析。

5、参数调整。

6、查询优化。

7、空间管理。

六、数据库技术的发展与新技术

1、分布式数据库。

2、对象数据库。

3、并行数据库。

4、数据仓库与数据挖掘。

一 什么是分布式数据库

分布式数据库系统是在集中式数据库系统的基础上发展来的 是数据库技术与网络技术结合的产物

分布式数据库系统有两种 一种是物理上分布的 但逻辑上却是集中的 这种分布式数据库只适宜用途比较单一的 不大的单位或部门 另一种分布式数据库系统在物理上和逻辑上都是分布的 也就是所谓联邦式分布数据库系统 由于组成联邦的各个子数据库系统是相对 自治 的 这种系统可以容纳多种不同用途的 差异较大的数据库 比较适宜于大范围内数据库的集成

分布式数据库系统(DDBS)包含分布式数据库管理系统(DDBMS)和分布式数据库(DDB)

在分布式数据库系统中 一个应用程序可以对数据库进行透明 *** 作 数据库中的数据分别在不同的局部数据库中存储 由不同的DBMS进行管理 在不同的机器上运行 由不同的 *** 作系统支持 被不同的通信网络连接在一起

一个分布式数据库在逻辑上是一个统一的整体 即在用户面前为单个逻辑数据库 在物理上则是分别存储在不同的物理节点上 一个应用程序通过网络的连接可以访问分布在不同地理位置的数据库 它的分布性表现在数据库中的数据不是存储在同一场地 更确切地讲 不存储在同一计算机的存储设备上 这就是与集中式数据库的区别 从用户的角度看 一个分布式数据库系统在逻辑上和集中式数据库系统一样 用户可以在任何一个场地执行全局应用 就好那些数据是存储在同一台计算机上 有单个数据库管理系统(DBMS)管理一样 用户并没有什么感觉不一样

分布式数据库中每一个数据库服务器合作地维护全局数据库的一致性

分布式数据库系统是一个客户/服务器体系结构

在系统中的每一台计算机称为结点 如果一结点具有管理数据库软件 该结点称为数据库服务器 如果一个结点为请求服务器的信息的一应用 该结点称为客户 在ORACLE客户 执行数据库应用 可存取数据信息和与用户交互 在服务器 执行ORACLE软件 处理对ORACLE数据库并发 共享数据存取 ORACLE允许上述两部分在同一台计算机上 但当客户部分和服务器部分是由网连接的不同计算机上时 更有效

分布处理是由多台处理机分担单个任务的处理 在ORACLE数据库系统中分布处理的例子如

客户和服务器是位于网络连接的不同计算机上

单台计算机上有多个处理器 不同处理器分别执行客户应用

参与分布式数据库的每一服务器是分别地独立地管理数据库 好像每一数据库不是网络化的数据库 每一个数据库独立地被管理 称为场地自治性 场地自治性有下列好处

◆系统的结点可反映公司的逻辑组织

◆由局部数据库管理员控制局部数据 这样每一个数据库管理员责任域要小一些 可更好管理

◆只要一个数据库和网络是可用 那么全局数据库可部分可用 不会因一个数据库的故障而停止全部 *** 作或引起性能瓶颈

◆故障恢复通常在单个结点上进行

◆每个局部数据库存在一个数据字典

◆结点可独立地升级软件

可从分布式数据库的所有结点存取模式对象 因此正像非分布的局部的DBMS 必须提供一种机制 可在局部数据库中引用一个对象 分布式DBMS必须提供一种命名模式 以致分布式数据库中一个对象可在应用中唯一标识和引用 一般在层次结构的每一层实施唯一性 分布式DBMS简单地扩充层次命名模型 实施在网络上唯一数据库命名 因此一个对象的全局对象名保证在分布式数据库内是唯一

ORACLE允许在SQL语句中使用全局对象名引用分布式数据库中的模式对象(表 视图和过程) 在ORACLE中 一个模式对象的全局名由三部分组成 包含对象的模式名 对象名 数据库名 其形式如

SCOTT EMP@SALES DIVISION ACME

一个远程查询为一查询 是从一个或多个远程表中选择信息 这些表驻留在同一个远程结点

一个分布式查询可从两个或多个结点检索数据 一个分布式更新可修改两个或两个以上结点的数据

一个远程事务为一个事务 包含一人或多个远程语句 它所引用的全部是在同一个远程结点上 一个分布式事务中一个事务 包含一个或多个语句修改分布式数据库的两个或多个不同结点的数据

在分布式数据库中 事务控制必须在网络上直辖市 保证数据一致性 两阶段提交机制保证参与分布式事务的全部数据库服务器是全部提交或全部回滚事务中的语句

ORACLE分布式数据库系统结构可由ORACLE数据库管理员为终端用户和应用提供位置透明性 利用视图 同义词 过程可提供ORACLE分布式数据库系统中的位置透明性

ORACLE提供两种机制实现分布式数据库中表重复的透明性 表快照提供异步的表重复;触发器实现同步的表的重复 在两种情况下 都实现了对表重复的透明性

在单场地或分布式数据库中 所有事务都是用MIT或ROLLBACK语句中止

二 分布式数据库系统的分类

( ) 同构同质型DDBS 各个场地都采用同一类型的数据模型(譬如都是关系型) 并且是同一型号的DBMS

( )同构异质型DDBS 各个场地采用同一类型的数据模型 但是DBMS的型号不同 譬如DB ORACLE SYBASE SQL Server等

( )异构型DDBS 各个场地的数据模型的型号不同 甚至类型也不同 随着计算机网络技术的发展 异种机联网问题已经得到较好的解决 此时依靠异构型DDBS就能存取全网中各种异构局部库中的数据

三 分布式数据库系统主要特点

DDBS的基本特点

( )物理分布性 数据不是存储在一个场地上 而是存储在计算机网络的多个场地上

逻辑整体性 数据物理分布在各个场地 但逻辑上是一个整体 它们被所有用户(全局用户)共享 并由一个DDBMS统一管理

( )场地自治性 各场地上的数据由本地的DBMS管理 具有自治处理能力 完成本场地的应用(局部应用)

( )场地之间协作性 各场地虽然具有高度的自治性 但是又相互协作构成一个整体

DDBS的其他特点

( )数据独立性

( )集中与自治相结合的控制机制

( )适当增加数据冗余度

( )事务管理的分布性

四 分布式数据库系统的优点

( )更适合分布式的管理与控制

分布式数据库系统的结构更适合具有地理分布特性的组织或机构使用 允许分布在不同区域 不同级别的各个部门对其自身的数据实行局部控制 例如 实现全局数据在本地录入 查询 维护 这时由于计算机资源靠近用户 可以降低通信代价 提高响应速度 而涉及其他场地数据库中的数据只是少量的 从而可以大大减少网络上的信息传输量;同时 局部数据的安全性也可以做得更好

( )具有灵活的体系结构

集中式数据库系统强调的是集中式控制 物理数据库是存放在一个场地上的 由一个DBMS集中管理 多个用户只可以通过近程或远程终端在多用户 *** 作系统支持下运行该DBMS来共享集中是数据库中的数据 而分布式数据库系统的场地局部DBMS的自治性 使得大部分的局部事务管理和控制都能就地解决 只有在涉及其他场地的数据时才需要通过网络作为全局事务来管理 分布式DBMS可以设计成具有不同程度的自治性 从具有充分的场地自治到几乎是完全集中式的控制

( )系统经济 可靠性高 可用性好

与一个大型计算机支持一个大型的集中式数据库在加一些进程和远程终端相比 由超级微型计算机或超级小型计算机支持的分布式数据库系统往往具有更高的性价比和实施灵活性 分布式系统比集中式系统具有更高的可靠性和更好的可用性 如由于数据分布在多个场地并有许多复制数据 在个别场地或个别通信链路发生故障时 不致于导致整个系统的崩溃 而且系统的局部故障不会引起全局失控

( )在一定条件下响应速度加快

如果存取的数据在本地数据库中 那么就可以由用户所在的计算机来执行 速度就快

( )可扩展性好 易于集成现有系统 也易于扩充

对于一个企业或组织 可以采用分布式数据库技术在以建立的若干数据库的基础上开发全局应用 对原有的局部数据库系统作某些改动 形成一个分布式系统 这比重建一个大型数据库系统要简单 既省时间 又省财力 物力 也可以通过增加场地数的办法 迅速扩充已有的分布式数据库系统

五 分布式数据库系统的劣势

( )通信开销较大 故障率高

例如 在网络通信传输速度不高时 系统的响应速度慢 与通信相关的因素往往导致系统故障 同时系统本身的复杂性也容易导致较高的故障率 当故障发生后系统恢复也比较复杂 可靠性有待提高

( )数据的存取结构复杂

一般来说 在分布时数据库中存取数据 比在集中时数据库中存取数据更复杂 开销更大

( )数据的安全性和保密性较难控制

在具有高度场地自治的分布时数据库中 不同场地的局部数据库管理员可以采用不同的安全措施 但是无法保证全局数据都是安全的 安全性问题式分布式系统固有的问题 因为分布式系统式通过通信网络来实现分布控制的 而通信网络本身却在保护数据的安全性和保密性方面存在弱点 数据很容易被窃取

分布式数据库的设计 场地划分及数据在不同场地的分配比较复杂 数据的划分及分配对系统的性能 响应速度及可用性等具有极大的影响 不同场地的通信速度与局部数据库系统的存取部件的存取速度相比 是非常慢的 通信系统有较高的延迟 在CPU上处理通信信息的代价很高 分布式数据库系统中要注意解决分布式数据库的设计 查询处理和优化 事务管理及并发控制和目录管理等问题

六 分布式数据库系统 数据分片

类型

水平分片

按一定的条件把全局关系的所有元组划分成若干不相交的子集 每个子集为关系的一个片段

垂直分片

把一个全局关系的属性集分成若干子集 并在这些子集上作投影运算 每个投影称为垂直分片

导出分片

又称为导出水平分片 即水平分片的条件不是本关系属性的条件 而是其他关系属性的条件

混合分片

以上三种方法的混合 可以先水平分片再垂直分片 或先垂直分片再水平分片 或其他形式 但他们的结果是不相同的

条件

( )完备性条件

必须把全局关系的所有数据映射到片段中 决不允许有属于全局关系的数据却不属于它的任何一个片段

( )可重构条件

必须保证能够由同一个全局关系的各个片段来重建该全局关系 对于水平分片可用并 *** 作重构全局关系;对于垂直分片可用联接 *** 作重构全局关系

( )不相交条件

要求一个全局关系被分割后所得的各个数据片段互不重叠(对垂直分片的主键除外)

七 分布式数据库系统 数据分配方式

( )集中式 所有数据片段都安排在同一个场地上

( )分割式

所有数据只有一份 它被分割成若干逻辑片段 每个逻辑片段被指派在一个特定的场地上

( )全复制式 数据在每个场地重复存储 也就是每个场地上都有一个完整的数据副本

( )混合式 这是一种介乎于分割式和全复制式之间的分配方式

八 分布式数据库系统 体系结构

数据分片和数据分配概念的分离 形成了 数据分布独立型 概念

数据冗余的显式控制 数据在各个场地的分配情况在分配模式中一目了然 便于系统管理

局部DBMS的独立性 这个特征也称为 局部映射透明性 此特征允许我们在不考虑局部DBMS专用数据模型的情况下 研究DDB管理的有关问题

九 分布式数据库管理系统

接受用户请求 并判定把它送到哪里 或必须访问哪些计算机才能满足该要求

访问网络数据字典 了解如何请求和使用其中的信息

如果目标数据存储于系统的多个计算机上 就必须进行分布式处理

通信接口功能 在用户 局部DBMS和其他计算机的DBMS之间进行协调

在一个异构型分布式处理环境中 还需提供数据和进程移植的支持 这里的异构型是指各个场地的硬件 软件之间存在着差别

分布式数据库管理系统

lishixinzhi/Article/program/Oracle/201311/16998

作者 石默研

本文对新一代NewSQL分布式数据库发展策略中的普遍困扰进行讨论，包括云原生（Cloud Native）与本地部署(On Premise)、HTAP进展方向、分布式与单机需求等分布式数据库商业与技术发展中难以决策的问题。

1 困扰

分布式NewSQL数据库近年来蓬勃兴起，其原因显而易见：切中了业务与数据量不断增长的用户对关系型数据库RDBMS需求，这在传统RDBMS到大数据的发展阶段中，有相当一段时间是空白。同时，随着互联网技术的不断发展与普及，用云计算模式满足IT需求似乎已经成为未来 社会 产业互联网发展的明确趋势，也就是说，有一种共识：不久的将来，绝大多数产业的IT服务是从公共的、行业的或者私有的、混合的云计算中心提供的。这一共识又带来了云原生（Cloud Native）概念与技术的兴起，而分布式NewSQL数据库自然也应该是云原生的，这决定了其相当多的产品设计决策应以符合这一趋势为原则。然而，在当今的现实中，满足业务与数据量不断增长的RDBMS需求的用户，与云原生的用户，除了互联网企业外，大多数情况下，并不重合，需要On-Premise部署的用户仍然占有很大比重，这就带来了第一个困扰：云原生（Cloud Native）与本地部署(On Premise)对产品发展要求的矛盾。

另一个困扰，是关于HTAP，即交易与分析混合负载。HTAP是当今非常火的一个概念与技术，在交易库上直接进行分析，而不再是将“数据从交易库搬下来，挪到另一个数据库中去”这样的繁琐过程。可以毫不夸张的说： 历史 上规模性企业IT复杂度的相当一部分，都来自于“搬数据”，这导致了数据采集、实时采集、全增量合并、数据传输、数据加载、数据建模、数据质量、数据标准、企业级元数据管理等繁杂多样的技术环节的产生，导致了企业数据分布、数据流向、数据模型、主数据、基础数据平台、ODS/数据仓库/数据集市、数据治理等复杂的数据架构设计优化领域，导致了由于多系统大规模数据搬迁而带来的如数据交换平台之类的复杂调度工程。咋眼一看，感觉该企业的数据技术好厉害，相关各领域的技术产品好丰富，技术人员的相关技能也好受欢迎。但如果在交易库就能直接满足分析需求而不影响生产效能的话，这些复杂高级的技术环节不都成了“自己给自己造了一座山，还说自己爬的好辛苦”？然而，现实却是，问题并不这么简单，除了在交易库中进行分析会影响业务效能外，还有很多原因导致这一现象产生：交易库并不需要存储那么长的 历史 数据，而分析往往是需要建立在大量 历史 数据之上的；交易库的模型往往并不适合分析需求，多数情况下需要重要建模，如非常流行且价值不菲的各行业数仓主题模型；用于交易的OLTP数据库与用于分析的OLAP数据库，其技术体系完全不同；以及大型企业已固化的内部业务结构并没有留给交易/分析整合可实施的可行空间等等。由于， 历史 积累的企业级数据体系相当复杂，HTAP的发明者迄今为止都没有系统表达完全替代数据分析需求、自顶而下重构企业数据体系的架构级策略，而是将产品重点定位在技术优化层面：在交易库上直接完成实时统计分析，满足高并发需求且不影响业务效能；或者是为实时分析统计/查询而建设的数据服务中间平台。然而，即使是暂时没有这种策略性的意向，在面向AP的产品具体研发中，又会发现明确的界限确实不好把握，随着一个个具体功能的不断完善，似乎假以时日，技术上也不是没有完全替代纯OLAP平台的可能性。那么，HTAP究竟如何定位呢？

再者就是规模化的分布式需求，与小规模的单机数据库需求（这里指逻辑上的单机）之间的矛盾：分布式数据库，自然而然是要应对规模化的数据管理需求的，长尾的小规模需求当然不应在产品设计考虑之列，同时，大炮轰苍蝇经常还打不好；然而，分布式NewSQL数据库又应该是云原生的，如果把云原生的业务含义理解为“全自助”，它应该以支持什么样的需求为主呢？现实看来，小规模长尾业务对云原生数据库的需求最起码应该是占据相当大的比重的。显而易见，如果是大规模的数据管理需求，即使是部署在云上，DBPaaS的“全自助”是其核心需求吗？这种规模化的业务，如果是云上的On-Premise又需要做出哪些方面的改变？从互联网与云计算发展的 历史 来看，“云自助”，其最核心的商业动机当然包括给用户侧的运维带来了方便，但更重要的可能是给云服务运营商应对海量长尾客户的安装与运维带来了极大的成本优势。这正如银行的小微及个人消费贷款都要走互联网线上模式，而重客、大客甚至中小企业信贷仍然是以线下为主的策略一样，本质是成本问题，而不是客户方便性问题。于是，矛盾显而易见：分布式是面向规模客户的，起码是中、大型客户，而云原生却有可能、最起码相当一段时间内是要以长尾客户为主要服务对象的。

以上困扰实质上，都涉及到了NewSQL分布式数据库的产品发展策略问题。

2 讨论

问题是客观而又普遍的，但分析与应对策略往往包含主观因素：人们的一个决定与决策，很多情况下并不由严格推理而来，而是心中已经有一个答案，再来找理由支持它。这里的讨论或许也并不能例外。

首先，来看看Cloud Native与On Premise。云原生本应是数据库即服务，然而目前真正有规模化数据增长需求的NewSQL应用相当多的情况下却是付费On Premise与免费On Premise区别，很多互联网企业的应用也可能只是部署在云基础设施上而已，真正的云原生更多是一些实验性、尝试性的需求。但云原生数据库在公有云、行业云以及大型私有云上已经逐渐在形成一种意识上的共识，其商业前景不可限量。也就是说，未来的数字化转型进程中，产业互联网的数据库部署，会逐渐向云基础设施迁移，长在云上。它可能是公有云，也可能是行业云，也可能是私有云，它们都是被定义为云原生NewSQL数据库的市场范围。当然，肯定还会有相当一部分数据库长在云下，这也不用纠结，将其排除在云原生市场战略目标之外即可，就是说，不需要考虑这部分客户需求对产品规划的影响，因为前一部分的份额已经足够大了。这样看来，以云原生为目标进行产品规划的逻辑没有问题，不过，还是要明确一点：长在云上的数据库是不是一定符合我们对“云原生”的既有理解？这里认为，即使未来，在云上形成了产业互联网数据库市场的主体，需要“全自助”的数据库即服务可能也是以面向长尾客户最为迫切、必不可少并且是核心本质，而对中大型以上的需求，“全自助”的意义相对有限，同时比较而言商业模式的转变或者更关键些。那么，如果是以“长在云上”为市场目标，似乎可以将其定义为“广义的云原生”，同时，只要是“长在云上”，那么“云原生”概念中高d性、高可用、低成本、快速迭代、存算分离等技术优势也都能方便获得。而对“云原生”策略中“云原生”一词的理解不同，对产品规划决策的影响也应该有所不同：一是目前被认为是On Premise的客户需求，或许也就是未来“云原生”主体市场的需求；二是NewSQL数据库关于云原生服务的产品策划，对用户侧“自助”水平的决策或许可以更灵活实用。高水平自助确实可以减轻客户对IT的依赖程度，但这里认为，云原生与用户自行在云上购买资源进行On-Premise部署相比，最关键的价值在于商业模式的改变，能自助多少，不一定是最重要的，因为成为云服务商后，运营运维的工作只会更多，责任可能会更大，甚至有时连IaaS的运维也需要PaaS服务商兜底。但从一个个客户的本地服务，变成集中化云服务，就已经是本质性的模式转变了。总之，需要就事论事，回到原点，仔细分析后决策，而不是用概念教条的判断，因为概念本身的定义并不见得准确对应实际的业务需求。

再来看看HTAP，对这个问题，正如在其它文章中表达过的一样，本文的观点较为明确。一是随着计算能力与架构的升级，从技术上讲，AP与TP的界限会越来越模糊；另外特别是在云原生的新世界里，数据库的这一特性又犹为重要，因为云原生的重要作用之一就是要让客户尽量摆脱对IT运维的依赖，将越来越多的精力集中到自己的业务发展上来；同时端到端的能力提升对云原生商业模式的贯彻也至关重要（需要仔细分析下目前DBPaaS的技术要求是否完全符合这一原点的、本质性的动力），过去与纯OLAP数据库的优势比较纠结在这里也可以得到正面支持；再者，既然架构上已经走向了AP，就很难做到在产品规划上时刻厘清纯AP与混合负载的需求后，再将前者排除在外。于是，以“混合负载满足部分AP需求”应该是由于投入与阶段性市场策略导致的阶段性产品规划，而长远来讲，以一套技术架构满足大多数需求，应该是云原生NewSQL数据库的追求。

接下来，就是关于规模化分布式与小规模单机需求的矛盾了。现在看来，经过上面的讨论，这一点已经不是什么问题了：因为“长在云上”、从分散服务向集中服务的商业模式转变就是指广义的云原生，而不一定要以小微的、迫切需要全自助的长尾为主流，那么，云原生NewSQL数据库仍然应以规模化分布式为其主体的需求方向，而小规模单机则暂时可以不做为重点来考虑。

最后指出一点，希望也能引发进一步的思考：我们所批判的主机，也声称自己是分布式架构，暂且不论其是否客观，但在现实中主机需要被替代的核心问题并不是有没有分布式，而是：一、扩展不灵活带来成本问题：“我只需要扩展一个节点，你却让我再买一台主机”；二、不自主可控；三、往往是软硬件结合的设计策略，包括内存、网络、存储与IO上的软硬融合设计，而这一点，是否需要云原生数据库从广义的定义出发进行学习参考，也是需要进一步讨论的。

数据库的查询功能实现原理：

数据库查询是数据库的最主要功能之一。我们都希望查询数据的速度能尽可能的快，因此数据库系统的设计者会从查询算法的角度进行优化。最基本的查询算法当然是顺序查找（linear search），这种复杂度为O(n)的算法在数据量很大时显然是糟糕的，好在计算机科学的发展提供了很多更优秀的查找算法，例如二分查找（binary search）、二叉树查找（binary tree search）等。如果稍微分析一下会发现，每种查找算法都只能应用于特定的数据结构之上，例如二分查找要求被检索数据有序，而二叉树查找只能应用于二叉查找树上，但是数据本身的组织结构不可能完全满足各种数据结构（例如，理论上不可能同时将两列都按顺序进行组织），所以，在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。

图1展示了一种可能的索引方式。左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址（注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的）。为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在O(log2n)O(log2n)的复杂度内获取到相应数据。

数据千万级别之多，占用的存储空间也比较大，可想而知它不会存储在一块连续的物理空间上，而是链式存储在多个碎片的物理空间上。可能对于长字符串的比较，就用更多的时间查找与比较，这就导致用更多的时间。

可以做表拆分，减少单表字段数量，优化表结构。

在保证主键有效的情况下，检查主键索引的字段顺序，使得查询语句中条件的字段顺序和主键索引的字段顺序保持一致。

主要两种拆分 垂直拆分，水平拆分。

垂直分表

也就是“大表拆小表”，基于列字段进行的。一般是表中的字段较多，将不常用的， 数据较大，长度较长（比如text类型字段）的拆分到“扩展表“。 一般是针对 那种 几百列的大表，也避免查询时，数据量太大造成的“跨页”问题。

垂直分库针对的是一个系统中的不同业务进行拆分，比如用户User一个库，商品Product一个库，订单Order一个库。 切分后，要放在多个服务器上，而不是一个服务器上。为什么？ 我们想象一下，一个购物网站对外提供服务，会有用户，商品，订单等的CRUD。没拆分之前， 全部都是落到单一的库上的，这会让数据库的单库处理能力成为瓶颈。按垂直分库后，如果还是放在一个数据库服务器上， 随着用户量增大，这会让单个数据库的处理能力成为瓶颈，还有单个服务器的磁盘空间，内存，tps等非常吃紧。 所以我们要拆分到多个服务器上，这样上面的问题都解决了，以后也不会面对单机资源问题。

数据库业务层面的拆分，和服务的“治理”，“降级”机制类似，也能对不同业务的数据分别的进行管理，维护，监控，扩展等。 数据库往往最容易成为应用系统的瓶颈，而数据库本身属于“有状态”的，相对于Web和应用服务器来讲，是比较难实现“横向扩展”的。 数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈。

水平分表

针对数据量巨大的单张表（比如订单表），按照某种规则（RANGE,HASH取模等），切分到多张表里面去。 但是这些表还是在同一个库中，所以库级别的数据库 *** 作还是有IO瓶颈。不建议采用。

水平分库分表

将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。

水平分库分表切分规则

1 RANGE

从0到10000一个表，10001到20000一个表；

2 HASH取模

一个商场系统，一般都是将用户，订单作为主表，然后将和它们相关的作为附表，这样不会造成跨库事务之类的问题。 取用户id，然后hash取模，分配到不同的数据库上。

3 地理区域

比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此。

4 时间

按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据 被查询的概率变小，所以没必要和“热数据”放在一起，这个也是“冷热数据分离”。

分库分表后面临的问题

事务支持

分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

跨库join

只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。

跨节点的count,order by,group by以及聚合函数问题

这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。

数据迁移，容量规划，扩容等问题

来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。

ID问题

一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得ID,以便进行SQL路由

一些常见的主键生成策略

UUID

使用UUID作主键是最简单的方案，但是缺点也是非常明显的。由于UUID非常的长，除占用大量存储空间外，最主要的问题是在索引上，在建立索引和基于索引进行查询时都存在性能问题。

Twitter的分布式自增ID算法Snowflake

在分布式系统中，需要生成全局UID的场合还是比较多的，twitter的snowflake解决了这种需求，实现也还是很简单的，除去配置信息，核心代码就是毫秒级时间41位 机器ID 10位 毫秒内序列12位。

跨分片的排序分页

一般来讲，分页时需要按照指定字段进行排序。当排序字段就是分片字段的时候，我们通过分片规则可以比较容易定位到指定的分片，而当排序字段非分片字段的时候，情况就会变得比较复杂了。为了最终结果的准确性，我们需要在不同的分片节点中将数据进行排序并返回，并将不同分片返回的结果集进行汇总和再次排序，最后再返回给用户。

一级考试大纲(WINDOWS环境)

基本要求

1具有使用微型计算机的基础知识（包括计算机病毒的防治常识）。

2了解微型计算机系统的组成和各组成部分的功能。

3了解 *** 作系统的基本功能和作用，掌握Windows的基本 *** 作和应用。

4了解文字处理的基本知识，掌握Word的基本 *** 作和应用,熟练掌握一种汉字（键盘）输入方法。

5了解电子表格软件基本知识，掌握Excel的基本 *** 作和应用。

6了解演示文稿的基本知识，掌握PowerPoint的基本 *** 作和应用。

7了解计算机网络的基本概念和因特网(Internet)的初步知识，掌握因特网(Internet)的简单运用。

考试内容

一、基础知识

1计算机的概念、类型及其应用领域；计算机系统的配置及主要技术指标。

2数制的概念，二进制整数与十进制整数之间的转换。

3计算机的数据与编码。数据的存储单位（位、字节、字）；西文字符与ASCII码；汉字及其编码（国标码）的基本概念。

4计算机的安全 *** 作,病毒的概念及其防治。

二、微型计算机系统的组成

1计算机硬件系统的组成和功能：CPU、存储器（ROM、RAM）以及常用的输入输出设备的功能。

2计算机软件系统的组成和功能：系统软件和应用软件，程序设计语言（机器语言、汇编语言、高级语言）的概念。

3多媒体计算机系统的初步知识。

三、 *** 作系统的功能和使用

1 *** 作系统的基本概念、功能、组成和分类（DOS、Windows、Unix、Linux）。

2Windows *** 作系统的基本概念和常用术语，文件、文件名、目录（文件夹）、目录（文件夹）树和路径等。

3Windows *** 作系统的基本 *** 作和应用。

(1)Windows概述、特点和功能、配置和运行环境。

(2)Windows“开始”按钮、“任务栏”、“菜单”、“图标”等的使用。

(3)应用程序的运行和退出。

(4)掌握资源管理系统“我的电脑”或“资源管理器”的 *** 作与应用。文件和文件夹的创建、移动、复制、删除、更名、查找、打印和属性设置。

(5)软盘格式化和整盘复制，磁盘属性的查看等 *** 作。

(6)中文输入法的安装、删除和选用。

(7)在Windows环境下，使用中文DOS方式。

(8)快捷方式的设置和使用。

四、字表处理软件的功能和使用

1字表处理软件的基本概念，中文Word的基本功能、运行环境、启动和退出。

2文档的创建,打开和基本编辑 *** 作,文本的查找与替换,多窗口和多文档的编辑。

3文档的保存、保护、复制、删除、插入和打印。

4字体格式、段落格式和页面格式等文档编排的基本 *** 作，页面设置和打印预览。

5Word的图形功能，图形编辑器及其使用。

6Word的表格制作功能：表格的创建，表格中数据的输入与编辑，数据的排序和计算。

五、电子表格软件的功能和使用

1电子表格的基本概念，中文Excel的功能、运行环境、启动和退出。

2工作簿和工作表的基本概念，工作表的创建、数据输入、编辑和排版。

3工作表的插入、复制、移动、更名、保存和保护等基本 *** 作。

4单元格的绝对地址和相对地址的概念，工作表中公式的输入与常用函数的使用。

5数据清单的概念，记录单的使用，记录的排序、筛选、查找和分类汇总。

6图表的创建和格式设置。

六、电子演示文稿制作软件的功能和使用

1中文PowerPoint的功能、运行环境、启动和退出。

2演示文稿的创建、打开和保存。

3演示文稿视图的使用，幻灯片的制作、文字编排、和图表插入及模板的选用。

4幻灯片的手稿和删除，演示顺序的改变，幻灯片格式的设置，幻灯片放映效果的设置，多媒体对象的插入，演示文稿的打包和打印。

二级可以从VFP，c语言，java，c++，vb，access，任选一科，考过即可，无论考哪一颗都要考二级公共基础知识。

公共基础知识

基本要求

1掌握算法的基本概念。

2掌握基本数据结构及其 *** 作。

3掌握基本排序和查找算法。

4掌握逐步求精的结构化程序设计方法。

5掌握软件工程的基本方法，具有初步应用相关技术进行软件开发的能力。

6掌握数据库的基本知识，了解关系数据库的设计。

考试内容

一、基本数据结构与算法

1算法的基本概念；算法复杂度的概念和意义（时间复杂度与空间复杂度）。

2数据结构的定义；数据的逻辑结构与存储结构；数据结构的图形表示；线性结构与非线性结构的概念。

3线性表的定义；线性表的顺序存储结构及其插入与删除运算。

4栈和队列的定义；栈和队列的顺序存储结构及其基本运算。

5线性单链表、双向链表与循环链表的结构及其基本运算。

6树的基本概念；二叉树的定义及其存储结构；二叉树的前序、中序和后序遍历。

7顺序查找与二分法查找算法；基本排序算法（交换类排序，选择类排序，插入类排序）。

二、程序设计基础

1程序设计方法与风格

2结构化程序设计。

3面向对象的程序设计方法，对象，方法，属性及继承与多态性。

三、软件工程基础

1软件工程基本概念，软件生命周期概念，软件工具与软件开发环境。

2结构化分析方法，数据流图，数据字典，软件需求规格说明书。

3结构化设计方法，总体设计与详细设计。

4软件测试的方法，白盒测试与黑盒测试，测试用例设计，软件测试的实施，单元测试、集成测试和系统测试。

5程序的调试，静态调试与动态调试。

四、数据库设计基础

1数据库的基本概念：数据库，数据库管理系统，数据库系统。

2数据模型，实体联系模型及E―R图，从E―R图导出关系数据模型。

3关系代数运算，包括集合运算及选择、投影、连接运算，数据库规范化理 论。

4数据库设计方法和步骤：需求分析、概念设计、逻辑设计和物理设计的相关策略。

C语言程序设计

基本要求

1熟悉TURBO C集成环境。

2熟练掌握结构化程序设计的方法，具有良好的程序设计风格。

3掌握程序设计中简单的数据结构和算法。

4TURBO C的集成环境下，能够编写简单的C程序，并具有基本的纠错和调试程序的能力。

考试内容

一、C语言的结构

1程序的构成，MAIN函数和其他函数。

2头文件，数据说明，函数的开始和结束标志。

3源程序的书写格式。

4C语言的风格。

二、数据类型及其运算

1C的数据类型（基本类型，构造类型，指针类型，空类型）及其定义方法。

2C运算符的种类、运算优先级和结合性。

3不同类型数据间的转换与运算。

4C表达式类型（赋值表达式，算术表达式，关系表达式，逻辑表达式，条件表达式，逗号表达式）和求值规则。

三、基本语句

1表达式语句，空语句，复合语句。

2数据的输入与输出，输入输出函数的调用。

3复合语句。

4GOTO语句和语句标号的使用。

四、选择结构程序设计

1用IF语句实现选择结构。

2用SWITCH语句实现多分支选择结构。

3选择结构的嵌套。

五、循环结构程序设计

1FOR循环结构。

2WHILE和DO WHILE循环结构。

3CONTINUE语句和BREAK语句。

4循环的嵌套。

六、数组的定义和引用

1一维数组和多维数组的定义、初始化和引用

2字符串与字符数组。

七、函数

1库函数的正确调用。

2函数的定义方法。

3函数的类型和返回值。

4形式参数与实在参数，参数值的传递。

5函数的正确调用，嵌套调用，递归调用。

6局部变量和全局变量。

7变量的存储类别（自动，静态，寄存器，外部），变量的作用域和生存期。

8内部函数与外部函数。

八、编译预处理

1宏定义：不带参数的宏定义；带参数的宏定义。

2“文件包含”处理。

九、指针

1指针与指针变量的概念，指针与地址运算符。

2变量、数组、字符串、函数、结构体的指针以及指向变量、数组、字符串、函数、结构体的指针变量。通过指针引用以上各类型数据。

3用指针作函数参数。

4返回指针值的指针函数。

5指针数组，指向指针的指针，MAIN函数的命令行参数。

十、结构体（即“结构”）与共用体（即“联合”）

1结构体和共用体类型数据的定义方法和引用方法。

2用指针和结构体构成链表，单向链表的建立、输出、删除与插入。

十一、位运算

1位运算符的含义及使用。

2简单的位运算。

十二、文件 *** 作

只要求缓冲文件系统（即高级磁盘I/O系统），对非标准缓冲文件系统（即低级磁盘I/O系统）不要求。

1文件类型指针（FILE类型指针）。

2文件的打开与关闭（FOPEN，FCLOSE）。

3文件的读写（FPUTC，FGETC，FPUTS，FGETS，FREAD，FWRITE，FPRINTF，FSCANF函数），文件的定位（REWIND，FSEEK函数）。

三级网络技术等级考试大纲

基本要求

1具有计算机软件及应用的基本知识。

2掌握计算机局域网的基本概念与工作原理

3了解网络 *** 作系统的基础知识

4掌握Internet的基本知识，了解电子政务与电子商务的应用。

5掌握组网、网络管理与网络安全等计算机网络应用的基本知识。

6了解网络技术的发展。7掌握计算机 *** 作并具有C语言编程（含上机调试）的能力。

考试内容

(一)基础知识

1计算机系统组成。

2计算机软件的基础知识。

3多媒体的基本概念。

4计算机应用领域。

(二)计算机网络基本概念

1计算机网络的定义与分类。

2数据通信技术基础。

3网络体系结构与协议的基本概念。

4广域网、局域网与城域网的分类、特点与典型系统。

5网络互连技术与互联设备。

(三)局域网应用技术1局域网分类与基本工作原理。

2高速局域网。

3局域网组网方法。

4结构化布线技术。

(四)网络 *** 作系统

1 *** 作系统的基本功能。

2网络 *** 作系统的基本功能。

3了解当前流行的网络 *** 作系统的概况。

(五)Internet基础

1Internet的基本结构与主要服务

。2Internet通信协议—TCP/IP。

3Internet接入方法。

4超文本、超媒体与Web浏览器。

(六)网络安全技术

1信息安全的基本概念。

2网络管理的基本概念。

3网络安全策略。

4加密与认证技术。

5防火墙技术的基本概念。

(七)网络应用—电子商务和电子政务

1电子商务的基本概念与系统结构。

2电子商务应用中的关键技术。

3浏览器、电子邮件及Web服务器的安全特性。

4Web站点内容的策划与推广。

5使用Internet进行网上购物与访问政府网站。

(八)网络技术发展1网络应用技术的发展。

2宽带网络技术。

3网络新技术。

(九)上机 *** 作

1掌握计算机的基本 *** 作。

2熟练掌握C语言程序设计的基本技术、编程和调试。

3掌握与考试内容相关的上机应用。

四级有三个方向 网络工程师 软件测试工程师 数据库工程师

网络工程师

基本要求

1了解大型网络系统规划、管理方法；

2具备中小型网络系统规划、设计的基本能力；

3掌握中小型网络系统组建、设备配置调试的基本技术；

4掌握企事业单位中小型网络系统现场维护与管理基本技术；

5了解网络技术的发展。

考试内容

一、网络规划与设计

1网络需求分析。

2网络规划设计。

3网络设备及选型。

4网络综合布线方案设计。

5接人技术方案设计

6IP地址规划与路由设计。

7网络系统安全设计

二、网络构建

1．局域网组网技术。

（1）网线制作方法、

（2）交换机配置与使用方法。

（3）交换机端口的基本配置。

（4）交换机VLAN配置。

（5）交换机STP配置。

2路由器配置与使用。

（1）路由器基本 *** 作与配置方法

（2）路由器接口配置

（3）路由器静态路由配置。

（4）RIP动态路由配置。

（5）OSPF动态路由配置。

3路由器高级功能。

（1）设置路由器为DHCP服务器。

（2）访问控制列表的配置。

（3）配置GRE协议。

（4）配置IPSec协议。

（5）配置MPLS协议。

4无线网络设备安装与调试。

三、网络环境与应用系统的安装调试

1．网络环境配置。

2 >

照您所说的话，这个不叫分布式数据库，一点都不是。顶多算是数据库联邦或者dblink。

也就是说，相同数据库结构的放着相同的应用，只是根据业务不同或是节点的功能不同，比如集团总部，二级单位，终端机构等节点，这样的话我有2个解决办法，

如果都是相同数据库，建议使用dblink方式，很简单，去网上查询一下有例子，就是几个命令。

如果数据库的类型都不同，比如有oracle、db2、sqlserver、mysql等，那么推荐你在应用上做webservice，就是SOA。这样就可以把查询其他节点的方法封装在一个接口并提供web服务，既能保障安全，又能保障不同数据库的跨域访问。

祝你成功。

补充：

>

星环科技分布式交易型数据库KunDB就不错。

KunDB是星环科技基于分布式技术自主研发的国产化的交易型数据库，提供完整的关系型数据库的能力，高度兼容SQL，保证事务ACID。KunDB具有业内领先的事务处理性能，SQL兼容性以及最新的分布式查询优化技术，支持复杂查询且性能是MySQL的10倍以上，充分满足高并发、大数据量的交易型业务场景，能够实现MySQL，Oracle等传统主流数据库的国产化替代。独特的混合部署技术支持主流国产化CPU等自主可控的硬件平台和OS部署，满足国产化部署需求。

KunDB提供全链路高可用、一致性备份恢复等容灾能力，以及完备的安全管理、资源管理能力，可以为不同业务场景保驾护航。

此外，KunDB以优异的成绩通过了工信部、央行、信通院、江苏省信创等多项数据库权威测试认证，连续收录Gartner、IDC、信通院等权威咨询机构数据库报告。

以上就是关于什么是数据库开发，是只写存储过程，函数，触发器吗全部的内容，包括:什么是数据库开发，是只写存储过程，函数，触发器吗、分布式数据库系统(DDBS)概述、NewSQL分布式数据库发展策略讨论等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！