[技术交流] 如何建好数据表

Qzzz

填表而不用公式，有时候是策划为了便于修改调试。游戏平衡性、节奏之类的测试没问题以后，程序再用公式写死是可以的。

当项目改动频繁的时候，用TGA和用ID一样会有匹配问题。比如今天这怪物叫史莱姆，明天老大说要改名成哥布林，一直用dropbyslime这不就容易产生误解了么。

wstc23

对第一点还是比较认同的

不太赞同Tag机制，还是分类手动填表和链接比较直观和方便
楼主意味强调简化表单，其实还不如直接操作数据库，但其实我觉得表这个东西只要是当事人自己写的就不会乱

小石子

SUN_OGRE 发表于 2013-5-31 12:34
这样的想法我是赞同的，每个人确实应该发挥最大的能量。但是当项目中的不同角色有冲突的时候，我更偏向于 ...

很不赞同这点。表是程序给导入数据库，程序引用不假；但要注意，填表的是策划。规则定好后，后续程序很多时候都不需要关注既定的表，但填表策划需要总去维护。。。程序按所谓的稳定，方便，快捷定了。表哥填表呢？谁管表哥的感受？

rikkikk

100多个项目
100多列的表


真是屌爆了，做了几年项目还真是没遇到过这么庞大的表。

linseryer

首先向前面的各位前辈致敬，看完对话受益匪浅。然后有一个疑问虽然可能会打乱大家的讨论主题，但是我还是希望能得到指点：
之前大家讨论了表的繁杂性，提到了，经验表，技能表中的列等例子。为何，我们不能把这两个部分，封装成两个单独的配置文件，这样表结构就可以简略，玩家角色属性表经验等级部分只需要一列经验值，技能表只需要定义关联的角色ID，激活技能列，冷却间隔或者使用次数等需要累积性数值就足够。至于经验是否足够升级，查询经验配置表即可返回数值，技能是否可以对建筑物使用，在技能属性文件中定义好即可，这样后期调整，维护时，只需要修改相应的配置文件，同时数据库中的表也可以得到一定精简
把大部分的定义型内容制作成单独的配置文件供地图服务器加载，比如技能配置文件，属性计算定义文件，物品道具属性定义文件等。尤其是最为庞杂的物品道具表，也可以得到很多简化，里面定义好归属角色ID，物品总编号ID，物品ID，属性变化值等少量定义型表头。任务指向时，我们可以给玩家角色预留一定数量的MARK位，这个数量可以很大，把MARK分配给各个任务，每个任务的各个阶段，只需要检查角色相应MARK位即可，又可以节约任务表很多内容，NPC只要定义关联上哪些任务或者剧情的ID，类型，属性，等等。
个人认为，事情总有变通的方法，策划虽然定义了表头，但是我想不一定每一个策划都对系统运行优化上很在行，功能我们要，内容多样性我们要，存储数据详细性我们要，但是整体运行优化我们也要吧，与其想破头合并，那将定义型的内容全部去掉，换成配置型文件加载不是更好？虽然达到的目的是一样的，但是后期维护时，有变化的内容只需要修改实际的定义型文件，这些文件可以提供每一个阶段，每一个修改版本的存档，一旦发生了问题具备更高的可追溯性。让后期维护时，仅仅是修改的内容就可以尽可能的不去碰数据库。尤其是一个运行中的游戏，一旦需要做某些修改去操作数据库时，就算过程是没问题的，但是总怕出问题吧。并且无论硬件，网络发展到什么程度，减少服务器查询请求，优化服务端运行效率应该也属于策划的考虑内容之一。

damage

看了猴的几篇文章真的忍不住要过来赞一下：姑且不论提出的方法是好是坏，看了总是让人感觉有些收获的~

1、我很认同应该是策划去建立表结构的观点，因为个人认为策划应该对游戏整体规划和未来扩展更了解或有想法一点，所以让策划建立表结构可以避免很多后期麻烦，而且有助于策划反思自己的想法是否足够通畅

2、权重和%各有各的好处，其他大家都很了解了，不过漏了一个地方：权重在加入一个新的项后会改变整体掉率。根据项目需要和影响程度大小选择合适的方法会收到更好的效果

huori

表格的重点，不是效率，而是易于理解。

独孤逍遥

学习，学习。

Mr_I

关于TAG不TAG的，不知道我是不是理解有误。
不过关于ID还是命名我是这么操作的：
凡是可以用命名的地方，我在表里都用命名，但单独维护一个INDEX表。
需要从表格输出配置的时候，自动从命名转化为INDEX指向的数字。

需要重命名的时候，只要表格和INDEX都重命名一下就好。
最方便的是，如果要改对应值，只需要改INDEX，表都不用动。

comtecrule

看了好几篇被标题吸引进来的文章，发现大部分都是猴子前辈发的，写的都非常好。个人觉得这样才是一个好的氛围。设计人员之间的交流，为了使方法行之有效，为了开发更好的游戏，而不是如何去圈钱。诚如所言，有时候也会感觉很悲观，算了还是不吐槽了。希望能和猴子前辈多学习，多交流。