Database management (SQLite) and table generation

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 i开发者_如何学运维dea 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?

From what you wrote :

to create a new table for every feed the user is subscribed to

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.

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.