File Format
-
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 :)
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...
-
Hi everyone, I am kind of just after a bit of advice and opinon. I am making a podcatcher in C#(duh that's the board I am posting to :) ). I don't have any problem with the coding yet(touch wood) however I am trying to decide how best to store the information on the subscribed to podcasts and their relevant episodes. Straight away I thought about saving it as an xml file, podcast RSS downloaded as an xml file, fairly easy convert of my object into XML and then back to saving it. But then I thought it could get a bit iffy when it comes to duplicates. I don't really want to have to traverse the entire XML doc to find duplicates, and ensure that they don't happen. So thinking ahead i created my podcast episode objects with a unique id. but then i don't really want to save my subscription list in a db either, that seems to me to be overkill. The only other thing is to just output the subs list into a text file, then read each object in and ensure that there are no duplicates from what ever storage container i put them in(ArrayList prob :)) This seems a bit naff too though. I don't know I think maybe I am just rubbish at making a decision :), but I would appreciate some other people's input into how they would store the data. Thanks in advance Cads
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!
-
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 :)