数据库的 题。。

1、若实体A和B是1对多的联系，实体B和C是1对1的联系，则实体A和C是1对1的联系。 B错 1对多

2、设一个学生关系为S(学生号，姓名)，课程关系为C(课程号，课程名)，选课关系为X(学生号，课程号，成绩)，求出所有选课的学生信息的运算表达式为∏学生号(X)与S的自然连接 A对

3、若一个关系的任何属性都不传递依赖任何候选码，则称该关系达到BC范式。 B错 对于关系模式R，若 R中的所有非平凡的、完全的函数依赖的决定因素是码，则R属于BCNF。

4、在SQL语句中，修改数据库表结构的命令是ALTER TABLE。 A对

5、在SQL语句中，删除数据库的命令是DELETE DATABASE。B错 drop

6、设置惟一值约束的列不可以为空。 B错 可以为空

7、SQL是结构化查询语言。A对

8、在SQL中，列级完整性约束分为4种情况，表级完整性约束分为6种情况。 B错 反了

9、在SQL中完整性约束分为列级完整性约束和表级完整性约束两个方面。 A对

10、数据库的内模式和模式都可以有多个。B 错 一个内模式 多个外模式

11、主键的字段的值可以为空。B错 主键 唯一不空

12、Order by子句对于查询结果的输出行数没有影响。A对

13、UNION运算符是用于将两个或多个检索结果合并成一个结果。A对

14、在SELECT语句中,如果要过滤结果集中的重复行,可以在字段列表前面加上DISTINCT。A对

15、数据库设计中的概念模型独立于硬件设备和DBMS。A对

定义1

严格地说，数据库是“按照数据结构来组织、存储和管理数据的仓库”。在经济管理的日常工作中，常常需要把某些相关的数据放进这样的“仓库”，并根据管理的需要进行相应的处理。例如，企业或事业单位的人事部门常常要把本单位职工的基本情况(职工号、姓名、年龄、性别、籍贯、工资、简历等)存放在表中，这张表就可以看成是一个数据库。有了这个"数据仓库"我们就可以根据需要随时查询某职工的基本情况，也可以查询工资在某个范围内的职工人数等等。这些工作如果都能在计算机上自动进行，那我们的人事管理就可以达到极高的水平。此外，在财务管理、仓库管理、生产管理中也需要建立众多的这种"数据库"，使其可以利用计算机实现财务、仓库、生产的自动化管理。 JMartin给数据库下了一个比较完整的定义：数据库是存储在一起的相关数据的集合，这些数据是结构化的，无有害的或不必要的冗余，并为多种应用服务；数据的存储独立于使用它的程序；对数据库插入新数据，修改和检索原有数据均能按一种公用的和可控制的方式进行。当某个系统中存在结构上完全分开的若干个数据库时，则该系统包含一个“数据库集合”。

定义2

数据库是依照某种数据模型组织起来并存放二级存储器中的数据集合。这种数据集合具有如下特点：尽可能不重复，以最优方式为某个特定组织的多种应用服务，其数据结构独立于使用它的应用程序，对数据的增、删、改和检索由统一软件进行管理和控制。从发展的历史看，数据库是数据管理的高级阶段，它是由文件管理系统发展起来的。

定义3

