系统综述如何选择数据库

① 如何选择操作系统和数据库.

我们公司一直使用windows/oracle. 最早是NT,由于NT的内存管理不是很好,所以我们一直是每周 重启机器,虽然现在我们升级到Windows 2003,但还是保持着传统每周重启,听说Windows 2003已经 改进得很好,我们也在考虑不重启. 使用windows,管理员并不比unix累,我们使用windows将近十年,系统运行很稳定,性能也非常好.唯 一的缺点是现在windows的主流还是32位,64位还不成熟,所以内寸最多只能用到4G. Oracle应使用SAP的安装盘,不需要选择.如果你非要知道,那应该是企业版.

② 欲检索综述文献,使用哪个数据库较方便

可以在知网上进行检索，能很方便的查到。

③ 数据库如何设计

数据库设计的基本步骤

按照规范设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为以下6个阶段

1.需求分析

2.概念结构设计

3.逻辑结构设计

4.物理结构设计

5.数据库实施

6.数据库的运行和维护

数据库设计通常分为6个阶段1分析用户的需求，包括数据、功能和性能需求；2概念结构设计：主要采用E-R模型进行设计，包括画E-R图；3逻辑结构设计：通过将转换成表，实现从E-R模型到关系模型的转换；4：主要是为所设计的数据库选择合适的和存取路径；5数据库的实施：包括编程、测试和试运行；6数据库运行与维护：系统的运行与数据库的日常维护。）,主要讨论其中的第3个阶段,即逻辑设计。

在数据库设计过程中，需求分析和概念设计可以独立于任何数据库管理系统进行，逻辑设计和物理设计与选用的DAMS密切相关。

1.需求分析阶段（常用自顶向下）

进行数据库设计首先必须准确了解和分析用户需求（包括数据与处理）。需求分析是整个设计过程的基础，也是最困难，最耗时的一步。需求分析是否做得充分和准确，决定了在其上构建数据库大厦的速度与质量。需求分析做的不好，会导致整个数据库设计返工重做。

需求分析的任务，是通过详细调查现实世界要处理的对象，充分了解原系统工作概况，明确用户的各种需求，然后在此基础上确定新的系统功能，新系统还得充分考虑今后可能的扩充与改变，不仅仅能够按当前应用需求来设计。

调查的重点是，数据与处理。达到信息要求，处理要求，安全性和完整性要求。

分析方法常用SA(Structured Analysis) 结构化分析方法，SA方法从最上层的系统组织结构入手，采用自顶向下，逐层分解的方式分析系统。

数据流图表达了数据和处理过程的关系，在SA方法中，处理过程的处理逻辑常常借助判定表或判定树来描述。在处理功能逐步分解的同事，系统中的数据也逐级分解，形成若干层次的数据流图。系统中的数据则借助数据字典（data dictionary，DD）来描述。数据字典是系统中各类数据描述的集合，数据字典通常包括数据项，数据结构，数据流，数据存储，和处理过程5个阶段。

2.概念结构设计阶段（常用自底向上）

概念结构设计是整个数据库设计的关键，它通过对用户需求进行综合，归纳与抽象，形成了一个独立于具体DBMS的概念模型。

设计概念结构通常有四类方法：

• 自顶向下。即首先定义全局概念结构的框架，再逐步细化。

• 自底向上。即首先定义各局部应用的概念结构，然后再将他们集成起来，得到全局概念结构。

• 逐步扩张。首先定义最重要的核心概念结构，然后向外扩张，以滚雪球的方式逐步生成其他的概念结构，直至总体概念结构。

• 混合策略。即自顶向下和自底向上相结合。

3.逻辑结构设计阶段（E-R图）

逻辑结构设计是将概念结构转换为某个DBMS所支持的数据模型，并将进行优化。

在这阶段，E-R图显得异常重要。大家要学会各个实体定义的属性来画出总体的E-R图。

各分E-R图之间的冲突主要有三类：属性冲突，命名冲突，和结构冲突。

E-R图向关系模型的转换，要解决的问题是如何将实体性和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。

4.物理设计阶段

物理设计是为逻辑数据结构模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。

首先要对运行的事务详细分析，获得选择物理数据库设计所需要的参数，其次，要充分了解所用的RDBMS的内部特征，特别是系统提供的存取方法和存储结构。

常用的存取方法有三类：1.索引方法，目前主要是B+树索引方法。2.聚簇方法（Clustering）方法。3.是HASH方法。

5.数据库实施阶段

数据库实施阶段，设计人员运营DBMS提供的数据库语言（如sql）及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制和调试应用程序，组织数据入库，并进行试运行。

6.数据库运行和维护阶段

