前言： JE吧github曲谱库2.0版本即将发布，为了更好推动JE吧的发展，我们也将正式更名为自由神社曲谱库！同时我们的安卓客户端也将开始使用自由神社这个名字。今后，我们将全力配合自由神社开发组，共同为JE吧做贡献！
一、 1.0版本本身的设计缺陷
-
1.0版本中为了美观使用了badge，后来成为了上传模板的主要门槛。另外，badge中的文字信息无法搜索到，影响了基本的搜索功能，导致许多用户搜不到想要的谱子，爬虫无法正确抓取歌曲信息。2.0版本中，我们决定将数据和样式分离，仅仅将github曲库定位为一个数据库，去除badge样式，另外通过网页和安卓端添加样式。这样不仅改善了搜索，降低了上传谱子的门槛，同时使得利用爬虫备份谱子数据成为可能。
1.0版本
2.0版本
app更改样式
- 1.0版本将一个作品定为一个issue，用issue里的comment来储存该作品的谱子，随着谱子数量增加，逐渐暴露出来一些问题。1. 如果同一作品下的谱子太多，那么用户搜索到该作品后还需要往下滚动很久才能找到需要的谱子，大大降低了用户体验。2. 以作品为基本单位的设计，先入为主地将谱子之间的其他方面联系削弱了。在2.0版本中，我们将每一首谱子单独作为一个issue，通过在comment中加入各种关键字来实现对谱子的分类搜索。比如用户现在能够按照作品名，扒谱人，xx年xx月新番，编曲等等进行搜索。极大的提高了搜索的自由度。
按作品搜索
按扒谱人搜索
按新番日期搜索
按编曲人搜索
二、 对于将网站的【曲谱数据库】与【用户信息数据库】分离的一些思考
对于一个网站来说将这两种数据存在一个数据库下好还是两个不同的数据库更好？
目前主流方案都是将用户数据和其他数据分开存放，保证用户敏感信息的安全。
三、 在神社2.0版本中使用GITHUB曲库2.0版本的可行性分析
-
目前神社2.0的api文档中关于谱子部分的需求github曲库都能完美满足，甚至可以说有过之而无不及。支持拖拽上传图片，自带完善的搜索功能。经过半年实践，曲库已经积累一定的经验。神社要自己建立同等功能的谱子数据库面临几个问题：1. 负责数据库的同学太忙没有时间；2. 实现曲库和谱子搜索功能需要花费一定时间；3. 谱子需要重复搬运。
神社api文档
- 通过调用github曲库的api能否实现收藏上传等功能？经过这段时间的学习和向相关程序猿咨询，我论证如下解决方案的可行性。通过用户id和谱子issue序号的唯一对应来实现收藏功能。用户将谱子上传至服务器，然后服务器用固定的github账号实现谱子的上传，上传的谱子默认为closed状态（用户不可见），待管理员审核后调整为open（用户可见）
四、 在神社2.0版本中使用GITHUB曲库2.0版本的优势
-
目前曲谱库中已经有300多个谱子，现已有10余人专业搬运团队
能够直接使用github强大的elastic search搜索功能，理论上支持各种分类，多字段搜索，避免重复造轮子
-
能够通过定期爬取数据进行备份
爬虫抓取
-
有配套的安卓客户端以及大佬的支持，稍加修改即可使用
五、 如何在神社2.0版本中使用GITHUB曲库2.0版本？
- 曲谱数据的存储以及搜索通过调用github的api实现
- 用户数据库存储在神社服务器上，基于OAuth 2.0实现第三方登录
-
通过用户id和谱子issue序号的唯一对应来实现收藏功能
- 用户将谱子上传至神社服务器，然后服务器用固定的github账号实现谱子的上传。上传的谱子默认为closed状态（用户不可见），待管理员审核后调整为open（用户可见）
- 求谱功能通过填写表单提交至后台，在指定页面以列表形式展现
写在最后：一月霸权 人类圣经 世界瑰宝 京紫八万八
