数据库管理（SQLite）和表生成
我正在构建一个 RSS 阅读器，它将提取的文章存储在数据库中（特别是 SQLite，但我认为这并不重要）。
不管怎样，当我最初设计和编码它时，想法是为用户订阅的每个提要创建一个新表，并拥有一个大的元表。在阅读了有关数据库管理的更多内容后，我发现另一种处理此问题的方法是有两个表，即元表和一个用于 rss 提要中的每个项目的表，并在该表中有一列，其中包含饲料是从哪里来的。
那么，是否有任何主要原因让我应该将正在使用的模型切换为大型项目表，而不是为用户订阅的每个提要创建一个模型？
I was building an RSS reader, which stores the articles pulled in an database (SQLite in particular, but I don't think that matters).
Anyway, when I originally designed and coded it, the idea was to create a new table for every feed the user is subscribed to, and to have a big meta table. After reading a bit more about database management, I found another way to handle this was to have two tables, the meta table, and a table for every item in the rss feed, and in that table, have a column with the id of the feed it came from.
So, is there any major reason why I should switch the model that I'm using to be a large items table, rather than having one for each feed the user is subscribed to?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
从你写的内容来看：
在数据库世界中，至少对我来说，这是疯狂的。
试想一下，用户想要订阅 1.000 个 rss 提要，您会创建 1.000 个表吗？决不。
您可以通过主键和外键将数据关联起来，为什么不使用此功能。
首先，您可以更轻松地编写查询。您不必担心表名。您将有一个表 rssfeed 和一个表帖子，然后所有内容都会链接在一起。
花时间对数据库进行建模。对于你的情况来说，这不会那么难。
您可能需要 3 到 4 个表才能处理 rssfeed、帖子和元数据。
在这里问另一个问题：如何设计一个数据库来满足这种需要？
人们会很乐意帮助你。
提出你的问题将节省时间、金钱（即使与此无关）和最佳实践（避免丑陋的设计）。
From what you wrote :
In a database world, at least for me, that is insane.
Just try to picture the user wants to subscribe to 1.000 rss feeds, will you create 1.000 tables ? No way.
You can put your data in relation thanks to Primary Key and foreign keys why don't you use this strenght.
First it will be easier for you to write your query. You won't have to worry about table name. you will have a table rssfeed and a table post then everything will be link togheter.
Spend time modelling your database. In your case it won't be that hard.
You might need 3 to 4 tables in order to handle rssfeeds, post, and metadatas.
Ask another question here on : How to design a database for this need ?
People will help you with pleasure.
Ask your question you'll save time, money (even if its not about it), and best-practices(avoiding ugly design).
存储此类数据的典型方式（假设所有提要的数据结构都相同）实际上是为所有提要使用一个表。
为什么？因为这将允许您以相同的方式访问所有提要。例如，假设您想要将所有提要合并到一个视图中，或者计算所有提要的某种统计数据。通过将它们全部放在一个表中，这将变得非常简单；将它们全部放在不同的表中将使事情变得更加复杂，并且没有任何（据我所知）附加值。
The typical way of storing such data (assuming that the structure of the data is the same for all feeds) is indeed to have a single table for all feeds.
Why? Because this will allow you to access all feeds in the same way. For example, lets say you want to combine all feeds in a single view, or calculate some kind of statistic on all of your feeds. By having them all located in a single table this will be extremely simple; having them all in different tables will make this much more complex, without any (as far as I can see) added value.
这是一个编码简单性与每个 RSS 提要拥有一个表可能略有性能优势的问题。拥有一张表（而不是每个 feed 一个）意味着您的代码不必执行任何 DDL，并且您可以更轻松地进行跨 RSS-feed 搜索；但查询和更新可能会慢一些。我可能会选择带有 Feed 列（索引）的单个表以使搜索更简单。
It's a matter of simplicity of coding versus the probably slight performance edge of having one table per RSS feed. Having one table (rather than one per feed) means your code doesn't have to do any DDL and you could more easily do cross-RSS-feed searching; but queries and updates could be a little slower. I'd probably opt for a single table with a Feed column (indexed) to make searches simpler.