数据库应用系统经过试运行后，即可投入正式运行，在数据库系统运行过程中必须不断地对其进行评价，调整，修改。

数据库设计5步骤
Five Steps to design the Database

1.确定entities及relationships

a)明确宏观行为。数据库是用来做什么的？比如，管理雇员的信息。

b)确定entities。对于一系列的行为，确定所管理信息所涉及到的主题范围。这将变成table。比如，雇用员工，指定具体部门，确定技能等级。

c)确定relationships。分析行为，确定tables之间有何种关系。比如，部门与雇员之间存在一种关系。给这种关系命名。

d)细化行为。从宏观行为开始，现在仔细检查这些行为，看有哪些行为能转为微观行为。比如，管理雇员的信息可细化为：

· 增加新员工

· 修改存在员工信息

· 删除调走的员工

e)确定业务规则。分析业务规则，确定你要采取哪种。比如，可能有这样一种规则，一个部门有且只能有一个部门领导。这些规则将被设计到数据库的结构中。

====================================================================
范例：
ACME是一个小公司，在5个地方都设有办事处。当前，有75名员工。公司准备快速扩大规模，划分了9个部门，每个部门都有其领导。
为有助于寻求新的员工，人事部门规划了68种技能，为将来人事管理作好准备。员工被招进时，每一种技能的专业等级都被确定。


定义宏观行为
一些ACME公司的宏观行为包括：
● 招聘员工
● 解雇员工
● 管理员工个人信息
● 管理公司所需的技能信息
● 管理哪位员工有哪些技能
● 管理部门信息
● 管理办事处信息
确定entities及relationships
我们可以确定要存放信息的主题领域(表)及其关系，并创建一个基于宏观行为及描述的图表。
我们用方框来代表table，用菱形代表relationship。我们可以确定哪些relationship是一对多，一对一，及多对多。
这是一个E-R草图，以后会细化。



细化宏观行为
以下微观行为基于上面宏观行为而形成：
● 增加或删除一个员工
● 增加或删除一个办事处
● 列出一个部门中的所有员工
● 增加一项技能
● 增加一个员工的一项技能
● 确定一个员工的技能
● 确定一个员工每项技能的等级
● 确定所有拥有相同等级的某项技能的员工
● 修改员工的技能等级

这些微观行为可用来确定需要哪些table或relationship。

确定业务规则
业务规则常用于确定一对多，一对一，及多对多关系。
相关的业务规则可能有：
● 现在有5个办事处；最多允许扩展到10个。
● 员工可以改变部门或办事处
● 每个部门有一个部门领导
● 每个办事处至多有3个电话号码
● 每个电话号码有一个或多个扩展
● 员工被招进时，每一种技能的专业等级都被确定。
● 每位员工拥有3到20个技能
● 某位员工可能被安排在一个办事处，也可能不安排办事处。

2.确定所需数据

要确定所需数据：

a)确定支持数据

b)列出所要跟踪的所有数据。描述table(主题)的数据回答这些问题：谁，什么，哪里，何时，以及为什么

c)为每个table建立数据

d)列出每个table目前看起来合适的可用数据

e)为每个relationship设置数据

f)如果有，为每个relationship列出适用的数据

确定支持数据

你所确定的支持数据将会成为table中的字段名。比如，下列数据将适用于表Employee，表Skill，表Expert In。

Employee

Skill

Expert In

ID

ID

Level

Last Name

Name

Date acquired

First Name

Description

Department

Office

Address


如果将这些数据画成图表，就像：



• 需要注意：


• ● 在确定支持数据时，请一定要参考你之前所确定的宏观行为，以清楚如何利用这些数据。


• ● 比如，如果你知道你需要所有员工的按姓氏排序的列表，确保你将支持数据分解为名字与姓氏，这比简单地提供一个名字会更好。


• ● 你所选择的名称最好保持一致性。这将更易于维护数据库，也更易于阅读所输出的报表。


• ● 比如，如果你在某些地方用了一个缩写名称Emp_status，你就不应该在另外一个地方使用全名(Empolyee_ID)。相反，这些名称应当是Emp_status及Emp_id。


• ● 数据是否与正确的table相对应无关紧要，你可以根据自己的喜好来定。在下节中，你会通过测试对此作出判断。

3.标准化数据

标准化是你用以消除数据冗余及确保数据与正确的table或relationship相关联的一系列测试。共有5个测试。本节中，我们将讨论经常使用的3个。
关于标准化测试的更多信息，请参考有关数据库设计的书籍。

标准化格式
标准化格式是标准化数据的常用测试方式。你的数据通过第一遍测试后，就被认为是达到第一标准化格式；通过第二遍测试，达到第二标准化格式；通过第三遍测试，达到第三标准化格式。

