精华内容
下载资源
问答
  • 常见数据库场景分析

    千次阅读 2016-08-07 22:00:25
    常见数据库场景分析 2 一 关系型数据库 2 1.关系型数据简介 2 2.常用的概念 2 4.特点 3 5.常见关系型数据库 3 二 常见非关系型数据库(NoSQL)场景分析 3 1、NoSQL的特性 3 2、根据需求进行分类 4 2.1满足...

    常见数据库场景分析 2

    一 关系型数据库 2

    1.关系型数据简介 2

    2.常用的概念 2

    4.特点 3

    5.常见关系型数据库 3

    二 常见非关系型数据库(NoSQL)场景分析 3

    1、NoSQL的特性 3

    2、根据需求进行分类 4

    2.1满足极高读写性能需求的Kye-Value数据库:Redis,Tokyo Cabinet, Flare 4

    2.2 满足海量存储需求和访问的面向文档的数据库:MongoDB,CouchDB 7

    2.3满足高可扩展性和可用性的面向分布式计算的数据库:Cassandra,Voldemort 9

     

     

     

     

     

     

    常见数据库场景分析

    一 关系型数据库

    1.关系型数据简介
    关系型数据库,是指采用了关系模型来组织数据的数据库。 简单来说,关系模型指的就是二维表格模型,而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。

    2.常用的概念
    关系:可以理解为一张二维表,每个关系都具有一个关系名,就是通常说的表名 ·

    元组:可以理解为二维表中的一行,在数据库中经常被称为记录

    属性:可以理解为二维表中的一列,在数据库中经常被称为字段

    域:属性的取值范围,也就是数据库中某一列的取值限制 
    · 关键字:一组可以唯一标识元组的属性,数据库中常称为主键,由一个或多个列组成 
    · 关系模式:指对关系的描述。其格式为:关系名(属性1,属性2,... ,属性N),在数据库中成为表结构 
    3.优点 
    ·  容易理解:二维表结构是非常贴近逻辑世界的一个概念,关系模型相对网状、层次等其他模型来说更容易理解 
    · 使用方便:通用的SQL语言使得操作关系型数据库非常方便

    易于维护:丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了

    4.特点

    1)数据库事务一致性需求 

    2)数据库的写实时性和读实时性需求

    3)对复杂的SQL查询,特别是多表关联查询的需求(join)

    4)常见的关系型数据库

    5.常见关系型数据库

    oracle、SQL Server、Sybase、DB2、Access

     

    二 常见非关系型数据库(NoSQL)场景分析

    1、NoSQL的特性

    1)High performance – 对数据库高并发读写的需求 

    2)Huge Storage – 对海量数据的高效率存储和访问的需求 

    3)High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求

    2、根据需求进行分类

    2.1满足极高读写性能需求的Kye-Value数据库:Redis,Tokyo Cabinet, Flare

    高性能Key-Value数据库的主要特点就是具有极高的并发读写性能,Redis,Tokyo Cabinet, Flare,这3个Key-Value DB都是用C编写的。

    2.1.1 Redis

    本质:一个Key-Value类型的内存数据库

    机制:很像memcached(memcached是一套分布式的高速缓存系统),整个数据库统 统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。

    特色:

    1)纯内存操作

    2)性能非常出色

    3)10万次读写操作/秒

    4)性能最快的Key-Value DB

    5)单个value的最大限制为1GB

    6)支持保存List链表和Set集合的数据结构,而且还支持对List进行各种操作

    Eg:从 List两端push和pop数据,取List区间,排序等等,对Set支持各种集合的并集交集操作,此外单个value的最大限制是1GB,不像 memcached只能保存1MB的数据,因此Redis可以用来实现很多有用的功能,比方说用他的List来做FIFO双向链表,实现一个轻量级的高性 能消息队列服务,用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一 个功能加强版的memcached来用。

    缺点:

    1)数据库容量受到物理内存的限制,不能用作海量数据的高性能读

    2)没有原生的可扩展机制,不具有scale(可扩展)能力,要依赖客户端来实现分布式读写。

    适合的场景:

    主要局限在较小数据量的高性能操作和运算上。

    目前使用Redis的网站:github,Engine Yard。

    2.1.2 Tokyo Cabinet和Tokoy Tyrant

    Tokyo Cabinet:一个key-value的DBM数据库,但是没有提供网络接口,以下称TC。

    Tokoy Tyrant:是为TC写的网络接口,他支持memcache协议,也可以通过HTTP操作,以下称TT。

    TC和TT的开发者是日本人Mikio Hirabayashi,主要被用在日本最大的SNS网站mixi.jp上,TC发展的时间最早,现在已经是一个非常成熟的项目,也是Kye-Value 数据库领域最大的热点,现在被广泛的应用在很多很多网站上。

    本质:

    TC是一个高性能的存储引擎

    TT提供了多线程高并发服务器

    支持高并发的分布式持久存储系统

    特色:

    1)4-5万次读写操作/秒。

    2)极高的并发读写性能&可靠的数据持久化机制

    3)支持类似关系数据库表结构的hashtable以及简单的条件,分页和排序操作。

    4)可以缓存磁盘数据的存储系统

    5)支持异步的写入机制

    缺点:

    1)没有scale的能力,如果单机无法满足要求,只能通过主从复制的方式扩展

    2)性能会随着数据量的增加而下降,当数据量 上亿条以后,性能会有比较明显的下降。

    3)在32位操作系统下,作为 Tokyo Tyrant 后端存储的 Tokyo Cabinet 数据库单个文件不能超过2G ,而64位操作系统则不受这一限制。所以,如果使用 Tokyo Tyrant,推荐在64位CPU、操作系统上安装运行

     

    备注:http://blog.chinaunix.net/uid-20556054-id-3321331.html

    2.1.3 Flare

    Flare简单的说就是给TC添加了 scale功能。他替换掉了TT部分,自己另外给TC写了网络服务器,

    特点:

    支持scale能力,他在网络服务端之前添加了一个 node server,来管理后端的多个服务器节点,因此可以动态添加数据库服务节点,删除服务器节点,也支持failover。如果你的使用场景必须要让TC可以scale,那么可以考虑flare。

    缺点:

    只支持memcached协议,因此当你使用flare的时候,就不能使用TC的table数据结构了,只能使用TC的 key-value数据结构存储。

    2.2 满足海量存储需求和访问的面向文档的数据库:MongoDB,CouchDB

    面向文档的非关系数据库主要解决的问题不是高性能的并发读写,而是保证海量数据存储的同时,具有良好的查询性能。MongoDB是用C++开发的,而 CouchDB则是Erlang开发的

    2.2.1 MongoDB

    MongoDB是一个介于关系数据库和非关系数据库之间的产品

    特点:

    1)非关系数据库当中功能最丰富,最像关系数据库。

    2)支持的数据结构非常松散,是类似 json的bjson格式,可以存储比较复杂的数据类型。

    3)支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能

    4)支持对数据建立索引。

    5)海量数据的访问效率,官方的文档,当数据量达到50GB以上的时候,Mongo的数据库访问速度是MySQL的10倍以上

    缺点:

    并发读写效率一般,0.5万-1.5万次读写/秒

    2.2.2 CouchDB

    特点:

    1)CouchDB是分布式的数据库,他可以把存储系统分布到n台物理的节点上面,并且很好的协调和同步节点之间的数据读写一致性。

    CouchDB是面向文档的数据库,存储半结构化的数据,比较类似lucene的index结构,特别适合存储文档,因此很适合CMS,电话本,地址本等应用,在这些应用场合,文档数据库要比关系数据库更加方便,性能更好。

    3)CouchDB支持REST API,可以让用户使用JavaScript来操作CouchDB数据库,也可以用JavaScript编写查询语句。

    缺点:

    仅仅提供了基于HTTP REST的接口并发读写性能不好

    2.3满足高可扩展性和可用性的面向分布式计算的数据库:Cassandra,Voldemort

    面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样,它首先必须是一个分布式的数据库系统,由分布在不同节点上面的数据库共同 构成一个数据库服务系统,并且根据这种分布式架构来提供online的,具有弹性的可扩展能力,例如可以不停机的添加更多数据节点,删除数据节点等等。因 此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的:

    2.3.1 Cassandra(卡桑德拉)
    Cassandra项目是Facebook在2008年开源出来的。目前除了 Facebook之外,twitter和digg.com都在使用Cassandra。

    Cassandra的主要特点就是它不是一个数据库,而是由一堆数据库节点共同构成的一个分布式网络服务,对Cassandra的一个写操作,会被复制到 其他节点上去,对Cassandra的读操作,也会被路由到某个节点上面去读取。对于一个Cassandra群集来说,扩展性能是比较简单的事情,只管在群集里面添加节点就可以了。

    特性:

    1)分布式

    2)基于column的结构化

    3)高伸展性

    特点:

    1)模式灵活 :使用Cassandra,像文档存储,你不必提前解决记录中的字段。你可以在系统运行时随意的添加或移除字段。这是一个惊人的效率提升,特别是在大型部署上。

    2)真正的可扩展性 :Cassandra是纯粹意义上的水平扩展。为给集群添加更多容量,可以指向另一台计算机。你不必重启任何进程,改变应用查询,或手动迁移任何数据。

    3) 多数据中心识别 :你可以调整你的节点布局来避免某一个数据中心起火,一个备用的数据中心将至少有每条记录的完全复制。

    2.3.2 Voldemort(伏地魔)
    Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统,Voldemort则来自于Linkedin这个SNS网站。Voldemort的资料不是很多,因此我没有特别仔细去钻研,Voldemort官方给出Voldemort的并发读 写性能也很不错,每秒超过了1.5万次读写。

    Voldemort是一个分布式键-值(Key-value)存储系统,是Amazon's Dynamo的一个开源克隆。

    特点:
    1)支持自动复制数据到多个服务器上。
    2)支持数据自动分割所以每个服务器只包含总数据的一个子集。
    3)提供服务器故障透明处理功能。
    4)支持可拨插的序化支持,以实现复杂的键-值存储,它能够很好的

    5)集成常用的序化框架如:Protocol Buffers、Thrift、Avro和Java Serialization。
    6)数据项都被标识版本能够在发生故障时尽量保持数据的完整性而不会影响系统的可用性。
    7)每个节点相互独立,互不影响。
    8)支持可插拔的数据放置策略。

     

    备注:http://www.360doc.com/content/11/0429/15/2560742_113169460.shtml

     

     

    展开全文
  • 使用PowerDesigner做数据库设计(一) ​ 使用PowerDesigner进行数据库设计,去年是第一次使用,使用它完成了一次小型的数据库设计。今年是第二次使用,中间间隔了几个月,再次打开PowerDesigner时,已经把使用步骤...

    使用PowerDesigner做数据库设计(一)

    ​ 使用PowerDesigner进行数据库设计,去年是第一次使用,使用它完成了一次小型的数据库设计。今年是第二次使用,中间间隔了几个月,再次打开PowerDesigner时,已经把使用步骤忘记个差不多了,有些还需要再去查找一下资料。为了能够把PowerDesigner使用步骤刻在脑子里,这次对PowerDesigner的常规使用步骤做一些记录,来加深印象,日后忘记时,有的查找,毕竟自己写过的东西能够再现出使用场景来。

    E-R:实体关系模型–》到不同的数据库,数据库开发人员可以根据ER图,设计出不同数据库的表。

    需求分析 概要设计 详细设计 数据库设计

    PowerDesigner:作用,用来做数据库建模,设计概念模型 物理模型 ,最终都反映到数据库,以及设计的正向和逆向工程导入使用。

    Sybase公司的工具集。

    作为一名使用PowerDesigner的小白,如何快速上手呢,为何强调快速上手,主要因为用不到的时候不愿意主动学习,用到的时候多半是任务紧迫,要在有限的时间内做出设计来。恐怕这时,连翻书都没有耐心翻下去了。

    初识PowerDesigner

    使用PowerDesigner做数据库设计,主要用到两个大的模型,第一个是CDM,第二个是PDM。使用步骤大抵如下,先创建CDM,然后把CDM转化成PDM,最后把PDM转化成数据库sql执行语句,还可以把PDM转化成word可视化数据库文档。可执行的sql语句和可视化word文档是做设计的最终成果,sql语句用于创建数据库,可视化word文档用于团队成员的沟通、开发及后期维护。PowerDesigner工具的亮点就是生成可执行的sql语句、可视化的word数据库文档。能不能快速高效地做出一份数据库设计,关键在于CDM的设计

    *概念数据模型CDM介绍*

    CDM是ConceptualDataMode的英文简称,概念数据模型的意思。在CDM中,有几个要素需要熟识一下,第一个是实体entity,第二个是实体entity中的属性attributes,也就是列。第三个是domains,域是对属性attributes的归类,可以提前创建域。在设置实体entity中的属性attributes时,先创建好属性的名称name和编码code,然后选择合适的域domains,就可以设定属性的数据类型datatype和长度length。第四个是关系relationship,也就是两个实体之间的关联关系,是一对一的关系,还是一对多的关系,还是多对多的关系。第五个是关联association,关联是实体的多对多关系,在做数据设计时,一对多时,可以把一存储在多的表中做外键,多对多时,需要另外建一个表进行关联,这就是关联association。在CDM中表现为关联association,用于区别一般的实体。还漏掉了一个就是标识符identifier就是实体中的主键

    *CDM创建,手把手实际操作*

    第一步,创建概念数据模型CDM,并对其命名。

    打开PowerDesigner工具,在工具栏点击文件,在打开的菜单栏中,选择第一个选项->建立新模型,在建立新模型的窗口,选择第二个模型,在modelname中对模型重新命名,最后点击OK按钮。

    img

    图-2

    第二步,创建域domains,也可以从其他现成的地方拷贝过来。

    1) 在 CDM模型 数据库设计 上点击鼠标右键,选中list of,在出现的列表中选中domains,出现如下窗口:

    img

    图-3

    2) 在此窗口,添加name、code,code可以不填,让其自动填充,并设置数据类型datatype和长度length,设置数据类型和长度是关键,后面的实体属性会继承这里的数据类型和长度,最后点击ok按钮进行保存,如下图所示:

    img

    图-4

    第三步,创建实体entity。

    1) 在窗口的右上角有一个悬浮框palette,有一个四方形的图表,鼠标移上去时会有一个entity的标识,没错,就是它了,点击这个图表,在空白的地方,点击一下就绘出实体entity的图表

    img

    图-5

    img

    图-6

    2) 点击悬浮框palette中的箭头pointer图表,让鼠标恢复状态,然后双击其中的一个实体,即可对实体进行name和code的命名,命名之后点击应用。点击应用不会关闭当前窗口,点击确定会关闭当前窗口。

    img

    图-7

    第四步,创建实体entity中的属性attribute。

    1) 接着上一个窗口,在entity窗口中,点击属性attribute,在这一栏目里可进行属性的name和code创建,name对应的是中文描述,code对应的数据库字段名称。

    img

    图-8

    2) 接着为每个字段选择对应的domain,点击domain下的None区域时,会出现下拉列表,从下拉列表选择合适的domain,domain不存在时,可以再次新增,新增后重新打开窗口再次选择对应的domain。

    img

    图-9

    3) 如果此时想添加备注,但是列表中并没有备注,可点击菜单栏下,漏斗下带笔的小图标勾选出备注comment,这时就可以看到备注一栏了。

    img

    图-10

    img

    图-11

    4) 在上图中有一个细节,就是在备注comment之前,有三个字母,每个字母下面有个复选框,这是什么意思呢,P是PrimaryIdentifier是否为主键表述的缩写,勾选了P就代表当前被勾选字段是该表的主键。M是Mandatory的缩写,属性值是否允许为空的意思。D是displayed的缩写,表示是否在实体图形符号中显示该属性。

    5) 还有一个Identifiers标识符,可以把主键的code拷贝过去,设置这个的好处是,可以在关系图中,一下子就能清楚地看到某个表的主键是哪个,是否有设置。

    img

    图-12

    第五步,创建实体entity之间的一对一、一对多关系的关联relationship。

    几种关系:一对一 一对多 多对一 多对多

    1) 现在有两个实体,一个是班级,一个是学生,一个班级存在多名学生,一个学生只能在一个班级上课,这就是一对多的关系,在右边悬浮框palette中有一个提示文字为Raletionship的图标,就是关系的映射,点击这个图标,按住鼠标的左键,从一个实体拖往另一个实体,通常是从一对多的关系开始拖这个图标,到多的实体停止这个图标。

    img

    图-13

    2) 鼠标拖过之后,再次点击箭头pointer图标,恢复鼠标状态,然后双击关系这条线,对关系进行编辑,对关系的name和code进行命名。

    img

    图-14

    3) 点击cardinalities栏目,可以对关系重新设置,设置班级和学生的关系是0对N关系,还是1对N关系,最后点击OK按钮保存。

    img

    图-15

    第六步,创建实体entity之间的多对多关联association。

    1) 在实际场景中,一个学生可以选择多个课程,一个课程也可以被多个学生选择,这就是多对多的关系,在右边悬浮框palette中选择association图表,在空白区域创建一个association,association可以看做是关系变形成的实体,对association极其属性进行命名。

    img

    图-16

    img

    图-17

    2) 接着绘制学生和这张关系的关联,在右边悬浮框中,有一个association link图标,这个图标就是代码实体域关联关系之间的连接,点击这个图标,从实体拖向association,即可建立关系。

    img

    至此,概念数据模型cdm的创建已经告一个段落了,你get到了吗?

    nk图标,这个图标就是代码实体域关联关系之间的连接,点击这个图标,从实体拖向association,即可建立关系。

    [外链图片转存中…(img-GhxYTlho-1603276820936)]

    至此,概念数据模型cdm的创建已经告一个段落了,你get到了吗?

    展开全文
  • 游戏数据库设计经验

    万次阅读 多人点赞 2019-07-13 18:31:18
    一、游戏模板数据库设计特点 软件行业一般数据库设计原则,”保持数据的完整性一致性“,”避免数据冗余“,”范式设计“。但游戏领域的游戏模板表设计上还需要考虑这些特点 1.1、对游戏程序只读,游戏程序只需要...

    一、游戏模板数据库设计特点

        软件行业一般数据库设计原则,”保持数据的完整性一致性“,”避免数据冗余“,”范式设计“。但游戏领域的游戏模板表设计上还需要考虑这些特点

    1.1、对游戏程序只读,游戏程序只需要考虑读取性能,不需要过多考虑修改性能

    1.2、数据结构复杂,如果过于追求“去冗余”,则会导致表结构非常复杂,策划将难以填写

    1.3、很多项目是采用Excel录入的,即使你设计的结构考虑了重用性,策划依然会冗余的填写

    1.4、大量的与程序约定的参数潜规则,程序员往往为了系统的灵活性,而抽象出一些配置,会放入模板表中,而这些对策划来说是晦涩难懂的,建议做详细备注

    1.5、程序事先读入内存,读取模板数据的方式,大部分的时候不会使用SQL的select,而常见的做法是事先读入内存,有的是实例化各种对象,有的是哈希表,有的数据数组,很少会在程序中嵌入一个SQL引擎去查询数据

    所以游戏模板库的设计,一般会在传统数据库设计原则基础上,做很多的灵活设计,这是由于游戏产品的特殊性决定的

    二、设计范式

        不管怎么说毕竟还是数据库设计,设计范式作为基本设计理念还是要重温一下
    2.1、第一范式,确保每列保持原子性,即列不可分,比如这些信息:”张三、战士、5级、绿装、50攻击力….“ 我们设计这样的结构

    玩家

    职业

    级别

    装备

    攻击力

    张三

    战士

    5

    绿色头盔

    50攻击力

        但是这样装备字段里包括了多个信息,所以我们改成这样,就可以符合第一范式了

    玩家

    职业

    级别

    装备品质

    装备

    攻击力

    张三

    战士

    5

    绿色

    头盔

    50攻击力

    2.2、第二范式,属性完全依赖于主键,比如有这样一个数据结构

    玩家

    职业

    级别

    装备品质

    装备

    攻击力

    技能

    技能图标

    张三

    战士

    5

    绿色

    头盔

    50攻击力

     普攻

    a.png

        这里面包括了玩家、装备、技能3类信息,当一个玩家有多个装备,且有多个技能的时候,这张表难以表达清楚逻辑关系。所以改成这样3张表,这样可以清楚的表达

    2.3、第三范式,属性和主键不能间接相关,比如上面的数据结构,装备的攻击力只与装备关系,技能图标只与技能关系,所以改成这样就可以了,独立一个描述装备表和技能表,然后玩家和他们之间建立关系表来表达他们直接的多对多关系。

    三、游戏模板库设计

    3.1、数组属性
        一般一个字段放一个属性值,如果要表达一个数组类的属性怎么设计呢?一般的设计是建立一个独立的表,方便各种select

         

    但是游戏库往往不需要反向查询,只需要存储一个数组数据,这时我们可以采用简单的存储方案

    这两种方案的选择,各有特点

        一般选择的话看需不需要考虑属性的扩展? 需不需要按属性分析? 需不需要对单个属性进行修改。比如一个玩家成就列表,我们可能就会放入一个字段,因为一般不会按成就查询且没有扩展属性。而玩家的任务我们会放入一个表,因为会扩展出接任务的时间、任务完成进度等属性

    案例:

        场景对象表中需要描述对象的交互范围 填1代表圆形范围后面跟半径参数,填2代表矩形范围,后面跟宽、高参数。这样我们会选择一个属性的设计。(注意 这个vector<int>,在数据库里一般是varchar类型,我这个是概念设计图)

    里面的数据大概是这样的

     

     

    3.2、单主键还是复合主键

        首先看程序的要求,有的项目出于某种原因,强制要求所有表必须单主键。比如分布式数据库的要求,或为了方便程序实例化对象。如果项目可以允许复合主键的话,可以充分利用好这类设计。

        约束的设计意义在于是否可以帮助业务帮助程序识别一条记录,比如这张表

    一般有3个设计方案

    方案1、你可以选择加一个自增长的单键来设计,但这样对读取数据没有任何好处,只是多了一个冗余的id

    方案2、如果“物品编号”是唯一标识的,你可以设置为单键,但似乎对索引没有任何好处,因为大部分情况下会按玩家编号查询,这里你还需要建立一个玩家编号的索引,还是冗余了一个索引数据,不过比上一个方案好

    方案3、如果条件允许,可以设置为玩家编号、物品编号 的复合主键,既可以解决标识问题,又可以解决索引问题

    案例:

        先讨论Dialog表,业务是“一次对话有多句话”,程序一般在读取的时候是按对话ID来一次读取的,所以这里直接设计了一个双主键来表达这个业务。

        再来看NPC功能表,业务是“一个NPC有多个业务功能,且业务功能会根据玩家的选择而进一步扩展”,为了达到这个“进一步扩展”需要设计一个用户表达树形结构的自关联,如果这个表是复合主键的话,会导致外键也需要是复合的,会产生冗余字段,另外有考虑到有可能存在多个NPC共用一套NPC功能的可能性(比如一个NPC在两个的场景中都会出现,或者两个NPC都有进多人副本的功能),所以这里设计了单主键

     

    3.3、范围结构的表达

    比如数据是这样的

    分数下限

    分数上限

    奖励

    0

    100

    5

    101

    200

    10

     

     

    一般来说有2种设计方法,

        一个是按一边维护比如按上限设计,这样在两段数据之间绝对不会有间隙,而且没有冗余数据,但是看起来需要结合上下文来理解。

        另一个是按上下限来设计,好处是程序写起来方便,读起来简单。但是这样可能存在间隙,比如100.5这种,特别是日期时间,策划不可能填精确到毫秒的时间。

    案例:

        一个技能根据,技能等级会有不同的数值变化,而这些变化是按等级段来的,比如10级内都是+10点攻击力,20级内都是加30点攻击力。

        这个表主要是为程序服务的,等级也不可能出现小数也就没有间隙问题,所以冗余了上下限的属性,另外为了程序用起来方便还加了等级段顺序属性(其实上下限的值就是顺序的,所以是冗余的)。

     

    3.4、树形结构的表达

    比如数据是这样的

    最基本的设计方案是"邻接表"

    但是为了方便程序的查询或者修改,一般会有各种冗余设计方案,这里举3个例子

    1、枚举路径,在数据中像路径一样把,每个节点的路径都写出来,优点是查询的时候只需要select like 查询就可以了,但缺点是修改节点之间的关系,可能需要重建相关的其他数据的路径,比如迁移一个子树到另一个根节点下,需要改变整个子树的路径。

    2、冗余根节点,这个设计方案就是一般是用在只按整个树查询的情形下,按根节点读取起来方便

    3、闭包表,这个设计完全是为了方便程序读取,有的程序为了在界面上展示一个树形结构会这样要求冗余数据,有时还会要求冗余一个层级的字段来表达是第几层的。但这种设计修改起来非常容易出错,且不易读。真的遇到需要这种设计,还是建议程序员自己在内存里生成这种结构,以保证数据维护的质量

    案例:

         这里举个技能行为的例子,业务是“一个行为后,接下一个行为,但QTE成功后行为是另一个”,我们也可以按最传统的结构表达出这个业务,但策划在用Excel填写的时候不直观,所以在当前行为下记录了下一个节点,而不是上一个。这个设计很像数据结构里的二叉树结构,也方便程序的读取。

        另一个案例看刚才的NPC功能表,同样为了Excel维护方便,程序读取简单,采用了记录下一个节点的方案,但这里的可能存在多个下级功能,所以用了前面说的数组属性,来避免多一张关系表

     

    3.5、对象的设计

    比如有这样一个玩家类,有两个子类机器人、VIP玩家,继承与玩家。我们如何表达这种设计

    这里列5种方案

    1、单表。就是用一张表把所有属性放进去,优点易于维护,缺点会有冗余数据

    2、独立实体表。就是完全分开两个不同的表,相同的部分,冗余到两张表里,这样缺点是如果子类多,容易产生很多类似的表,后续修改表结构起来需要同时维护。

    3、类-表映射。就是和类一样设计3张表,优点是逻辑清晰,没有冗余数据,但维护数据起来需要改多张表

    4、范型属性表。这个设计非常灵活扩展非常好,但对应的维护起来基本不用工具是很难维护的。实际工作中只用来解决未知的扩展用。

    5、半结构化属性表。这个也是牺牲了维护性,追求扩展性的设计,大文本里一般是类似json,xml之类的,一般用在非常复杂的参数扩展上

    案例:

        场景对象里有可以包括普通怪物、NPC、不可见的触发区域、城堡、宝箱等等。

        很多对象的属性是差不多的,而其中有几类对象是会自己移动的,比如巡逻怪,NPC等。所以我们的行为树和移动速度放直接放在主表里,方便共用与维护。

        而NPC又有许多特殊的属性,且会有进一步的扩展功能,所以这里建立了一个1对0..1的NPC扩展表。在表达这1对0..1关系一般有3种,比较常见的是在子表里和主表的键的数据一致,既是主键也是外键。另外就是子表里放主表的键,这样子表的键比较自由,可以用自增ID。另一种是在主表里放子表的键,数据会有冗余。这里为了方便策划维护所以采用了后者

     

    3.6、多对多关系

    最常见的多对多关系就是采用关系表了,比如这样

        这种传统设计完全复合范式设计理念,扩展性非常好,可以在关系表上扩展其他属性,同时也方便各种SQL的select查询

        而在游戏模板表里,如果只是单纯的多对多关系,业务上不需要扩展的话,更多是采用数组方案。在策划填表上优势非常明显,非常利于策划的填写,而不需要频繁的在不同excel中切换

    案例:

        场景对象在不同的状态下,对不同的阵营有不同的行为。比如我们有3个阵营友好、敌对、中立,另有3个状态普通、战斗、死亡,那就会有9种排列组合。

    对象

    阵营

    状态

    动作

    A

    友好

    普通

    动作A

    A友好敌对动作B

       我们在设计这个表的时候用了这个结构

        首先把阵营做为数组放在场景对象表上了,然后按不同状态定义不同的动作扩展属性。这个设计相当于把阵营解耦到对象表上了,这是因为业务上”非PVP玩法的时候的时候,很多对象对不同阵营是对应一个状态动作的组合“,这样避免了动作扩展属性数据冗余,填起来也方便。

    四、模板库设计的其他经验

    4.1、设计好了策划不一定会按设计的来填写

    比如有个多语言的表,设计师是想,一段多语言的文字只要内容相同的情况下是可以复用的

    而策划填的时候往往为了方便,每个都去新增一行,根本没有去看看表里是不是已经存在了可以复用。

    这类现象在填表的时候非常普遍,有的是为了方便维护,有的是怕后续会发生变化会相互影响,但也有是没有去冗余意识

    最好的情形是策划填表的时候发现冗余数据太多,找设计师改设计。

    4.2、为了避免小数使用万分比,而不使用百分比

    因为模板表程序用的时候可能会经过各种导表工具给程序用,用小数容易出现数值差异,特别是各种概率

    4.3、建议使用设计工具维护一个数据字典,而不是依赖Excel

    这里建议使用Power Designer,或 ER Studio之类的工具把表设计给存下来,方便设计师与技术、策划的交流

    五、总结

        大家通过案例可以看到,实际在做游戏数据库设计时,是需要根据业务灵活的使用各种设计方案。而不是固定的按某个固定的设计范式进行设计,甚至在表达一个业务时需要同时结合多种设计方案。
        另外就是调整,任何设计都是可能需要调整的,即使完全满足当前设计需求,也有可能随着业务变化而需要设计调整,这个是永远避免不了的。
        没有完美的设计,好的设计师是在各种约束条件下找到一个设计平衡点,来达到业务目的。

    展开全文
  • 分布式数据库-TiDB应用场景简介

    千次阅读 2020-02-27 15:53:52
    一般mysql单表数据库容量达到一定的极限,性能会急剧下降,之前工作的时候已经大佬们高喊几次了分库分表,但是最终没能实现或者落地的方案不佳。在这里一篇很好的文章指出了当前开源的分库分表的框架的不足,并介绍...

    前言:最近公司要讨论分库分表,正好一起参加了培训。一般mysql单表数据库容量达到一定的极限,性能会急剧下降,之前工作的时候已经大佬们高喊几次了分库分表,但是最终没能实现或者落地的方案不佳。在这里一篇很好的文章指出了当前开源的分库分表的框架的不足,并介绍了使用TiDb作为新的分布式数据库的各种优点传送门

    目前的常用的分库分表概述

    一种是中间件代理,例如mycat和sharding-proxy,对于应用是比较透明的,支持的语言也多;第二种是侵入式,也就是数据库直连,例如sharding-jdbc。sharding-proxy和sharding-jdbc都已经整合到sharding-Sphere里,中文文档可以点击这里

    sharding-sphere作为分库分表的实现短板。

    sharding-sphere包含三个项目:sharding-jdbc、sharding-proxy和Sharding-Sidecar。如果有兴趣大家可一查看demo,里面包含各种应用场景。我仅仅以后台人员的角度来看局限性。

    • shrdingkey粘连 例如sharding-jdbc里面需要指出分库键和分表键,如果你的业务很复杂,意味着你要建立很多shrdingkey;即使你认为这没有啥,最要命的是你增删改查都必须带上这个shrdingkey才能路由到你要去的那张表,这就好比回娘家,还真得左右一只鸡右手一只鸭,不然娘家不认你。
    • 数据冷热均衡、高可用复杂度很高 一般分表分库数据,热点数据我就需要设计非常复杂的算法,提前规划好几张库几张表;例如购物记录表,你设计2个库,每个库水平切4张表,再为这些表设计一套均衡的数据分流,但是人员表你最多一个库两张表,再为这冲业务维度设计一套数据均衡。最后,你要为这些来个主从、读写分离保证高可用,...同志,你确定你能行吗?牛逼的话希望可以给口饭吃。
    • 扩容非常困难 如果你已经提前规划好了几个库几个表,并且为每个业务表都设计好一套牛逼的算法,保证一百年性能不出问题,并且也给了我一口汤喝,百年之后老板的儿子要扩容。运维人员需要根据你的算法,再来扩容,4库变成8个库,每个库再来切一下,再来弄个高可用,再来迁移数据。运维黑人问号脸:我去你***%……%%35433454
    • sql不支持关联查询、分布式事务复杂度高、一致性差。不过这些都是分布式都面临的问题,已阅。

    TIDB原理简介

    TIDB.png

    • TiDB Server :解析SQL 请求,最后通过 PD 找到存储计算所需数据的 TiKV (键值对)然后返回。TiDB 是无状态的,也就是无脑传话机,本身不存储任何数据。
    • PD Server: TiKV存储集群的元信息;对 TiKV 集群进行调度和负载均衡;分配全局唯一且递增的事务 ID。他是集群,集群是要选举的,必须是奇数个哦! PD Server是指挥官,负责调度。
    • TiKV Server: 负责存储数据,基本单元就是Region,也就是一个K-V。多个Region组成一个TiKV 节点,多个节点组成一个GROUP。

    TiDB作为分布式数据库的优点

    • 对于现有得应用非常透明化。Tidb的原理是解析sql语句,进入自己的key-value存储单元获取数据,使得现有得应用可以平滑过渡,挂的是关系型数据库的皮,做的是NOSQL数据库的事,我们叫他不是个东...new SQL。他借用了mysql引擎,所以你直接在NAVICAT上就可以直接界面化操作啦。
    • 可以非常快捷的伸缩,实现冷热数据的均衡。例如使用sharding-jdbc,要实现热点数据的分布存储,抛开复杂的分库分表算法不说,每次扩容对于运维人员非常繁琐。但是TIDB就不存在啦,只要扩展TiDB Server 节点增加计算能力,扩展TIKV节点增加存储能力就可以。这是一场战争,号角吹响,补兵不行补兵,传话的不够加传话的,指挥官挂了选新的。男人不能说自己不xing.
    • 支持分布式事务,数据强一致性,百亿级存储。根据官网吹牛(shihua)逼(shishuo)说,金融级高可用。

    TiDB作为分布式数据库的缺点

    • 存储过程、触发器、事件、外键约束不支持,但是这个是人家谦(chenqie)虚的说法(zuobudao),分布式数据库谁还用这些鸡肋玩意儿,特别是触发器。
    • 硬件要求高,不多说的,反正就是高,你想想人家这么快肯定IO轻松不了,人家大神都说了,最好全换成SSD。

       

      image.png

    TiDB的安装

    作为后台人员,我们就是用最快捷的docker快速安装搭建TIDB,Tidb官网已经给出了非常完整的文档,这里不再详述。

     

    参看文章

     

     

    TiDB和Mysql的sql差异总结

    简介
    根据网上一些使用案例列出目前TiDB和mysql在使用上的区别和目前的遇到的常见问题及解决方案,当然具体的使用问题还需要大量的线下测试才能确认。

     

    问题类型    问题描述    原因及解决办法
    DDL    在一个 DDL 里不能对多个列或者多个索引做操作。    
    ADD/DROP INDEX/COLUMN 操作目前不支持同时创建或删除多个索引或列,

    需要拆分单独执行,官方表示 3.0 版本有计划改进。

     

    建表语句执行速度相比 MySQL 较慢    
    多台 TiDB 的时候,Owner 和接收 create table 语句的 TiDB Server 不在一台 Server 上时,

    可能比 MySQL 慢一些,每次操作耗时在 0.5s 左右,官方表示会在后续的版本中不断完善。

    大表建索引时对业务有影响    官方建议在业务低峰期操作,在 2.1 版本中已经增加了操作优先级以及并发读的控制,情况有改善。


    TiDB 对于 MySQL 用户授权 SQL 语法的兼容支持尚不完善,

    目前不支持 SHOW CREATE USER 语法,

    有时候不得不读取系统表(mysql.user)来查看一个数据库账户的基本信息

    希望后续版本优化


    DML      
    部分操作符查询优化器支持不够好,比如 or 操作符会使用 TableScan,

    改写成 union all 可避免。

    官方表示目前使用 or 操作符确实在执行计划上有可能不准确,

    已经在改进计划中,后续 3.0 版本会有优化。

     

    MySQL 事务中,可以通过影响条数,作为写入(或修改)是否成功的依据;

    而在 TiDB 中,这却是不可行的。

    原因:
    对于 MySQL,当更新某条记录时,会先获取该记录对应的行级锁(排他锁),

    获取成功则进行后续的事务操作,获取失败则阻塞等待。

    对于 TiDB,使用 Percolator 事务模型:可以理解为乐观锁实现,事务开启、

    事务中都不会加锁,而是在提交时才加锁。

    解决方案:

    在业务层,可以借助分布式锁,实现串行化处理,但是会增加开发成本。

     

    对于热数据,数据量一般不大,但是查询频度很高,比如查询 sql 为:
    SELECT * FROM t_job_record where status=0
    and execute_time<= 1546361579646
    这个在 MySQL 中很高效的查询,在 TiDB 中虽然也可从索引检索,

    但其耗时却不尽人意(百万级数据量,耗时百毫秒级)。

    原因:在 TiDB 中,底层索引结构为 LSM-Tree。当从内存级的 C0 层查询不到数据时,

    会逐层扫描硬盘中各层;且 merge 操作为异步操作,索引数据更新会存在一定的延迟,可能存在无效索引。

    由于逐层扫描和异步 merge,使得查询效率较低。

    解决方案:

    尽可能缩小过滤范围,比如结合异步 job 获取记录频率,在保证不遗漏数据的前提下,

    合理设置 execute_time 筛选区间,例如 1 小时,sql 改写为:

    SELECT * FROM t_job_record where status=0 and execute_time>1546357979646
    and execute_time<= 1546361579646

     

    select count(1) tidb查询慢    
    原因:和上面类似。

    tidb因为存储结构和查询方式的不同,tidb其实是暴力扫表。很多使用方也都反应慢,

    这个是目前的TiDB的一个常见的问题。这里给出官方的解决方案:

     

    尚不支持的sql语法:    
    增加、删除主键
    非 UTF8 字符集
    视图(即将支持)、存储过程、触发器、部分内置函数
    Event
    全文索引、空间索引
     


    PD     
    重启一个 PD 节点的时候,业务能捕捉到 PD 不可用的异常,

    会报 PD server timeout 。

    因为重启的是 Leader 节点,所以重启之前需要手动切换 Leader,然后进行重启。

    官方建议这里可以通过重启前做 Leader 迁移来减缓,

    另外后续 TiDB 也会对网络通讯相关参数进行梳理和优化。

     

    pd-ctl 命令行参数解析严格,多一个空格会提示语法错误。    官方表示低版本中可能会有这个问题,在 2.0.8 及以上版本已经改进。


    TiDB    
    现在 TiDB 的 GC 对于每个 kv-instance 是单线程的,

    当业务删除数据的量非常大时,会导致 GC 速度较慢,

    很可能 GC 的速度跟不上写入。

    目前可以通过增多 TiKV 个数来解决,长期需要靠 GC 改为多线程执行,后续版本会支持。
    TiKV     存储空间放大问题    
    该问题属于 RocksDB,RocksDB 的空间放大系数最理想的值为 1.111,

    官方建议在某些场景下通过 TiKV 开启 RocksDB 的 dynamic-level-bytes 以减少空间放大。

     

    TiKV 容易发生 Write Stall    
    原因:

    TiKV 底层有 2 个 RocksDB 作为存储。新写的数据写入 L0 层,当 RocksDB 的 L0 层数量达到一定数量,

    就会发生减速,更高则发生 Stall,用来自我保护。

    生 L0 文件过多可能的原因有 2 个:

    写入量大,Compact 完不成。
    Snapshot 一直创建不完,导致堆积的副本一下释放,rocksdb-raft 创建大量的 L0 文件
    解决:

    TiKV调优:

    减缓 Raft Log Compact 频率(增大 raft-log-gc-size-limit、raft-log-gc-count-limit)
    加快 Snapshot 速度(整体性能、包括硬件性能)
    调整max-sub-compactions 、max-background-jobs参数等
    添加 TiKV 节点后需要较长时间才能完成数据再平衡    1TB 数据大约需要 24 个小时才能完成拷贝,建议在低峰期引入

     

     

    TiDB和Mysql优缺点对比
    简单总结一下TiDB的优缺点:

    TiDB优点
    高度兼容mysql协议,迁移成本低
    高可用:相比于传统主从(M-S)复制方案,基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证,且在不丢失大多数副本的前提下,可以实现故障的自动恢复(auto-failover),无需人工介入。
    支持海量数据,可拓展性强:分布式数据库,可通过增加TiKV节点拓展,支持分裂和自动迁移,对业务基本无感知。
    和传统的分库分表,相比业务拓展性较强:传统的分库分表技术,开发和维护成本都较高,业务侵入性也较大,使用TiDB会明显降低 RD 和 DBA 的开发维护成本。
    分布式事务
    TiDB的不足
    对机器配置门槛要求较高,特别是内存和CPU的要求很高,当数据量不大时会增加机器的资源使用成本。
    TiDB对sql的支持尚不完善,对一些sql的执行性能并不理想,一些复杂sql需要重新设计,还有一些mysql的功能并不支持。
    TiDB技术较新,尚在不断优化中,因此也容易踩坑。


    综合
    综上所述,个人认为和mysql相比,

    TiDB目前更适合TB级的海量数据处理,数据量越大,使用场景和优势越明显,
    也比较适合对查询性能要求不高的数据分析场景或离线计算场景
    即时场景下查询上最适合海量数据下进行多维度的精确查询
    整体而言TiDB技术仍不能算成熟,目前还在快速的更新和迭代过程中,容易采坑,建议引入也是先从离线业务->非核心业务->核心业务的使用过程。

     


     
     

    展开全文
  • 物理设计要做什么 一.选择合适的数据库管理系统 Oracle、SqlServer、MySql及PgSQL 版权、成本考虑: 功能上的考虑: Oracle:业界内比较好的一种DBMS,性能很高,是适合大的事务操作。 操作系统上的考虑: Sql...
  • 目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。 第一范式(1NF):是指在关系模型中,对域添加的一个...
  • 数据库设计的三大范式:为了建立冗余较小、结构合理的数据库,设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库,必须...
  • 数据库系统设计概述

    千次阅读 2020-07-29 08:45:00
    数据库系统设计概述世界上只有两种开发人员,一种使用数据库系统的,一种开发数据库系统的。数据是系统最重要的信息。大部分系统都是对数据的管理。应用系统通过数据模型来构建现实世界,通过算法操作...
  • 五、数据库测试场景

    2019-09-27 14:47:17
    五、数据库测试场景 1.页面提交成功时检查数据是否正确地保存在数据库中 2.检查不接受空值的列值 3.数据应根据表设计被存储在单个或多个表中 4.索引名称应按照标准如IND_ <表名> _ < 列名> 5.表应该有...
  • 数据库设计规范-通用版

    万次阅读 2018-12-25 18:08:43
    1、不得使用数据库保留关键字,以及php/java等常用语言的保留关键字,或者可能成为关键字的单词作为完整命名。(对于一些疑似关键字的单词,可以在后面加一个下划线来避免,例如“key_”)。【附:MySQL保留关键字...
  • 一文读懂,DDD落地数据库设计实战

    千次阅读 2021-01-15 18:52:00
    作者范钢,曾任航天信息首席架构师,《大话重构》一书的作者。本文根据具体实例详细描述了DDD 落实到数据库设计的整个过程阅读本文之前建议先阅读上一篇文章《万字长文,结合电商支付业务一文搞懂...
  • 数据规模不断扩大,导致关联数据的响应速度越来越慢……数易轩致力于图数据库技术服务,为您介绍图数据库平台及其应用场景,也许能通过NoSQL数据库——图数据库解决您的烦恼。 一、图数据库平台简介 图数据库平台是...
  • 【摘要】随着互联网金融场景的不断拓展,海量的数据访问和处理造成传统的集中式数据库开始表现出性能瓶颈,分布式数据库的研究和场景使用应运而生,而数据的安全和合规也随着企业对数据使用的要求越来越高更加重视。...
  • 数据库设计:物理删除VS逻辑删除

    千次阅读 2020-05-26 10:59:28
    物理删除VS逻辑删除物理删除概念代价应用场景逻辑删除结论 物理删除 概念 1、就是用DELETE、TRUNCATE、DROP语句删除数据 2、物理删除是把数据从硬盘中删除,释放存储空间,缩小表体积,对性能提升有帮助 代价 1、...
  • 口罩预约管理系统——数据库设计(前端+PHP+MySQL)

    万次阅读 多人点赞 2020-09-14 20:55:54
    口罩预约管理系统(数据库设计)基本功能实现,如何结合前端基础、后端PHP和MySQL数据库实现呢?手把手教你设计数据库,搭建口罩预约管理系统,实现基本需求功能!
  • 数据库设计流程和依据

    千次阅读 2018-09-19 17:27:22
    1.根据数据库自身的特点把物理逻辑转化为物理设计 4.维护和优化 1.新的需求进行建表 2.索引优化 3.大表拆分 需求分析: 1.了解系统中要存储的数据 2.了解数据的存储特点 3.了解数据的生命周期 1.实体与实体...
  • 1、通过对具体的金融场景下的实验,使学生掌握数据库设计基础,并通过实践,将设计的模型转化为具体的对象; 2、通过对场景的实现,使学生能够掌握基础的SQL语言的应用; (二)实验要求 实验要求: 技术要求 1、...
  • 关系型数据库,是指采用了关系模型来组织数据的数据库,其以行和列的形式存储数据,以便于用户理解,关系型数据库这一系列的行和列被称为表,一组表组成了数据库。用户通过查询来检索数据库中的数据,而查询是一个...
  • 数据库物理设计

    万次阅读 2018-04-22 09:08:33
    物理设计就是根据所选择的关系型数据库的特点对逻辑模型进行存储结构设计。它涉及的内容包含以下4方面:1. 定义数据库、表及字段的命名规范;2. 选择合适的存储引擎;3. 为表中的字段选择合适的数据类型;4. 建立...
  • 12306的数据库设计

    万次阅读 2018-01-23 17:23:07
    经过前面的分析,已经把铁路售票系统最关键的几个业务场景进行了描述,并且阐述了其中的设计痛点,那么我们如何设计合理的系统来满足几亿人民抢票的需求呢? 西游记里每一集孙悟空师父被妖怪抓走,总能找到救兵...
  • NoSQL 数据库的使用场景

    千次阅读 2016-03-20 21:27:01
    这里就带你一览NoSQL各种类型的适用场景及一些知名公司的方案选择。 在过去几年,关系型数据库一直是数据持久化的唯一选择,数据工作者考虑的也只是在这些传统数据库中做筛选,比如SQL Server、Oracle、MySQL。...
  • 基于MySQL 数据库的审计设计方案

    千次阅读 2018-01-18 17:23:42
    场景描述 3 使用范围规则 4 角色与职责 5 审计系统环境的部署 5.1 MySQL数据库部署 5.2 Replicate 部署 5.3 半同步复制配置 5.4 备份策略  6 审计操作 6.1数据库层面审计操作
  • 数据库设计之字段冗余

    千次阅读 2020-08-26 13:36:16
    学过数据库设计的同学都知道,数据库设计有三大范式,但是在实际工作中,三大范式很难被严格的执行。本文将给大家介绍一种常见的、违反范式的数据库设计方案——字段冗余 1 经典示例 先来看一个经典的例子,在...
  • 数据存储和操作是以业务连续性为目标,包括存储数据的设计、实现和支持活动,以及在整个数据生命周期中,从计划到销毁的各种操作活动。 在互联网时代背景下,传统单一的数据库的时代已经过去,对于数据库的新需求在...
  • 点击上方「蓝字」关注我们前言随着社交、电商、金融、零售、物联网等行业的快速发展,现实社会织起了了一张庞大而复杂的关系网,传统数据库很难处理关系运算。大数据行业需要处理的数据之间的关系随数...
  • 一,前言 权限管理系统的应用者应该有三种不同性质上的使用: A、使用权限 B、分配权限 C、授权权限 本文只从《使用权限》和...做着做着就会发现这样设计太过繁琐,如果公司里面所有员工都有这样的权限呢,每...
  • 在实际业务中,经常碰见数据库和缓存中数据不一致的问题,缓存作为抵挡前端访问洪峰的工具,用的好的话可以大大减轻服务端压力,但是在一些场景下,如果没有控制好很容易造成数据库和缓存的数据不一致性,尤其是在...
  • 数据库设计

    2020-05-11 16:03:20
    数据库设计》 对于一个系统,数据库的设计是非常重要的,数据库设计决定了以后数据好不好维护。后期需求好不好展。同时也决定了系统的性能。一个坏的数据库设计一个功能点的改动可能会设计多张表的改动。一不小心...
  • 先删除缓存,再修改数据库,如果删除缓存成功了,如果修改数据库失败了,那么数据库中是旧数据,缓存中是空的,那么数据不会不一致,因为读的时候缓存没有,则读数据库中旧数据,然后更新到缓存中 2、比较复杂的数据...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 133,019
精华内容 53,207
关键字:

数据库设计场景描述