我想创建一个需要自有数据表的插件。因此，拥有迁移（migration）和模型（model）生成器是个好主意，因为手动从主应用目录复制它们不仅容易出错，而且非常不便。所以我开始开发自己的生成器。我先从迁移生成器入手：
接下来我可以为模型和控制器做同样的事情。但现在我开始阅读 https://guides.rubyonrails.org/engines.html，这让我觉得所有这些工作可能是在重复劳动。为什么 Discourse 插件生成器 与 Rails 插件生成器如此不同？
Rails 插件生成器会创建一个专用于该插件的 bin/rails 文件，从而启用该插件特有的迁移和模型生成器。如果能拥有类似的功能就好了。我也尝试过实现类似的东西，但无法使其正常工作，因此我另辟蹊径，直接开始创建这些特殊的生成器。如果我能更清楚地理解 Rails 插件与 Discourse 插件在实现方式上的差异，或许就能选择另一条路径，从而节省时间。也许有人能对此进行补充说明。为什么 Discourse 插件和 Rails 插件是不同的概念，它们为何不能相互构建？
Rails 插件与 Discourse 插件之所以不同，原因有很多。Discourse 插件需要遵循特定的文件夹结构，它们可以扩展或覆盖 Discourse 核心的 Ember 代码等。我认为 Discourse 插件的 Rails 部分会更接近通用的 Rails 插件，但它们并非完全相同。
此外，只有在确实需要时才应创建新表。Discourse 已经拥有约 150 个表，通常你只需使用其中一个或几个表就能完成任务。
不过，展望未来，我个人非常希望看到这种情况发生。这意味着人们正在构建庞大且更具吸引力的插件，并在 Discourse 能实现的功能上展现出更多的创造力。
我需要这些表。即使是基本功能也需要表。我认为目前没有清晰文档化的方法来实现这一点，这真的很令人烦恼。例如，poll 插件使用了它自己的表，但我找不到生成这些表的生成器。discourse/plugins/poll at main · discourse/discourse · GitHub
文档化的另一个好处是，可以为表和迁移的命名空间建立规范。（我在论坛上看到过一些非常 hacky 的解决方案，用于向插件添加迁移）
太好了！那么该选择哪种方式？是更接近 Rails 插件生成器，在插件文件夹中包含自己的 bin/rails，还是为所有生成器（迁移、模型、控制器）提供自己的版本？
你需要在此阅读插件开发指南主题。对于大多数插件，你可以使用现有的表（例如帖子自定义字段）。有时你需要更多的表，但建议先从难度较低的内容入手。
我阅读了初学者插件指南以及这篇。还有其他需要看的吗？我还查看了一些插件的代码。我只知道需要创建表。而且其他一些插件也使用它们自己的表。为什么大家如此执着于不创建新表？创建新表有什么重大成本吗？尤其是如果它们以插件名称开头进行命名空间划分，我真的看不出有什么弊端。
https://meta.discourse.org/t/creating-routes-in-discourse-and-showing-data/48827/19?u=fzngagan
就是这两个链接。在就任何开发相关话题发表评论之前，我强烈建议你先动手实践一下这些内容。这并不是说你永远不需要自定义表，但这些内容无论如何都是必须掌握的。
这个东西只是一个基本的键值存储。我无法在那里存储表之间的关系。我喜欢 SQL，而且我创建插件时需要使用它。
我能理解这个问题适用于那些希望创建“非技术人员”也能安装和卸载的插件的人。我不是这类人。所以，如果我们能回到主题，我将不胜感激。
如果目的是创建一个仅供你自己使用的工具，依我之见，编写浏览器扩展或桌面应用程序可能比编写插件更好。是否有任何原因必须将其做成插件？
这里有一个相关的有趣讨论：