如何标准格式：
1． 列出数据
2． 为每个表确定至少一个键。每个表必须有一个主键。
3． 确定relationships的键。relationships的键是连接两个表的键。
4． 检查支持数据列表中的计算数据。计算数据通常不保存在数据库中。
5． 将数据放在第一遍的标准化格式中：
6． 从tables及relationships除去重复的数据。
7． 以你所除去数据创建一个或更多的tables及relationships。
8． 将数据放在第二遍的标准化格式中：
9． 用多于一个以上的键确定tables及relationships。
10． 除去只依赖于键一部分的数据。
11． 以你所除去数据创建一个或更多的tables及relationships。
12． 将数据放在第三遍的标准化格式中：
13． 除去那些依赖于tables或relationships中其他数据，并且不是键的数据。
14． 以你所除去数据创建一个或更多的tables及relationships。

数据与键
在你开始标准化（测试数据）前，简单地列出数据，并为每张表确定一个唯一的主键。这个键可以由一个字段或几个字段（连锁键）组成。

主键是一张表中唯一区分各行的一组字段。Employee表的主键是Employee ID字段。Works In relationship中的主键包括Office Code及Employee ID字段。给数据库中每一relationship给出一个键，从其所连接的每一个table中抽取其键产生。

RelationShip

Key

Office

*Office code

Office address

Phone number

Works in

*Office code

*Employee ID

Department

*Department ID

Department name

Heads

*Department ID

*Employee ID

Assoc with

*Department ID

*EmployeeID

Skill

*Skill ID

Skill name

Skill description

Expert In

*Skill ID

*Employee ID

Skill level

Date acquired

Employee

*Employee ID

Last Name

First Name

Social security number

Employee street

Employee city

Employee state

Employee phone

Date of birth


将数据放在第一遍的标准化格式中
● 除去重复的组
● 要测试第一遍标准化格式，除去重复的组，并将它们放进他们各自的一张表中。
● 在下面的例子中，Phone Number可以重复。（一个工作人员可以有多于一个的电话号码。）将重复的组除去，创建一个名为Telephone的新表。在Telephone与Office创建一个名为Associated With的relationship。

将数据放在第二遍的标准化格式中
● 除去那些不依赖于整个键的数据。
● 只看那些有一个以上键的tables及relationships。要测试第二遍标准化格式，除去那些不依赖于整个键的任何数据（组成键的所有字段）。
● 在此例中，原Employee表有一个由两个字段组成的键。一些数据不依赖于整个键；例如，department name只依赖于其中一个键（Department ID）。因此，Department ID，其他Employee数据并不依赖于它，应移至一个名为Department的新表中，并为Employee及Department建立一个名为Assigned To的relationship。


将数据放在第三遍的标准化格式中
● 除去那些不直接依赖于键的数据。
● 要测试第三遍标准化格式，除去那些不是直接依赖于键，而是依赖于其他数据的数据。
● 在此例中，原Employee表有依赖于其键（Employee ID）的数据。然而，office location及office phone依赖于其他字段，即Office Code。它们不直接依赖于Employee ID键。将这组数据，包括Office Code，移至一个名为Office的新表中，并为Employee及Office建立一个名为Works In的relationship。

4.考量关系

当你完成标准化进程后，你的设计已经差不多完成了。你所需要做的，就是考量关系。

考量带有数据的关系
你的一些relationship可能集含有数据。这经常发生在多对多的关系中。

遇到这种情况，将relationship转化为一个table。relationship的键依旧成为table中的键。

考量没有数据的关系
要实现没有数据的关系，你需要定义外部键。外部键是含有另外一个表中主键的一个或多个字段。外部键使你能同时连接多表数据。

有一些基本原则能帮助你决定将这些键放在哪里：

一对多在一对多关系中，“一”中的主键放在“多”中。此例中，外部键放在Employee表中。

一对一在一对一关系中，外部键可以放进任一表中。如果必须要放在某一边，而不能放在另一边，应该放在必须的一边。此例中，外部键（Head ID）在Department表中，因为这是必需的。

多对多在多对多关系中，用两个外部键来创建一个新表。已存的旧表通过这个新表来发生联系。

5.检验设计

在你完成设计之前，你需要确保它满足你的需要。检查你在一开始时所定义的行为，确认你可以获取行为所需要的所有数据：
● 你能找到一个路径来等到你所需要的所有信息吗？
● 设计是否满足了你的需要？
● 所有需要的数据都可用吗？
如果你对以上的问题都回答是，你已经差不多完成设计了。

最终设计
最终设计看起来就像这样：