(伯尔尼公约议定书专家委员会的观点) 所有的信息(数据率档）的编纂物，不论其是以印刷形式，计算机存储单元形式，还是其它形式存在，都应视为“数据库”。 数字化内容选择的原因有很多，概括起来主要有： (1)存储空间的原因。数字化的产品是通过网络被广大用户存取利用，而大家都知道数字化产品是存放在磁盘阵列上的，磁盘阵列由服务器来管理，磁盘空间是有限的，服务器的能力也是有限的，不可能无限量地存入数字资源，这就需要我们对文献资源数字化内容进行选择。 (2)解决数字化生产高成本和图书馆经费有限性之间矛盾的需要。几乎没有图书馆有充足的资源来对整个馆藏进行数字化，内容选择不可避免。 (3)数字资源管理的需要。技术的快速发展使数字化项目所生成的数字资源的生命周期越来越短，投入巨资进行数字迁移是延长数字资源生命的1个重要途径，昂贵的维护成本就必须考虑数字化的内容选择。 数据库发展史数据库技术从诞生到现在，在不到半个世纪的时间里，形成了坚实的理论基础、成熟的商业产品和广泛的应用领域，吸引越来越多的研究者加入。数据库的诞生和发展给计算机信息管理带来了一场巨大的革命。三十多年来，国内外已经开发建设了成千上万个数据库，它已成为企业、部门乃至个人日常工作、生产和生活的基础设施。同时，随着应用的扩展与深入，数据库的数量和规模越来越大，数据库的研究领域也已经大大地拓广和深化了。30年间数据库领域获得了三次计算机图灵奖（CW Bachman,EFCodd, JGray），更加充分地说明了数据库是一个充满活力和创新精神的领域。就让我们沿着历史的轨迹，追溯一下数据库的发展历程。 传统上，为了确保企业持续扩大的IT系统稳定运行，一般用户信息中心往往不仅要不断更新更大容量的IT运维软硬件设备，极大浪费企业资源；更要长期维持一支由数据库维护、服务器维护、机房值班等各种维护人员组成的运维大军，维护成本也随之节节高升。为此，企业IT决策者开始思考：能不能像拧水龙头一样按需调节的使用IT运维服务？而不是不断增加已经价格不菲的运维成本。

定义4

数据库（DataBase，DB）是一个长期存储在计算机内的、有组织的、有共享的、统一管理的数据集合。她是一个按数据结构来存储和管理数据的计算机软件系统。数据库的概念实际包括两层意思： （1）数据库是一个实体，它是能够合理保管数据的“仓库”，用户在该“仓库”中存放要管理的事务数据，“数据”和“库”两个概念结合成为数据库。 （2）数据库是数据管理的新方法和技术，他能更合适的组织数据、更方便的维护数据、更严密的控制数据和更有效的利用数据。

影响数据检索效率的几个因素

数据检索有两种主要形态。第一种是纯数据库型的。典型的结构是一个关系型数据，比如 mysql。用户通过 SQL 表达出所需要的数据，mysql 把 SQL 翻译成物理的数据检索动作返回结果。第二种形态是现在越来越流行的大数据玩家的玩法。典型的结构是有一个分区的数据存储，最初这种存储就是原始的 HDFS，后来开逐步有人在 HDFS 上加上索引的支持，或者干脆用 Elasticsearc 这样的数据存储。然后在存储之上有一个分布式的实时计算层，比如 Hive 或者 Spark SQL。用户用 Hive SQL 提交给计算层，计算层从存储里拉取出数据，进行计算之后返回给用户。这种大数据的玩法起初是因为 SQL 有很多 ad-hoc 查询是满足不了的，干脆让用户自己写 map/reduce 想怎么算都可以了。但是后来玩大了之后，越来越多的人觉得这些 Hive 之类的方案查询效率怎么那么低下啊。于是一个又一个项目开始去优化这些大数据计算框架的查询性能。这些优化手段和经典的数据库优化到今天的手段是没有什么两样的，很多公司打着搞计算引擎的旗号干着重新发明数据库的活。所以，回归本质，影响数据检索效率的就那么几个因素。我们不妨来看一看。

数据检索干的是什么事情

定位 => 加载 => 变换

找到所需要的数据，把数据从远程或者磁盘加载到内存中。按照规则进行变换，比如按某个字段group by，取另外一个字段的sum之类的计算。

影响效率的四个因素

读取更少的数据

数据本地化，充分遵循底层硬件的限制设计架构

更多的机器

更高效率的计算和计算的物理实现

原则上的四点描述是非常抽象的。我们具体来看这些点映射到实际的数据库中都是一些什么样的优化措施。

读取更少的数据

数据越少，检索需要的时间当然越少了。在考虑所有技术手段之前，最有效果的恐怕是从业务的角度审视一下我们是否需要从那么多的数据中检索出结果来。有没有可能用更少的数据达到同样的效果。减少的数据量的两个手段，聚合和抽样。如果在入库之前把数据就做了聚合或者抽样，是不是可以极大地减少查询所需要的时间，同时效果上并无多少差异呢？极端情况下，如果需要的是一天的总访问量，比如有1个亿。查询的时候去数1亿行肯定快不了。但是如果统计好了一天的总访问量，查询的时候只需要取得一条记录就可以知道今天有1个亿的人访问了。

索引是一种非常常见的减少数据读取量的策略了。一般的按行存储的关系型数据库都会有一个主键。用这个主键可以非常快速的查找到对应的行。KV存储也是这样，按照Key可以快速地找到对应的Value。可以理解为一个Hashmap。但是一旦查询的时候不是用主键，而是另外一个字段。那么最糟糕的情况就是进行一次全表的扫描了，也就是把所有的数据都读取出来，然后看要的数据到底在哪里，这就不可能快了。减少数据读取量的最佳方案就是，建立一个类似字典一样的查找表，当我们找 username=wentao 的时候，可以列举出所有有 wentao 作为用户名的行的主键。然后拿这些主键去行存储（就是那个hashmap）里捞数据，就一捞一个准了。

谈到索引就不得不谈一下一个查询使用了两个字段，如何使用两个索引的问题。mysql的行为可以代表大部分主流数据库的处理方式：

基本上来说，经验表明有多个单字段的索引，最后数据库会选一最优的来使用。其余字段的过滤仍然是通过数据读取到内存之后，用predicate去判断的。也就是无法减少数据的读取量。

在这个方面基于inverted index的数据就非常有特点。一个是Elasticsearch为代表的lucene系的数据库。另外一个是新锐的druid数据库。

效果就是，这些数据库可以把单字段的filter结果缓存起来。多个字段的查询可以把之前缓存的结果直接拿过来做 AND 或者 OR *** 作。

索引存在的必要是因为主存储没有提供直接的快速定位的能力。如果访问的就是数据库的主键，那么需要读取的数据也就非常少了。另外一个变种就是支持遍历的主键，比如hbase的rowkey。如果查询的是一个基于rowkey的范围，那么像hbase这样的数据库就可以支持只读取到这个范围内的数据，而不用读取不再这个范围内的额外数据，从而提高速度。这种加速的方式就是利用了主存储自身的物理分布的特性。另外一个更常见的场景就是 partition。比如 mysql 或者 postgresql 都支持分区表的概念。当我们建立了分区表之后，查找的条件如果可以过滤出分区，那么可以大幅减少需要读取的数据量。比 partition 更细粒度一些的是 clustered index。它其实不是一个索引（二级索引），它是改变了数据在主存储内的排列方式，让相同clustered key的数据彼此紧挨着放在一起，从而在查询的时候避免扫描到无关的数据。比 partition 更粗一些的是分库分表分文件。比如我们可以一天建立一张表，查询的时候先定位到表，再执行 SQL。比如 graphite 给每个 metric 创建一个文件存放采集来的 data point，查询的时候给定metric 就可以定位到一个文件，然后只读取这个文件的数据。

另外还有一点就是按行存储和按列存储的区别。按列存储的时候，每个列是一个独立的文件。查询用到了哪几个列就打开哪几个列的文件，没有用到的列的数据碰都不会碰到。反观按行存储，一张中的所有字段是彼此紧挨在磁盘上的。一个表如果有100个字段，哪怕只选取其中的一个字段，在扫描磁盘的时候其余99个字段的数据仍然会被扫描到的。

考虑一个具体的案例，时间序列数据。如何使用读取更少的数据的策略来提高检索的效率呢？首先，我们可以保证入库的时间粒度，维度粒度是正好是查询所需要的。如果查询需要的是5分钟数据，但是入库的是1分钟的，那么就可以先聚合成5分钟的再存入数据库。对于主存储的物理布局选择，如果查询总是针对一个时间范围的。那么把 timestamp 做为 hbase 的 rowkey，或者 mysql 的 clustered index 是合适。这样我们按时间过滤的时候，选择到的是一堆连续的数据，不用读取之后再过滤掉不符合条件的数据。但是如果在一个时间范围内有很多中数据，比如1万个IP，那么即便是查1个IP的数据也需要把1万个IP的数据都读取出来。所以可以把 IP 维度也编码到 rowkey 或者 clustered index 中。但是假如另外还有一个维度是 OS，那么查询的时候 IP 维度的 rowkey 是没有帮助的，仍然是要把所有的数据都查出来。这就是仅依靠主存储是无法满足各种查询条件下都能够读取更少的数据的原因。所以，二级索引是必要的。我们可以把时间序列中的所有维度都拿出来建立索引，然后查询的时候如果指定了维度，就可以用二级索引把真正需要读取的数据过滤出来。但是实践中，很多数据库并不因为使用了索引使得查询变快了，有的时候反而变得更慢了。对于 mysql 来说，存储时间序列的最佳方式是按时间做 partition，不对维度建立任何索引。查询的时候只过滤出对应的 partition，然后进行全 partition 扫描，这样会快过于使用二级索引定位到行之后再去读取主存储的查询方式。究其原因，就是数据本地化的问题了。

[page]

数据本地化

数据本地化的实质是软件工程师们要充分尊重和理解底层硬件的限制，并且用各种手段规避问题最大化利用手里的硬件资源。本地化有很多种形态

最常见的最好理解的本地化问题是网络问题。我们都知道网络带宽不是无限的，比本地磁盘慢多了。如果可能尽量不要通过网络去访问数据。即便要访问，也应该一次抓取多一些数据，而不是一次搞一点，然后搞很多次。因为网络连接和来回的开销是非常高的。这就是 data locality 的问题。我们要把计算尽可能的靠近数据，减少网络上传输的数据量。

这种带宽引起的本地化问题，还有很多。网络比硬盘慢，硬盘比内存慢，内存比L2缓存慢。做到极致的数据库可以让计算完全发生在 L2 缓存内，尽可能地避免频繁地在内存和L2之间倒腾数据。

另外一种形态的问题化问题是磁盘的顺序读和随机读的问题。当数据彼此靠近地物理存放在磁盘上的时候，顺序读取一批是非常快的。如果需要随机读取多个不连续的硬盘位置，磁头就要来回移动从而使得读取速度快速下降。即便是 SSD 硬盘，顺序读也是要比随机读快的。

基于尽可能让数据读取本地化的原则，检索应该尽可能地使用顺序读而不是随机读。如果可以的话，把主存储的row key或者clustered index设计为和查询提交一样的。时间序列如果都是按时间查，那么按时间做的row key可以非常高效地以顺序读的方式把数据拉取出来。类似地，按列存储的数据如果要把一个列的数据都取出来加和的话，可以非常快地用顺序读的方式加载出来。

二级索引的访问方式典型的随机读。当查询条件经过了二级索引查找之后得到一堆的主存储的 key，那么就需要对每个 key 进行一次随机读。即便彼此仅靠的key可以用顺序读做一些优化，总体上来说仍然是随机读的模式。这也就是为什么时间序列数据在 mysql 里建立了索引反而比没有建索引还要慢的原因。

为了尽可能的利用顺序读，人们就开始想各种办法了。前面提到了 mysql 里的一行数据的多个列是彼此紧靠地物理存放的。那么如果我们把所需要的数据建成多个列，那么一次查询就可以批量获得更多的数据，减少随机读取的次数。也就是把之前的一些行变为列的方式来存放，减少行的数量。这种做法的经典案例就是时间序列数据，比如可以一分钟存一行数据，每一秒的值变成一个列。那么行的数量可以变成之前的1/60。

但是这种行变列的做法在按列存储的数据库里就不能直接照搬了，有些列式数据库有column family的概念，不同的设置在物理上存放可能是在一起的也可能是分开的。对于 Elasticsearch 来说，要想减少行的数量，让一行多pack一些数据进去，一种做法就是利用 nested document。内部 Elasticsearch 可以保证一个 document 下的所有的 nested document是物理上靠在一起放在同一个 lucene 的 segment 内。

网络的data locality就比较为人熟知了。map reduce的大数据计算模式就是利用map在数据节点的本地把数据先做一次计算，往往计算的结果可以比原数据小很多。然后再通过网络传输汇总后做 reduce 计算。这样就节省了大量网络传输数据的时间浪费和资源消耗。现在 Elasticsearch 就支持在每个 data node 上部署 spark。由 spark 在每个 data node 上做计算。而不用把数据都查询出来，用网络传输到 spark 集群里再去计算。这种数据库和计算集群的混合部署是高性能的关键。类似的还有 storm 和 kafka 之间的关系。

网络的data locality还有一个老大难问题就是分布式大数据下的多表join问题。如果只是查询一个分布式表，那么把计算用 map reduce 表达就没有多大问题了。但是如果需要同时查询两个表，就意味着两个表可能不是在物理上同样均匀分布的。一种最简单的策略就是找出两张表中最小的那张，然后把表的内容广播到每个节点上，再做join。复杂一些的是对两个单表做 map reduce，然后按照相同的 key 把部分计算的结果汇集在一起。第三种策略是保证数据分布的方式，让两张表查询的时候需要用到的数据总在一起。没有完美的方案，也不大可能有完美的方案。除非有一天网络带宽可以大到忽略不计的地步。

更多的机器

这个就没有什么好说的了。多一倍的机器就多一倍的 CPU，可以同时计算更多的数据。多一倍的机器就多一倍的磁头，可以同时扫描更多的字节数。很多大数据框架的故事就是讲如何如何通过 scale out解决无限大的问题。但是值得注意的是，集群可以无限大，数据可以无限多，但是口袋里的银子不会无限多的。堆机器解决问题比升级大型机是要便宜，但是机器堆多了也是非常昂贵的。特别是 Hive 这些从一开始就是分布式多机的检索方案，刚开始的时候效率并不高。堆机器是一个乘数，当数据库本来单机性能不高的时候，乘数大并不能起到决定性的作用。

更高效的计算和计算实现

检索的过程不仅仅是磁盘扫描，它还包括一个可简单可复杂的变换过程。使用 hyperloglog，count min-sketch等有损算法可以极大地提高统计计算的性能。数据库的join也是一个经常有算法创新的地方。

计算实现就是算法是用C++实现的还是用java，还是python实现的。用java是用大Integer实现的，还是小int实现的。不同的语言的实现方式会有一些固定的开销。不是说快就一定要C++，但是 python 写 for 循环是显然没有指望的。任何数据检索的环节只要包含 python/ruby 这些语言的逐条 for 循环就一定快不起来了。

结论

希望这四点可以被记住，成为一种指导性的优化数据检索效率的思维框架。无论你是设计一个mysql表结构，还是优化一个spark sql的应用。从这四个角度想想，都有哪些环节是在拖后腿的，手上的工具有什么样的参数可以调整，让随机读变成顺序读，表结构怎么样设计可以最小化数据读取的量。要做到这一点，你必须非常非常了解工具的底层实现。而不是盲目的相信，xx数据库是最好的数据库，所以它一定很快之类的。如果你不了解你手上的数据库或者计算引擎，当它快的时候你不知道为何快，当它慢的时候你就更加无从优化了。

7个因素决定大数据的复杂性 如何处理

 我们谈论了很多关于复杂数据及其为你的商业智能带来的挑战和机遇，但是导致数据复杂化的是什么呢？

以及你如何区分你的公司当前的数据是否是“复杂的”，亦或不久的将来会变得复杂？本文将解决这些问题。

为什么这很重要？

当你试图将数据转化为商业价值时，它的复杂度很可能会预示你将面对的困难程度——复杂数据的准备和分析通常要比简单数据更加困难，以及通常需要一组不同的BI 工具来实现。复杂数据在可以“成熟的”分析和可视化之前需要额外的准备工作和数据模型。因此重要的是，通过了解您目前的数据的复杂程度以及它在未来的复杂性趋向，来评估您的大数据/商业智能项目是否能够胜任这一任务。

简单测试：大数据或者异构数据

在高级层面上，有两种基本的迹象表明你的数据可能被视为是复杂的：

你的数据很“大”：我们把大放在引号里是因为它貌似符合“大数据”术语的含义。然而事实是，处理海量数据在计算资源需要处理巨大的数据集方面提出了一个挑战， 就像把小麦从谷壳分开的困难，或者说在一个巨大的原始信息中辨别信号和杂音。

你的数据来自许多不同的数据源：多重数据源通常意味着脏数据，或者遵循着不同的内部逻辑结构的简单的多个数据集。为了确保数据源有统一的数据语言，数据必须被转换或整合到一个中央资源库。

可以认为这是两个最初的（可供选择的）征兆：如果你正处理大数据或异构数据，你应当开始思考数据的复杂性。但是深究一下，对你的公司的数据的复杂性，以下有7个更具体的指标。

（注意，以上两点之间有相似之处，但不互相排除——反之，例如，离散数据往往意味着各种各样的数据结构类型）

7个因素决定你的数据的复杂性

1、数据结构

不同数据源的数据，或甚至来自同一个源的不同表，通常设计同样的信息但结构却完全不同：

举例来说，想象你们人力资源部有三种不同的表格，一个是员工个人信息表，另一个是员工职位和薪资表第三个是员工职位要求表，诸如此类——而你们财务部门随同保险、福利和其他花费一起记录同样的信息到单个表中。另外，在这些表中的一些表可能提到员工的全名，而另一些则只有名字的首字母，或者二者的结合。为了从所有表中有效使用数据，同时不丢失或重复信息，需要数据建模或准备工作。

这是最简单的用例：更进一步复杂化的是处理最初没有适当地模式的非结构化数据源（例如NoSQL 数据库）。

2、数据大小

再次回到模糊的“大数据”概念，你收集的数据量会影响你需要用来分析它的软硬件的类型。这个可以通过原始大小来衡量：字节，TB或PB——数据增长越大，越有可能“窒息”广泛使用的内存数据库（IMDB），依赖于转化压缩数据到服务器内存。其他因素包括多元异构数据——包含很多数据行的表（Excel，可以说是最常用的数据分析工具，最大行数限制为1048576行），或结构化数据——包含很多数据列的表。

你将会发现在分析工具和方法上用于分析100,000行数据和那些用于分析1亿行数据的是明显不同的。

3、数据细节

你想要探索的数据的粒度水平。当创建一个仪表盘或报表，展现总结或聚合数据时常常比让终端用户钻取到每一个细节更容易实现——然而这是以牺牲数据分析的深度和数据挖掘为代价而做的权宜之计。

创建一个BI系统，使其具有颗粒向海量数据钻取处理分析的能力，（不依赖于预定义查询，聚合或汇总表）

4、查询语言

不同的数据源有不同的数据语言：虽然SQL是从常见数据源和RDBMS提取数据的主要手段，但是当使用第三方平台时你会经常需要通过它自己的API和语法去连接它，以及解析用于访问数据的数据模型和协议。

你的BI工具需要足够灵活的根据数据源允许这种本地连接的方式，或者通过内置插件或API访问，否则你会发现你自己将不得不重复一个繁琐的导出数据到表格SQL数据库数据仓库的过程，然后导入到你的商业智能软件里，从而使你的分析变得麻烦。

5、数据类型

一方面动态数据以表格形式存储，处理的大多是数值型数据，但是大规模和非结构化的机器数据完全是另外一回事儿，就像是文字数据集存储在MongoDB中，当然了，更别提像视频音频这种超大规模的非结构化数据了。

不同的数据类型具有不同的规则，为使得商业决策建立在对公司数据的全面考虑的基础上，找到一种建立单一可信来源的方法是至关重要的。

6、离散数据

数据存储在多个位置：例如，组织里的不同部门，本地或云（付费存储或通过云应用），来自客户或供应商的外部数据等。这种数据不仅收集起来很困难（简单来说是由于及时而有效的接收数据而需要的利益相关者的数量）。而且一旦收集了——在不同的数据集交叉引用和分析之前，通常需要“清理”或标准化，因为每个本地数据集是根据相关组织应用程序自身的实际和关注收集数据。

7、数据量的增长

最终，你不仅需要考虑当前数据，还有数据的增长或变化的速度。如果经常更新数据源，或经常增加新的数据源，这将会消耗你的软硬件资源（无论何时当源数据发生重大更改时,不是非常先进的系统都需要重新获取整个数据集）,以及上述提到的关于结构、类型、大小的复合性问题等。

怎样掌控复杂数据？

如果你认同上述的一个或更多以及你的数据刚刚好是复杂的，不要绝望：理解，是找到一个合适的解决方案的第一步，以及复杂数据的分析本身不需要过于复杂。我们将在未来的文章中涉及解决复杂数据的方法，但是你将想问自己的第一件事可能是——控制复杂数据你实际需要多少BI系统。

以上是小编为大家分享的关于7个因素决定大数据的复杂性 如何处理的相关内容，更多信息可以关注环球青藤分享更多干货

第一：各个参数是否对应的一个对象（面向对象编程思想）；

第二：各个参数可能类型和出现的最大长度，之后合理的设计各个字段的最大长度和相应类型；

第三：各个参数中哪些字段具有唯一性，考虑作为主键或者是外键来进行表关联；

第四：根据数据量的大小来考虑是否需要进行分区处理；

第五：哪些字段是不经常便跟字段，可以考虑进行多张表的存储来节省存储空间（可能影响查询修改效率）

以上就是关于数据库的 题。。全部的内容，包括:数据库的 题。。、数据库定义、影响数据检索效率的几个因素等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！