数据库兼容 NexusPHP 讨论

[PlexPt]

1. 全新开发，优先考虑功能。后续推出迁移程序或脚本
2. 沿用数据库结构，尽量保持兼容性。

[120318]

我认为这要看rocket-pt的定位

• 如果rocket-pt定位是提升 NP 的性能，那么，应该尽量沿用 NP 的数据库结构，只在需要优化的地方做处理，这样迁移脚本的工作量会很小，且能最大化保留 NP 的数据。（顺带一说的话，如果只是考虑性能，只要重写 Tracker 就好了，不需要重写 Web）
• 如果rocket-pt定位是优化 NP 丑陋的 UI，那么也应该尽量沿用 NP 的数据结构，可以少很多思考设计，只需要专注前端框架和前后端分离即可。
• 如果 rocket-pt定位是新时代的 Web 框架 & Tracker，想要使用现代化技术重新设计 Web 功能，希望做出更易用，架构更合理的站点，那就没必要沿用了。因为 NP 的功能实际上非常简陋，且数据库的设计一定有一些不合理的地方。重新设计完全可以跳出局限，甩掉历史包袱。至于数据迁移，虽然会有一些遗漏，但是由于 NP 的简单性，这也不会是问题。

[PlexPt]

目前来说倾向于3

[Rhilip]

为什么要兼容nphp这个设计那么差的表结构？

1. 没有外键关联（虽然现在有些指导不建议使用，而是在应用层保证。
2. 大量可以使用boolean（即tinyint (1) ）的地方使用了enum(yes,no)。以及从准确性的角度，任何使用datetime的地方都应该用timestamp。
3. torrents表设计稀烂。nfo这种原始数据而且大多数种子都没有，直接一个has_nfo的boolean列就可以了，原始内容存库或者硬盘都可以。cache_stamp这种和外置影片信息有关的变成和种子相关联。visible和banned在结果上没有太多区别，但分成两个列。 leechers和seeders这两列属于经常变动的列，导致torrents经常更新，根本没必要，直接扔缓存中就行了的。ori_descr存了东西但是根本没用。
4. adminpanel，modpanel，staffpanel这种可以用路由或者if判断来解决的开个表
5. allowedemails，bannedemails，torrents_state，searchbox这种一个表只有一行，而且都是和配置项有关的，扔数据库干嘛？直接改config就好了，还减少数据库请求开销。（searchbox这个表设计是我最不能理解的，本质是为了一个站点有多套搜索cat的方式，但实际大家定好了就不会再改）
6. suggest这种推荐表，regimages这种临时表完全可以用redis改造，不需要扔数据库。
7. poll表一堆options，谁设计投票这么设计？
8. downloadspeed这种和注册选项有关的数据表根本没必要，没人关注这些信息，也可以有更好的解决方法。
9. faq这种处理i18n的表也可以有更好的解决方法。
10. files表：见 https://github.com/xiaomlove/nexusphp/issues/27

---

总而言之，nphp的设计都落后时代了，没必要搞兼容。 unit3d也是另开一个迁移脚本的仓库。 而且就国内的开源环境，这项迁移兼容完全可以作为付费支持项。

[PlexPt]

有兴趣参与前端开发吗大佬

---原始邮件--- 发件人: @.> 发送时间: 2023年2月8日(周三) 凌晨1:14 收件人: @.>; 抄送: @.@.>; 主题: Re: [PlexPt/rocket-pt] 数据库兼容 NexusPHP 讨论 (Issue #5)

为什么要兼容nphp这个设计那么差的表结构？

没有外键关联（虽然现在有些指导不建议使用，而是在应用层保证。

大量可以使用boolean（即tinyint (1) ）的地方使用了enum(yes,no)。

torrents表设计稀烂。nfo这种原始数据而且大多数种子都没有，直接一个has_nfo的boolean列就可以了，原始内容存库或者硬盘都可以。cache_stamp这种和外置影片信息有关的变成和种子相关联。visible和banned在结果上没有太多区别，但分成两个列。 leechers和seeders这两列属于经常变动的列，导致torrents经常更新，根本没必要，直接扔缓存中就行了的。ori_descr存了东西但是根本没用。

adminpanel，modpanel，staffpanel这种可以用路由或者if判断来解决的开个表 5.allowedemails，bannedemails，torrents_state，searchbox这种一个表只有一行，而且都是和配置项有关的，扔数据库干嘛？直接改config就好了，还减少数据库请求开销。（searchbox这个表设计是我最不能理解的，本质是为了一个站点有多套搜索cat的方式，但实际大家定好了就不会再改）

suggest这种推荐表，regimages这种临时表完全可以用redis改造，不需要扔数据库。

poll表一堆options，谁设计投票这么设计？

downloadspeed这种和注册选项有关的数据表根本没必要，没人关注这些信息，也可以有更好的解决方法。

faq这种处理i18n的表也可以有更好的解决方法。

总而言之，nphp的设计都落后时代了，没必要搞兼容。 unit3d也是另开一个迁移脚本的仓库。 而且就国内的开源环境，这项迁移兼容完全可以作为付费支持项。

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[PlexPt]

为什么要兼容nphp这个设计那么差的表结构？

1. 没有外键关联（虽然现在有些指导不建议使用，而是在应用层保证。
2. 大量可以使用boolean（即tinyint (1) ）的地方使用了enum(yes,no)。
3. torrents表设计稀烂。nfo这种原始数据而且大多数种子都没有，直接一个has_nfo的boolean列就可以了，原始内容存库或者硬盘都可以。cache_stamp这种和外置影片信息有关的变成和种子相关联。visible和banned在结果上没有太多区别，但分成两个列。 leechers和seeders这两列属于经常变动的列，导致torrents经常更新，根本没必要，直接扔缓存中就行了的。ori_descr存了东西但是根本没用。
4. adminpanel，modpanel，staffpanel这种可以用路由或者if判断来解决的开个表 5.allowedemails，bannedemails，torrents_state，searchbox这种一个表只有一行，而且都是和配置项有关的，扔数据库干嘛？直接改config就好了，还减少数据库请求开销。（searchbox这个表设计是我最不能理解的，本质是为了一个站点有多套搜索cat的方式，但实际大家定好了就不会再改）
5. suggest这种推荐表，regimages这种临时表完全可以用redis改造，不需要扔数据库。
6. poll表一堆options，谁设计投票这么设计？
7. downloadspeed这种和注册选项有关的数据表根本没必要，没人关注这些信息，也可以有更好的解决方法。
8. faq这种处理i18n的表也可以有更好的解决方法。

---

总而言之，nphp的设计都落后时代了，没必要搞兼容。 unit3d也是另开一个迁移脚本的仓库。 而且就国内的开源环境，这项迁移兼容完全可以作为付费支持项。

说得很好，有部分是我之前也没有考虑到的