设计数据库的表属性
数据库设计需要确定有什么表，每张表有什么字段。此节讨论如何指定各字段的属性。

对于每一字段，你必须决定字段名，数据类型及大小，是否允许NULL值，以及你是否希望数据库限制字段中所允许的值。

选择字段名
字段名可以是字母、数字或符号的任意组合。然而，如果字段名包括了字母、数字或下划线、或并不以字母打头，或者它是个关键字（详见关键字表），那么当使用字段名称时，必须用双引号括起来。

为字段选择数据类型
SQL Anywhere支持的数据类型包括：
整数（int, integer, smallint）
小数（decimal, numeric）
浮点数（float, double）
字符型（char, varchar, long varchar）
二进制数据类型（binary, long binary）
日期/时间类型（date, time, timestamp）
用户自定义类型

关于数据类型的内容，请参见“SQL Anywhere数据类型”一节。字段的数据类型影响字段的最大尺寸。例如，如果你指定SMALLINT，此字段可以容纳32,767的整数。INTEGER可以容纳2,147,483,647的整数。对CHAR来讲，字段的最大值必须指定。

长二进制的数据类型可用来在数据库中保存例如图像(如位图)或者文字编辑文档。这些类型的信息通常被称为二进制大型对象，或者BLOBS。

关于每一数据类型的完整描述，见“SQL Anywhere数据类型”。

④ 如何选择合适的数据库

如何选择数据库

一般来讲，数据分析的查询不会直接从生产环境的数据库来读取数据，一方面是影响线上性能，另一方面是OLTP的表结构设计更多的是面向插入，而不是读取。如何来选择合适的数据库做数据分析呢？本文给出了四方面的考量，抛砖引玉。

1. 客户要分析什么样的数据

2. 客户分析的数据量是多少

3. 客户工程师团队技术背景，运维能力

4. 预期的数据分析的响应时间

客户要分析什么样的数据

上文已简单介绍了关系型数据库和非关系型数据库的区别，这里就不再赘述。下图是一个简单的分类。

⑤ 怎样选择数据库审计系统

安华金和官网上看的一篇文章，希望对你有帮助。随着数据价值的不断提升，从政策到用户对于数据安全重视程度越来越高，数据库审计产品作为一款部署简单，不用对现有IT架构进行任何改变，又能够满足政策合规需求的产品，是很多用户保障数据安全和合规需求的首选产品。那么面对市场上众多的数据库审计产品该怎样选择呢？下面将从数据库审计产品的功能上提出一些参考建议，希望对在数据库审计产品的选型过程中对您有所帮助。
一、数据库审计产品选型的10大基本能力
如果要满足用户使用数据库审计产品的基本需求，必须满足以下条件：
1、审计记录全和准：保证审计的准确性、全面性、无漏审，实现数据库访问流量的全捕获；
2、高效入库：审计结果快速入库，要在高访问量压力下，审计结果入库无延迟、无丢包；
3、准确的关联审计：高并发情况下，能够审计到数据库操作的应用用户；
4、高效分析：要能够对审计记录进行快速分析与检索，至少实现千万乃至亿级数据秒级响应；
5、高易用性：要符合用户的使用习惯，保障产品的易用性；
6、加密协议解析：随着通讯加密的普及，数据库审计产品必须要能够解析加密的数据库访问流量；
7、数据库入侵行为监测：数据价值的提升，造成了数据库攻击行为更加普遍，审计产品应提供针对数据库漏洞攻击的“检测”功能，并对这些漏洞攻击实时监控、有效记录，发现风险后及时告警，且能够有效追溯风险来源；
8、数据库异常行为监测：数据库访问行为异常时，系统可提供实时的告警能力，降低数据泄露的损失；
9、数据库违规行为监测：数据库审计产品还应具备针对数据库的违规访问、登录等行为检测告警的能力；
10、报表展现：数据库审计产品应具备将审计日志进行数据化分析并以个性化报表展示的能力，以便帮助安全管理人员更加便捷、深入的剖析数据库运行风险。例如：综合报表、合规性报表、专项报表、自定义报表等。
二、做标王，数据库审计还需要哪些更过硬实力
在具备了数据库审计产品的基本功能之外，一款好的数据库审计产品还应能够做到以下四点：
1、全面的审计元素：包括，表、函数、包、存储过程、视图、数据库登陆用户、客户端ip、端口、MAC、客户端操作系统、用户名、客户端工具、影响行数、结果集、执行时间、操作类型、长语句、大对象、mysql压缩协议、dblink、imp、exp、prepare参数等，这样才能保证审计结果的全面性；
2、精确SQL语句解析：采用句柄追踪\参数绑定追踪和基于词法和语法的精确SQL解析技术，可以实现在长SQL语句、高并发访问量时不丢包；在多SQL语句情况下，准确记录数据库语句是否执行成功；对于prepare语句，准确将参数值与原始语句和绑定变量关联；对SQL执行结果集进行准确追踪，从而准确记录SQL语句的影响行数，从而保证数据库审计结果的准确性；
3、应用审计视角下的4层应用框架结构：具备4级应用框架结构——应用请求、应用行为、应用模块、应用：
应用请求：访问源对某个指定的URL发起访问请求的流水记录；
应用行为：针对某类相同和相似的应用请求，去除参数化的URL模板（类似于SQL语句模板概念）；
应用模块：多个应用行为的组合，归属于一组功能模块的集合，对应应用服务器的功能菜单；
应用：以应用服务器IP+应用服务器端口+应用工程名定义的一个应用系统。
这种4级应用框架结构，可以有效保证数据库审计产品的应用关联准确性，从而提供完整的基于应用访问视角的综合性统计数据呈现和正向追溯能力，以及多角度的审计结果分析能力。
4、完整的风险匹配规则与多样化的告警方式：基于横向的黑白名单匹配规则以及黑白名单SQL语句，以及纵向的高中低等风险等级设置，实现准确的数据库访问风险行为匹配。snmp、syslog、短信、邮件等多样性的告警方式，保证数据库风险行为的实时告警，从而实现全面风险发现与及时告警。
这是我在安华金和官网上看到的一篇文章，觉得不错，推荐给你，他们家就有数据库审计产品。

