> 火影忍者交易

游戏账号数据库设计

作者: 租号官方平台 2021-04-17 14:31:20 火影忍者交易

游戏的程序员会不会偷偷改自己账号的数据?

说实话作为开发,开发游戏已经摸透了每一行代码,自己去玩的时候总在想着,卧槽,这个部分是我写的,真牛逼,其实很简单的。那么多测试账号,随便在测试服务器改改值,看看牛逼的特效,但是要我老老实实玩呀,不可能,对于开发来说,没啥好玩的,下班玩的时候总觉得在工作,也不会一直玩下去,没意思呀,对于开发来说,完全没有吸引力,哈哈!

支撑日活百万用户的高并发系统,应该如何设计其数据库架构? ?

以mysql为列:

1:支撑高并发系统,一定会涉及事务,所以数据库引擎必选innodb,innodb支持事务,事务级别根据业务而定,如果业务数据一致性要求很高,事务就开启序列化级别,这样就完全隔离事务,但是会导致锁资源竞争加剧。mysql的性能有一定的降低。

2:读写分离,数据库分成主库和从库,主库负责写数据,丛库负责读数据。注意主从数据库数据一致性问题。

3:冷热数据分离,美团,饿了么部分设计采用冷热数据分离,拿订单来说,已送达订单,主要的业务场景就是查询,越往前的数据查询的概率就越低。这就是冷数据。正在交易的订单就是热数据,需要时时查询和更新。对于冷数据,可以放到redis缓存。这样会增加查询效率。

4:数据表设计,充分利用索引查询。业务sql避免返回无用的行和列,禁止使用select *查询,查询的时候加limit,尽可能返回满足要求的行。对于复杂的sql,考虑拆分sql,拆分sql有一个好处,重复查询的sql,第二次查询会放到mysql的缓冲区,避免重复操作磁盘,提高访问的性能。

5:分库分表。比如业务数据按月分等。一定程度缓解增删改查的压力。

希望对你有一定的帮助。谢谢。

数据库设计用户表?

有建议,除表和表字段外,其它功能块在命名时均要加英文缩写前缀。但就个人意见,除视图外,其它部分加不加前缀都不重要,视图加前缀是为了在执行查询时和表区分开,而存储过程、函数、约束等,我们一眼即可看出它是什么,更何况在可视化管理工具中,这些功能块本来就是各自独立展示的。

关于表的命名,TB这种前缀是毫无意义的,本来就是一个表,为什么还要说明?这也是我上面不建议在其它功能块中加前缀的原因。如果表格数量较少,后期项目扩展升级的可能性不大,也没有必要加其它前缀。但有时规模相对庞大、业务逻辑相对复杂的项目,表格数量多到一定程度,在可视化管理工具中查阅浏览不太方便,这时,根据业务或功能对表格进行分类,加前缀也就有必要了。个人感觉是50张表内的数据库,加前缀意义不大,超过100张,则很有必要加前缀。而且我们要求,为了不给后期代码生成造成非必要麻烦,如果要给表加前缀,则所有表均要有前缀,不要出现有些表有、有些没有的情况。

表前缀主要是为了区分不同功能的表,而非解释表的功能,表的功能由表名来解释。前面要求表名的长度要控制在30个字符以内,在此前提下,为了尽可能不影响表的命名,表前缀应该越短越好。我们建议表前缀控制在两个以内。具体表前缀添加规则建议如下,括号内的单个大写字母表示要添加的前缀。这里以Oracle数据库为例说明:

a. 系统表(S_):System,系统配置相关的基本信息表。系统用户表(S_USER)、系统角色表(S_ROLE)、系统菜单(S_LINK_MENU)、操作日志(S_OPERATION_LOG)、登录日志(S_LOGIN_LOG)、系统字典(S_DICTIONARY)、系统字典类型(S_DICTIONARY_TYPE)等。

b. 字典表(D_):Dictionary,非系统字典外的字典表。在“设计规范”——“相关注释”——“字典字段”中提到过字典表的定义,除了数据库中的通用字典表,还有一些常见表,比如地区表(D_REGION)、ICD编码(D_ICD)等,也是一种字典表,这里的D_前缀即加在这类字典表名前面。

c. 中间表(R_):Relationship,多对多关系中间表。具体命名方式建议为:R_主表名_从表名,在多对多关系中其实不分主从表,这里我们规定核心表为主表,另外一个为从表。比如用户角色关系中,用户表(S_USER)为主、角色(S_ROLE)表为从,那中间表就命名为R_USER_ROLE。当中间表名超长时,则根据实际情况缩写主从表名,建议优先缩写从表表名。

