游戏数据库设计
方案一：使用自己的加密算法
第一种加密方案是修改RGSS102J.dll中的解密算法，然后自己把素材打包成RGSSAD格式。
此方案要求使用者对程序设计以及二进制文件的修改有一定的基础。
由于我现在还没有试过外挂dll这种技术，所以这里介绍一个相对简单的方法——修改MagicKey的初始值。RMXP是使用0xDEADCAFE作为MagicKey的初始值，那么我们把RGSS102J.dll中的DEADCAFE修改掉，然后自己打包就可以防范那些一般的解包工具。
当然，如果你觉得有必要的话，还可以给这个修改过的dll文件加一个强壳，然后随游戏发布。
虽然安全系数不高，但足以应对全自动的提取工具。我写了一个程序来自动修改MagicKey，并打包资源文件，我给它起名叫"纸老虎"。下载网页 http://www.uushare.com/user/lingchen/file/1333250。
难度指数：★★
安全指数：★☆
·方案二：混淆文件名
第二种加密思路是混淆文件名。在Windows操作系统下，有 \/:*?"<>| 这9个字符是不能用作文件名的。除去\/表示文件目录，我们还有7个特殊字符可用。如果在原有文件名中加入这几个本来不能用的字符，那么解包程序就会因为不能正常创建文件而提取失败。
注：此方法需要自己打包资源文件，以及修改rxdata文件，工作量比较大。
混淆不能绝对保证自己的游戏不被盗用，它的主要目的是打击盗用者的信心，让他在还没有导出全部素材的时候就已经垂头丧气，精疲力尽了。
难度指数：★★★★
安全指数：★★☆
Ⅱ Unity的本地数据库和服务器数据库分别用什么好
sqlite也可以支持服务器存储的；
支持跨平台，像很对安卓的应用可以找到它的影子；
sqlite是一个单文件的数据库文件系统，属轻型数据库，理论支持百万级数据量；性能方面不能但看数据库本身，还要看你的设计，设计的不好10万级有点悬；
另外，网络多应用共享时，容易造成死锁；
个人建议啊，要是做网络游戏，不太建议用sqlite做服务器数据库，到是可以做客户端内嵌的小型数据库。
Ⅲ 如何建立游戏数据库
说的太简略了，需求不明说简单点，大概的思路就是你的数据库建立一个游戏数据表，表里面有游戏名称，以及之后你想搜索的一些字段，比如游戏类型，游戏规模等等在前台的复选框跟这些字段对应，在搜索时匹配就可以了
Ⅳ 数据库设计步骤与系统开发阶段的关系
一般一个面向对象的系统，开发阶段：需求确认——概要设计——详细设计——编码——单元测试——集成测试——系统测试——维护 。数据库设计步骤：需求分析，概念设计，逻辑设计，物理设计，数据库实施与维护。我们知道，系统开发的软件是让人使用的，为使用者提供一种可视化可操作的界面，而使用者使用这个系统是为了查询或者操作数据，一个没有数据库的系统是死系统，没有意义。 数据库设计的第一个阶段需求分析是在系统开发之前考虑的，也考虑用户需要知道什么数据，需要操作那些数据，第二阶段概念设计到第四阶段都是围绕第一阶段设计考虑的。 与系统开发阶段相关的是第一阶段需求分析和最后的实施维护，数据库设计和系统开发相辅相成，系统开发的需求是为了了解用户能看到（前台）哪些界面，拥有哪些操作。而界面中显示的信息，操作的数据结果是数据库（后台）设计的。 打个比方，如一个游戏系统，比如《热血传奇》，双击游戏图标跳出界面，里面有区选择框，这个界面有多大，有多少按钮，这是系统开发需求的设计，而界面里显示哪些新闻公告，显示几个区，是数据库设计的。游戏版本升级，新功能是系统开发编码实现，新功能显示的新数据是数据库实现。游戏测试如果有BUG，数据错误是数据库出错，按钮无效则是前台功能无效。修复BUG，修复数据是数据库维护，修复按钮功能是单元维护。 整个游戏测试就是系统测试。