⑥ 如何选择出最适合做网店的数据库系统

首先，先介绍几款在网店系统中使用最常见的数据库。
Access数据库，在ASP网店系统流行时，是一款应用非常广泛的数据库，它最大的特点就是操作、维护简单，管理方便。但对储存数据较大的网站，Access在存储、处理、安全等角度就显得吃力。随着ASP技术被微软淘汰，Access在网店系统中的应用也不在明显。
Mysql数据库,由于其主要的管理程序和运行环境都是开源的，因此发展非常迅速，在网店系统中的应用也非常广泛，特别在PHP网店系统中数据库无一例外选择的是Mysql。但Mysql数据库的接口支持彼此不统一，在数据库对接上存在一定的困难。
SQL server数据库，也是目前网店系统行业应用最多的数据库之一，随着微软在互联网方面的技术投入，11545.html">我们有理由相信它会越来越强大。SQL server的特点是具有很好的伸缩性，可跨越多种平台使用，对Web技术的支持，使用户能够很容易地将数据库中的数据发布到Web页面上。
Oracle数据库，在网店系统行业来讲是比较高端、安全的数据库，适合大型网点应用，如金融、国防、政府、世界五百强等网站，都是采用了Oracle数据库。
笔者近期也研究了几款国内知名网店系统，像SHOP++、ECSHOP、V5SHOP、SHOPEX等都在研究范围内。SHOP++是基于JAVA技术的网店系统，支持Mysql、SQL server、Oracle等多种数据库;ECSHOP和SHOPEX同是PHP技术开发的，同是商派旗下产品，数据库采用的是Mysql;V5SHOP是.NET技术中的老牌产品，数据库支持Mysql，若要支持SQL server必需先要获取数据库用户名和密码。显然，在网店系统行业若系统能同时支持多种数据库则会是最佳选择。
接下来进入正题，分析数据库在网店系统中的作用
通过我对几款网店系统的研究，各网店系统正常安装分为：程序安装和环境部署，而环境部署过程中就包含了数据库的安装。数据库我们都知道，在网店在主要是存储功能，如网站的资料、图片等都是储存在数据库上。对于一个有意义的网站来说，数据库是必不可缺的，我们常见的动态网站就是通过数据库的存储、输出来产生。如果是静态页面，就不需要存储资料、图片了，更不用使用数据库。
说到数据库还有一点是让站长最劳心的就属数据的迁移了，若有站长对网站数据的迁移存有疑惑，不防可以参照下面的方法操作：
a.进入网站后台，对数据进行备份，以防发生意外;
b.进入空间将home和image文件用ftp下载到本地;
c.安装新的网店程序，设置好管理账户、数据库的用户名和密码;
d.解析域名;
e.上传home和image文件;
f.进入后台对备份的数据恢复，更新后台，退出;
g.重新登录，访问正常，即迁移成功;
其实，数据库在网店系统中还有一个非常重要的作用--安全，也是本文的重点：
数据库的对网店系统有安全一面，可能有网友不解。我们举一个例子，小偷同时光顾Access数据库和Oracle数据库，你会发现小偷在Access数据库中可以来去自由，数据库文件不经意间就被任意DOWN走了。而光顾Oracle数据库，进入“保险库”大门后，发现还有一个警察拿着枪对着他，相比下使用Oracle的网店系统安全方面就更强。如网页编辑程序ewebeditor一样，只因使用了Access数据库，就造成了数以万计的站点因为它而被黑客轻轻松松的黑掉了。所以，数据库的选择也关系到网店系统的安全。

