Open phoenixlzx opened 4 years ago
目前的数据库工具类实现目前讨论的结构理论上可以,但是可能会出现潜在的性能问题/数据冗余存储的问题
用uuid作为索引性能会低于直接使用数字id->player
以co存储方式为例,存储玩家信息使用的是一个数字id,int,这个int对应了一个uuid和一个玩家名,大量重复的uuid不需要被存储 索引查找时也不需要匹配字符串而是匹配数字 我想法是利用这个特性来减小交易记录的存储量与signshop、market的存储量
现有架构一个item表解决所有的signshop、market、Lottle的对应关系还可能带来一个耦合性高的问题 日后想扩展(比如加个功能)可能会遇到麻烦 数据表结构定下之后想改基本只能再次重构。。。
如果想解决的话要用到inner操作,目前NC对数据库操作做不到,需要造个轮子解决inner操作的问题。 可以暂时使用多次查询方式临时解决问题之后再从内部把操作重构(也就是可以先糊功能再解决性能问题)
以signshop为例,设计的存储架构如下
位置和owner信息存成这样
signshop_meta
|id|owner|world_x|……|
实际内部的道具存成这样
signshop_items
|id|signshop_id|item_id|
|int|int|int|
使用signshop_id和item_id分别先筛出需要的记录再把具体值套上去 这样做索引大概会快非常多,而且省空间
item存成这样
item
|id|nbt|unit_price|……|
|int|int|int|……|
nbt
|id|nbt|
|int|TEXT|
交易记录也可查询到对应的item的实时状态
坏处也有。。就是交易记录不好和主要功能分开了,可以进行定期挪出非活跃物品至另一数据表内永久保存,这个功能可以后期加
数据库主要问题有两个。一个是不同DBMS(e.g. SQLite vs MySQL)有各自的SQL方言(主要是数据类型和autoincrement (对我就是在说你sqlite)),导致NC实现的复杂度增加,建议固定一个数据库。二是没有DBA,导致每次更新/重构都引入schema上的变动就GG。另外不建议把NC的数据库组件扩展成支持inner,要么直接SQL,要么抛弃NC的数据库换成一个有维护的功能全的。自己写太容易出错了。更别提多线程+事务混着用的情况了。
功能
广告功能并没有人用所以不要了。
配置
config.yml
automation.yml
- 自动化用配置,暂不开发命令
所有命令默认权限都是 op,需要手动赋予玩家组。
/h [m\|market]
heh.business.market
/h [m\|market] <unit price>
heh.business.market
/h shop [sell\|buy] [unit price]
heh.business.signshop
/h chest req
heh.business.chest.req
/h chest lotto
heh.business.chest.lotto
/h auc [base] [step] <reserve>
heh.business.auction
/h req [material\|HAND] [unit price] [amount] <additional params...>
heh.business.requisition
/h bid <price>
heh.business.bid
price
参数则出最低加价/h sell <amount>
heh.business.sell
/h sellto [player] [unit price]
heh.business.sellto
/h pay [invoice id]
heh.business.pay
/h cancel [invoice id]
heh.business.cancel
/h frame
heh.business.frame
/h storage
heh.storage
/h search <params...>
heh.search
/heh balance [view\|pay\|take] <params...>
heh.admin.balance
/heh remove [item\|shop\|player\|storage] [item id\|player name\|sign]
heh.admin.remove
/heh run auc\|req <params...>
heh.admin.run