File Format
-
how many records will you need? 10? 100? 1000? simply don't know? IMO for anything above 30 it takes a database to do it well. It's the most scalable approach. And it's easier than XML if you ask me. :)
Luc Pattyn
Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.
Local announcement (Antwerp region): Lange Wapper? Neen!
I guess it would be fairly open ended as to how many podcasts that a user could subscribe to. I never really thought about how many records there would be( starting to sound like the amateur I am here!:) ) Actually thinking about my own usage, I am subscribed to about 10 different podcasts each with say 10-20 episodes in it. Certainly over your 30 records mark! ;) lol Is that a good rule of thumb? More than 30 use a db? Thanks Cads
-
It just seems so OTT to use a Database to store what is basically RSS Feed data. [edit]Although saying that I didn't think of using Access...hmmm...just not sure...
Senseicads wrote:
It just seems so OTT to use a Database to store what is basically RSS Feed data.
Lots of RSS-data, and I guess that you want to search it fast :)
Senseicads wrote:
Although saying that I didn't think of using Access
I'd go for SQL CE; it can't create nifty reports like Access does, but all that you need is a searchable datastore.
I are Troll :)
-
I guess it would be fairly open ended as to how many podcasts that a user could subscribe to. I never really thought about how many records there would be( starting to sound like the amateur I am here!:) ) Actually thinking about my own usage, I am subscribed to about 10 different podcasts each with say 10-20 episodes in it. Certainly over your 30 records mark! ;) lol Is that a good rule of thumb? More than 30 use a db? Thanks Cads
Senseicads wrote:
Is that a good rule of thumb? More than 30 use a db?
No it isn't. The real rule of thumb is: few ==> file; many ==> database. But that could be considered a bit vague. So I volunteered 30. Don't pin me down on the number. :)
Luc Pattyn
Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.
Local announcement (Antwerp region): Lange Wapper? Neen!
-
Senseicads wrote:
It just seems so OTT to use a Database to store what is basically RSS Feed data.
Lots of RSS-data, and I guess that you want to search it fast :)
Senseicads wrote:
Although saying that I didn't think of using Access
I'd go for SQL CE; it can't create nifty reports like Access does, but all that you need is a searchable datastore.
I are Troll :)
Lol I think you are right. I pretty much just need a datastore. Thanks for the guidance :) Ian
-
Senseicads wrote:
Is that a good rule of thumb? More than 30 use a db?
No it isn't. The real rule of thumb is: few ==> file; many ==> database. But that could be considered a bit vague. So I volunteered 30. Don't pin me down on the number. :)
Luc Pattyn
Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.
Local announcement (Antwerp region): Lange Wapper? Neen!
No from now on it will be Luc said 30!!! its too late now! its in print and everything! :)
-
Lol I think you are right. I pretty much just need a datastore. Thanks for the guidance :) Ian
-
Senseicads wrote:
i don't really want to save my subscription list in a db either, that seems to me to be overkill
Go for a database with a small footprint. You can use SQL CE or Microsoft Access; both a relative small, and it would be easy to define a primary key or a unique-constraint :)
I are Troll :)
Eddy Vluggen wrote:
Microsoft Access;
X|
only two letters away from being an asset
-
Senseicads wrote:
It just seems so OTT to use a Database to store what is basically RSS Feed data.
Lots of RSS-data, and I guess that you want to search it fast :)
Senseicads wrote:
Although saying that I didn't think of using Access
I'd go for SQL CE; it can't create nifty reports like Access does, but all that you need is a searchable datastore.
I are Troll :)
SQL CE is obsolent. SQL Server Compact[^] is the current rendition
only two letters away from being an asset
-
SQL CE is obsolent. SQL Server Compact[^] is the current rendition
only two letters away from being an asset
-
No from now on it will be Luc said 30!!! its too late now! its in print and everything! :)
Right. So start choosing your DB, your SQL dialect, your server, and your backup service. :)
Luc Pattyn
Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.
Local announcement (Antwerp region): Lange Wapper? Neen!
-
Eddy Vluggen wrote:
Microsoft Access;
X|
only two letters away from being an asset
Yeah, that's the standard-reaction, you get the some one when talking about Visual Basic 6. Many a brownfield is a combination of those two :) Access empowered a lot of non-programmers to create small business-applications. It got abused as a server-database, and is still one of the better reporting engines (You'd only need to free runtime-version of Access and Microsoft Word) Yeah, they were great products in their time, and they still haven't vanished. I guess that they're like Windows, or Democracy. We know it sucks, but there is no better alternative available yet.
I are Troll :)