求采纳

⑦ 如何选择数据库

如何选择数据库

完整的存储进去，完整的取出来，不需要额外的操作。

NoSQL 比 RDB 有更强的扩展性，可以充分利用分布式系统来提升读写性能和可靠性。

这不是谁设计好坏的问题，而是跟他们要解决的问题有关：RDB 诞生于互联网萌芽的时代，那时数据的准确、可靠是最重要的，而 NoSQL 诞生于互联网快速发展普及的时代，大数据、分布式、扩展性成了数据库的另一个重要特性。

总结一下：

NoSQL ，not only SQL，其实就是对那种打破了 RDB 严格事务和关系模型约束的那些数据库的泛指，而随着要解决的问题的不同，又诞生了各种各样的 NoSQL。

首先是“列式数据库”（Column-oriented DBMS），数据量上去了，我们想分析网站用户的年龄分布，简单说，就是你需要对同一个特征进行大数据量的分析统计，于是把原来 RDB 的“按行存储”的范式打破，变成了“按列存储”，比如 HBase；

然后你发现有些数据变动不是很大，但是经常需要被查询， 查询时还要关联很多张表，于是你把这些来自不同表的数据，揉成一个大对象，按 key-value 的格式存起来，比如 Redis；

再后来你需要对博客内容进行相关性搜索，传统 RDB 不支持相关性搜索，最重要的，还是扩展性差，增加机器的带来边际效益有限，于是有了“全文搜索引擎”，比如 Elasticsearch；

除此之外，还有“文档数据库”、“图形数据库”……

没有一种数据库是银弹。

总结

这篇文章的题目是“如何选择数据库”，这是困扰很多人的问题，那么多数据库，到底要选什么好？

可是当你问出这样一个问题时，其实你是在问一种“手段”。我现在要做这样一个需求，用什么数据库可以帮我实现它？

但其实你需要的不只是一种“手段”，因为如果对方甩给你一个冷冰冰的名字，Mysql、Elasticsearch、MongoDB，你肯定会问，凭什么？

你需要的，是一种“解决方案”。如果你需要数据十分严格准确，分毫不差，那我会推荐你采用“事务”和“关系模型”来处理数据；如果你需要数据能够被大量读取和写入，那我会推荐你扩展性强的“分布式”；如果你的数据经常是整个读取、整个更新的，那“关系模型”就没有“文档模型”适合你。

“事务”、“关系模型”、“分布式”、“文档模型”等等，这些就是“解决方案”，知道用什么“解决方案”，用哪个数据库，自然水到渠成。

正如一位大牛说的：

用户不会因为你用了 Mysql 或者 MongoDB 而使用你的软件，毕竟绝大多数用户都不知道 Mysql 和 MongoDB 是什么玩意。

⑧ 如何做一个好的系统综述和Meta分析