d. 业务表(B_):Business,核心业务涉及的基本信息表。这里的业务是非系统配置业务相关的,比如登录、注册、权限这些业务涉及的表都是和系统配置相关的,前缀应该是S_,而非B_。比如在线商城的项目中订单业务涉及的表即是核心业务表,会诊系统中会诊单业务涉及的表即是核心业务表,如果项目庞大,涉及业务较多,可以在B后面继续加单字母区分不同的业务,BA_、BB_、BC_……,没必要非得和某个英文对应,只是个代号,和项目组的人员说明即可。

表名前缀的说明如上,已经足够明确,除此外还应该避免无谓的表格后缀。比如存储客户信息的表直接命名为Guest而非GuestInfo,存储航班信息的表直接命名为Flight而非FlightList。还有命名表时,一律使用单数形式。例如,使用 Employee,而不是 Employees,总之,表的命名应该简单明了。

如何设计一个客户信息数据库?

数据库是用于存储大量数据的区城,它通常包括一个或多个表。数据库应用成为当今计算机应用的主要领域之一。VB提供了功能强大的数据库管理功能,能够方便、灵活地完成数据库应用中涉及的诸如建立数据库、查询和更新等各种基本操作。本章讨论数据库的基本概念、VB中提供的Data控件、DBGrid控件、ADO Data控件的使用方法和SQL语言。

关系数据库以表的形式(即关系)组织数据。关系数据库以关系的数学理论为基础。在关系数据库中,用户可以不必关心数据的存储结构,同时,关系数据库的查询可用高级语言来描述,这大大提高了查询效率。

VB本身使用的数据库是Access数据库,可以在VB中直接创建,库文件的扩展名为.MDB。

下面讨论关系数据库的基本术语。

1. 表

表用于存储数据,它以行列方式组织,可以使用SQL从中获取、修改和删除数据。表是关系数据库的基本元素。表在我们生活中随处可见,如职工表、学生表和统计表等。表具有直观、方便和简单的特点。

表是一个二维结构,行和列的顺序并不影响表的内容。

2. 记录

记录是指表中的一行,在一般情况下,记录和行的意思是相同的。在表10.1中,每个学生所占据的一行是一个记录,描述了一个学生的情况。

3. 字段

字段是表中的一列,在一般情况下,字段和列所指的内容是相同的。在表10.1中,如“学号”一列就是一个字段。

4. 关系

关系是一个从数学中来的概念,在关系代数中,关系是指二维表,表既可以用来表示数据,也可以用来表示数据之间的联系。

在数据库中,关系是建立在两个表之间的链接,以表的形式表示其间的链接,使数据的处理和表达有更大的灵活性。有3种关系,即一对一关系、一对多关系和多对多关系。

5. 索引

索引是建立在表上的单独的物理数据库结构,基于索引的查询使数据获取更为快捷。索引是表中的一个或多个字段,索引可以是唯一的,也可以是不唯一的,主要是看这些字段是否允许重复。主索引是表中的一列和多列的组合,作为表中记录的唯一标识。外部索引是相关联的表的一列或多列的组合,通过这种方式来建立多个表之间的联系。

6. 视图

视图是一个与真实表相同的虚拟表,用于限制用户可以看到和修改的数据量,从而简化数据的表达。

7. 存储过程

存储过程是一个编译过的SQL程序。在该过程中可以嵌入条件逻辑、传递参数、定义变量和执行其他编程任务

在VB中,可用的数据访问接口有3种:ActiveX数据对象(ADO)、远程数据对象(RDO)和数据访问对象(DAO)。数据访问接口是一个对象模型,它代表了访问数据的各个方面。可以在任何应用程序中通过编程控制连接、语句生成器和供使用的返回数据。

为什么在VB中有3种数据访问接口呢?因为数据访问技术总是不断进步,而这3种接口的每一种都分别代表了该技术的不同发展阶段。最新的是ADO,它比RDO和DAO更加简单,而且是更加灵活的对象模型。对于新工程,应该使用ADO作为数据访问接口。

ADO控件是VB 6.0中文版提供的一个ActiveX控件,与旧版的Data控件相似。

看过游戏账号数据库设计还喜欢

网站分类
游戏账号数据库设计标签列表