系统性综述的英文名称有systematic review, overview和meta-analysis。我们用overview表示系统性综述的统称， 用meta-analysis代表定量系统性综述。系统性综述的实施步骤包括: 拟定主题， 检索、 选择和评价有关素材(原始文献)， 综合有关数据或资料， 及得出结论。系统性综述可以用于治疗、 病因、 诊断和预后等方面的问题。 1.1 基本标准 大多数临床问题涉及病人的治疗、 病因、 诊断和预后。除非综述明确地描述了主题， 否则我们就只能猜测其主要内容是否与病人的诊疗问题有关。如果通过文题或摘要无法了解综述的主题， 最好另选文章。 素材的选择标准应该包含病人、 暴露因素和观测指标或结局(outcome)的定义， 及研究方法的界定。对素材的具体要求可见前几篇关于治疗、 诊断、 危害因素和预后方面文章的介绍。 在主题相同的综述中， 入选病人、 暴露因素或观测指标的不同， 可以导致综述结果的不同。如果作者介绍了选择素材的标准并按之实施， 则基本上可以避免因自身经验的影响而导致挑选支持其原先假设的文献的倾向。 1.2 二级标准 全面检索， 以搜集符合选择标准的原始文献是综述的一个重要环节。全面检索应包括检索有关数据库(如MEDLINE， EMBASE)、 查找已知文献的引文和向专家咨询。专家咨询的作用可避免漏选尚未印刷、 索引和引用的待发表或已发表的文献， 还可避免因漏选未发表文献而导致的“出版偏倚”--结果阳性的文章更易发表的倾向所造成的对干预因子作用的过高估计。除非文中介绍了文献检索的方法， 否则很难判断文献被漏选的情况。 即使对于全部以随机对照试验为素材的综述， 仍有必要了解原始研究的质量是否良好; 即使各个原始研究的结果是一致的， 仍有必要了解各原始研究的真实有效性。 目前， 尚无公认的评估真实有效性的标准方法。在各种评价方法中， 有些为复杂的考查条款， 有些仅包含三四条原则或要求。不妨参照本系列文章前几篇文章的要求来进行评价。 搜集文献、 评价原始研究的真实有效性并选取其中的数据是综述的重要环节， 但较易出现差错或偏倚。如果能安排两个或两个以上的人分别独立地进行， 且重复性或一致性良好， 那么综述的结果更加可信。 即使制定了严格的纳入标准， 但在病人、 暴露或干预、 结局指标和研究方法方面， 大多数系统性综述的素材(原始研究)之间仍会存在许多不同。我们必须判定这些不同的程度(或性质)是否严重影响到综合原始研究的结果或数据的基础。 对于定量的数据来说， 确定可否综合的标准之一是各个原始研究测量的效应关系具有相同的含义。在定量系统性综述中， 可以检验研究结果之间不同的程度是否超出了随机因素所致的预计范围及超出的程度。这种统计学分析称为“一致性检验”(齐性检验)。一致性检验的(差异)显着性越大， 原始研究之间结果的差异单独由机会所致的可能性越小， 但对不一致性“统计学意义”的解释应慎重。另一方面， 差异无显着性的检验结论并不能排除重大不一致性的存在。因此， 即使一致性检验的结果是差异无显着性， 但是如果原始研究结果之间的差异具有临床意义， 那么仍要求我们谨慎地解释综合的结果--总结果。然而， 即使原始研究之间的结果具有重大的差异， 只要所有被利用的原始研究的质量上乘， 综述的结果仍是干预或暴露作用的最佳估计值。 2 综述结果的含义 2.1 系统性综述总结果的含义 临床研究(原始)通过个体病人收集数据。系统性综述通过原始研究获取数据， 进而通过定量(或定性)的方法分析和综合之。 简单地比较原始研究中结果阳性的研究与阴性的数目的方法不是一种综合原始研究结果的好办法。系统性综述根据样本量权重各个原始研究， 样本大的研究， 权重也大， 从而得到的总结果是原始研究结果的加权平均值。有时根据研究的质量给予权重， 或劣质研究的权重定为零(剔除)， 并了解这种安排或调整是否会造成总结果的重大改变。 有时， 各个原始研究结果指标的性质相同， 但测量的方法或工具不同。例如， 同类的研究可能采用不同的方法测量功能状态， 如果病人标准和干预措施是相同的， 则仍值得对干预措施影响功能状态平均效应进行估计。一种实施这类估计的方法是通过“效应尺度”(effect size)来综合各个原始研究的结果。效应尺度是某一研究的干预组与对照组结局指标测得值之差的均数除以标准差的商。所以， 通过效应尺度能够计算以不同方法测量结果的许多原始研究的加权平均效应。你可能感到很难解释或理解效应尺度的临床意义。你不妨将其重新转换为熟悉其诊疗意义的指标。 通常， 我们希望系统性综述的结果为定量性综合的结果， 但是由于原始研究结果间不明原因的异质性或原始研究的质量很差， 进行定量性综合有时并不合适。此时， 可以通过图表“罗列”原始研究的结果。 可以通过可信区间来估计平均效应值的精度。 由于系统性综述包含许多单项研究， 它的优点之一是其结果来源于各式各样的病人。如果各单项研究的结果一致， 系统性综述的结果适用于这些单项研究中纳入的各式各样的病人。即使如此， 我们仍应对其结果的普遍性留有余地: 或许你的病入年龄比系统性综述纳入对象的年龄都大; 如果单项研究应用的药物不同， 我们就应考虑某药的作用是否比另一种药物的要好。 后一个问题涉及亚组分析问题。判定是否相信亚组分析结果的最重要的原则之一是对待研究间比较所得的结论应持怀疑的态度进行审查。如果存在下列情况， 亚组间存在差异的假设较为可信: 治疗效应的差别很大; 治疗效应的差异具有高度显着性统计学意义; 研究之前就假设存在着差异， 且数个假设的差异中仅该项被验证; 单项研究间的结果一致; 间接证据支持存在差异。如果不符合上述情况， 亚组分析的结果很少是真实的， 我们应该接受系统性综述的总结果， 而不是亚组分析的结果。 通过主题具体的以单一结局为指标的综述更有可能得到真实有效的结果或结论， 但这并不意味着我们可以忽略综述没有包含的结局: 临床决策需要考虑所有重要的临床结局。 临床决策的原则是预期效益必须大于潜在的风险和成本。治疗或预防决策时， 这一点很明确。向病人介绍病因或预后情况时， 同样存在着益处和害处的问题。 [Oxman AD,等. JAMA，1994，272:1367-1371 (英文)傅 鹰 摘译 吴廷王充 校译]

⑨ 系统综述怎么写

内容要求
文献综述是在研究选题确定后并在大量搜集、查阅相关文献的基础上，对相关课题或相关领域已有研究成果进行的综合性介绍，目的是理清本课题已有的研究基础及尚存的研究空间，它既可以给研究者在充分借鉴前人已有成果的基础上如何进一步深化本课题的研究指明方向，还可以帮助读者（或论文审阅者）明确本研究的新意所在。因此，写好文献综述，对于课题研究具有重要作用。
文献综述的结构一般由下列成份构成：
1、标题。文献综述的标题一般多是在论文选题的标题后加“研究综述”或“文献综述”字样。
2、提要或前言。此部分一般不用专设标题，而是直接作为整个文献综述的开篇部分。内容是简要介绍本课题研究的意义；将要解决的主要问题；如果本课题涉及到较前沿的理论，还应对该理论进行简要介绍；最后要介绍研究者搜集的资料范围及资料来源，其中要讲清查阅了哪些主要着作、在网络中查询了哪些资料库（如中国期刊网全文数据库、学位论文全文数据库等）、并以怎样的方式进行搜索（如通过输入“关键词”或“作者名”或“文章名”进行搜索，一般用精确匹配），共搜索到的相关论文的篇目数量多少，对自己有直接参考价值的论文有多少等信息。
3、正文。这是文献综述的核心部分。应在归类整理的基础上，对自己搜集到的有用资料进行系统介绍。撰写此部分时还应注意以下两点：
其一、对已有成果要分类介绍，各类之间用小标题区分。以下是常见的分类线索：按时空分类（如：本课题的研究历史与研究现状、国外研究现状与国内研究现状）；按本课题所涉及的不同子课题分类；按已有成果中的不同观点进行分类，等等。

⑩ 数据库如何设计

数据库设计的基本步骤
按照规范设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为以下6个阶段
1.需求分析
2.概念结构设计
3.逻辑结构设计
4.物理结构设计
5.数据库实施
6.数据库的运行和维护

数据库设计通常分为6个阶段1分析用户的需求，包括数据、功能和性能需求；2概念结构设计：主要采用E-R模型进行设计，包括画E-R图；3逻辑结构设计：通过将转换成表，实现从E-R模型到关系模型的转换；4：主要是为所设计的数据库选择合适的和存取路径；5数据库的实施：包括编程、测试和试运行；6数据库运行与维护：系统的运行与数据库的日常维护。）,主要讨论其中的第3个阶段,即逻辑设计。

在数据库设计过程中，需求分析和概念设计可以独立于任何数据库管理系统进行，逻辑设计和物理设计与选用的DAMS密切相关。

1.需求分析阶段（常用自顶向下）
进行数据库设计首先必须准确了解和分析用户需求（包括数据与处理）。需求分析是整个设计过程的基础，也是最困难，最耗时的一步。需求分析是否做得充分和准确，决定了在其上构建数据库大厦的速度与质量。需求分析做的不好，会导致整个数据库设计返工重做。
需求分析的任务，是通过详细调查现实世界要处理的对象，充分了解原系统工作概况，明确用户的各种需求，然后在此基础上确定新的系统功能，新系统还得充分考虑今后可能的扩充与改变，不仅仅能够按当前应用需求来设计。
调查的重点是，数据与处理。达到信息要求，处理要求，安全性和完整性要求。
分析方法常用SA(Structured Analysis) 结构化分析方法，SA方法从最上层的系统组织结构入手，采用自顶向下，逐层分解的方式分析系统。
数据流图表达了数据和处理过程的关系，在SA方法中，处理过程的处理逻辑常常借助判定表或判定树来描述。在处理功能逐步分解的同事，系统中的数据也逐级分解，形成若干层次的数据流图。系统中的数据则借助数据字典（data dictionary，DD）来描述。数据字典是系统中各类数据描述的集合，数据字典通常包括数据项，数据结构，数据流，数据存储，和处理过程5个阶段。