XML or SQL?

views:

381

answers:

+2 Q:

I am just beginning to get into desktop application development, and have chosen C# to do so. After making some basic programs, I am wanting to get into more useful creations for myself. I was thinking about making a Project time tracker, as well as a password safe type program of my own. Both of these require taking in information that needs to be stored.

The way I have come across is to use a SQL server for the storage aspect, but from what I have gathered that requires me to have a SQL server installation on all the computers I plan to use these programs with does it not? So I have been leaning towards XML, as it seems to be more mobile and open, but is this a viable option for data storage? And can it be properly encrypted when I get to that step in my password safe program?

Which of these should I begin to implement in my desktop based applications, or is there an alternative I have missed that would be better.

+1 A:

Consider SQL Server Compact, which you can include with your desktop application.

Joe Chung 2009-07-07 02:06:14

+4 A:

SQL Server is not good at all for desktop applications. However, if you want to use a database instead of XML, you should use the SQLite database format, due to not requiring a server, and requires only a single DLL contining both the DB engine and an ADO.NET driver.

MiffTheFox 2009-07-07 02:06:51

You know, I'd go so far as to say you didn't answer his question... sure SQLite might be a great option if he wants to use SQL... but he's still trying to decide that. Is everyone voting this up just because they like SQLite or something?

Telos 2009-07-07 03:56:28

You have the option of using from SQL Express in the upper end down to a zero footprint database such as SQLLite. They seem like better alternatives than XML to me.

Otávio Décio 2009-07-07 02:06:57

Definitely not XML for storing data. XML should be used as a document markup language, not as a storage or non-document data interchange format (although it is used as such).

You should check out SQLite.

felideon 2009-07-07 02:08:07

Are you kidding? XML is/can be a great way to store data and is used that way all the time...

Telos 2009-07-07 02:11:59

Sure, if you like your data format to be more verbose than the data you are storing.

felideon 2009-07-07 02:13:15

XML + zip if size is REALLY a concern for you. Also, you assume your data is 5-10 characters long... It usually isn't...

Matthew Scharley 2009-07-07 02:29:53

You're missing the point. It's not about size or performance. It's about principle and purpose. XML is used all the time because it's "good enough" and "everyone else is doing it." Refer to http://web.archive.org/web/20071231152902/xmlsucks.org/but_you_have_to_use_it_anyway/useful-xml.html to see where I'm coming from.

felideon 2009-07-07 02:55:57

Personally, I'm just thankful for LINQ to XML.

felideon 2009-07-07 02:57:21

@felideon: I have no problem with a little extra size when it makes the data format maintainable and human readable in a pinch. As for your link, it's funny... you claim it's not meant to be a data format but the very first bullet point is about XML being a heirarchical data format.

Telos 2009-07-07 03:05:04

Again, my gripe is not with "extra size". Verbosity has more implications than just "size". Verbosity hurts the very fact you are defending: human readability. Why do we have tools like XML notepad if XML is so readable. If it's so maintainable, why do manipulate DOM rather than parsing XML ourselves? I never said it wasn't meant to be a data format, it's just not it's not what people claim it to be: human-readable and simple.

felideon 2009-07-07 03:48:45

Personally, I manipulate XML in plain text editors, and I don't know what you're whining about. The reason there are tools like that are the same reason there are tools like Dreamweaver and Frontpage. People are lazy. As for parsing XML yourself... The same reason you don't do anything yourself, you use preexisting code to do it. You CAN parse XML yourself, if you want a headache.

Matthew Scharley 2009-07-07 03:54:24

You said "not a storage or data transfer language" so how is that not saying it's not supposed to be a data format exactly? Why do we work with DOM, or have tools? BEcause we use abstractions and tools for EVERYTING. Are you going to argue SQL is bad because we use Linq to SQL or some ORM? What do you mean not human readable? It's in ASCII text, you can open it in notepad and read it. If it's too complex to read, you designed a bad XML schema. That's not the language's fault, it's the designer's

Telos 2009-07-07 03:54:51

@Matthew: "If you want a headache." My point exactly.@Telos: What it purports to be is different than what it actually is, or what it is actually good for. Abstractions and tools are fine, it's just that it's one hell of a leaky abstraction when it comes to XML. Regarding SQL and LINQ to SQL—I won't bother with that straw man argument.

felideon 2009-07-07 06:03:32

You do realize Matthew was talking about writing your own XML parser rather than using existing tools, right? It'd be more of a headache to rewrite (INSERT_TECHNOLOGY_HERE) than to use already written technology in any case. Look, we get it. You don't like XML. That doesn't mean that XML is a bad way to store data. It's such a good way, that most open document formats use it! MS has converted their doc storage to use it. What do you have that's better, without installing a database on PCs, which is overkill AND changes end user experience by moving them away from files?

Telos 2009-07-07 13:18:24

Therein lies the problem: The conjecture "Other people use it, so it must be good!" is a pretty weak argument. And Microsoft, above all, is the example? What is better? S-expressions. But that's a whole other flame war.

felideon 2009-07-07 14:57:45

You're kidding right? Lisp expressions as a human readable data format? Yeah, right. Because armies of parenthesis are so much more readable and easy to parse.

Telos 2009-07-07 15:34:11

Armies of parentheses as opposed to armies of angle brackets, equal signs, double quotes, and slashes? Yeah, very readable. Easy to parse? Substantially easier than parsing XML.

felideon 2009-07-07 16:35:59

Maybe it is harder to parse, if you don't use the five billion tools out there to do it for you. Of course doing THAT would be like writing your programs in Assembly, and there's a reason we don't normally do that either. You're basically arguing one set of punctuation is better than another at this point, which is silly. The REAL question is: which has better support in terms of tools to work with it. Oh yeah, XML.

Telos 2009-07-07 18:00:35

That is a different discussion than the one I (or you) started. The discussion was not of which had better tools—or even community support—but rather why XML was not designed for what it is currently being used for, including but not limited to: non-document data interchange and, worse, storing data.

felideon 2009-07-07 22:50:29

If you say so. I'm pretty sure it was meant to store data, and it works very, very well for data interchange. In fact, it works well for both in part BECAUSE of all the tools out there to make using XML easier. You don't have that with s-expressions, therefore they are NOT as good of a tool to use. Either way, I think using a database for the OP's purposes is probably silly... and using s-expressions without tools would be silly... so, that leaves xml or a proprietary format, which would be even sillier.

Telos 2009-07-07 23:19:08

Actually, the W3C clearly states: "Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere." From the maker itself we can see that (1) XML was not originally meant to be a data interchange format and (2) XML has grown into being used as a data interchange format. Now, whether #2 is a good thing or not is up for debate. However, I can't find anywhere in the W3C site any reference to XML being designed to store data.

felideon 2009-07-08 00:28:34

Also, arguing "punctuation" is not silly at all. Eric Naggum said it best: "Contrary to the foolish notion that syntax is immaterial, people optimize the way they express themselves, and so express themselves differently with different syntaxes."

felideon 2009-07-08 00:30:00

So, you don't understand that electronic publishing would mean both storing data and exchanging it? Interesting. Oh, and when you're arguing that parens are better than angle brackets, you're nowhere near what Mr. Naggum was talking about. Until you show me Linq to S-expressions XML is a better option.

Telos 2009-07-08 16:31:11

Speaking of which, s-expressions weren't designed data exchange either... so they should have no advantage there going by your logic. In fact, they were only meant to be used with M-Expressions, so using them for regular data storage would be just as much of a violation of their original intent/design as using XML for it.

Telos 2009-07-08 16:34:11

Right, because configuration files and time tracking are fine examples of electronic publishing. I never argued parens are better than angle brackets, that is indeed silly and not what Naggum was talking about at all. I'm talking about XML's verbose syntax. Granted, I used the word "punctuation", but note the quotes—I was only using your same wording from before, I should have made this clearer.

felideon 2009-07-08 19:00:28

Please remind me where I've claimed that s-expressions are used or should be used for data interchange. As your Wikipedia reference states, s-expressions were initially designed for data only, and then used as code as well (wherein lies the power of Lisp). But it seems like you are confusing the two terms/purposes: data itself and the interchange of this data.

felideon 2009-07-08 19:26:31

Wait, so when s-expressions do something beyond what they were meant it's "the power of lisp" but when XML does something beyond what it was designed for it's bad? Please. Oh, and there isn't really extra verbosity in XML other than specifying the end tags... which happens to make it easier to read. Which is one of the things we should be shooting for in a human readable data format.

Telos 2009-07-08 19:42:21

Yes, because what XML does beyond what it was designed for, it does poorly. Regarding readability and verbosity, please refer to points #3 and #4 here: http://www.w3.org/XML/1999/XML-in-10-points.html. Wow, here I thought we were arguing that XML was actually meant to be readable, but I guess we were wrong. Then again, wasn't that your premise to begin with?

felideon 2009-07-08 20:06:55

Look, you advocated using a DATABASE to someone who basically needs a simple data storage mechanism. You did that because you don't like XML, and when asked for an alternative you suggested s-expressions which simply do NOT have the support XML does. You can argue all you want about how poorly XML handles data storage or how verbose it is, but the truth is it does a good job at it. S-expressions might be as well, but they weren't designed for it either AND there is not a lot of support/tools to help you use them, so it is the worse option.

Telos 2009-07-08 22:53:55

You're wrong: I did not suggest using a database simply because I do not like XML. I suggested using a database because I really think it is the best option/tool for the task at hand. Moreover, the discussion about sexps had nothing to do with the OP's question or my answer. Even if the OP was actually programming in Lisp I would have also suggested using a DB for storage/object persistence rather than the filesystem. Your rhetorical question specifically assumed the lack of a database, for which I restate my claim: sexps are better than XML. The why is superfluous at this point.

felideon 2009-07-09 01:10:20

So you have a bunch of options. First you can encrypt/decrypt any file you would like as long as you use a two way algorithm. An XML file can definitely be used in this way.

On the SQL route there are a couple light wight database engines SQL Server Compact Edition and SQLite which work of an individual file. You would want to encrypt them also if you used them.

Basically your options are open, it would be a grat opportunity to learn how both systems work if you want to spend the time to do so.

Matt 2009-07-07 02:08:17

+1 A:

Are you thinking of distributing these? Personal use? Corporate use?

You could include SQL with the install, but I feel like that's overkill. However, if you are planning this for personal use or just to learn SQL is a pretty important skill. (XML is too, but it's not as complicated really.) However, if you're doing this in a corporate environment, it might be worthwhile to store all the info centrally on a server that gets backed up... which is pretty ideal reasons to go with SQL.

If you want to distribute this, or don't care about centralizing the data then just go with XML. There's really nothing bad about it, and you just don't need all the power SQL would give you... at the cost of hogging extra system resources, increasing download size and learning curve...

Telos 2009-07-07 02:10:57

+5 A:

I use sqlite for desktop apps that need a good way to store relational information. Lots of other people do too.

SQLite is easy, robust, fast, and light. There are plenty of .NET data providers for sqlite, and there's a nice SQLite browser app to check out your data file.

SQL Server [Express] is appropriate for "big" apps, or apps that need features of a "real" sql database (like stored procedures or something). You can do an embedded sql server express, if you have enough memory on your target machines.

XML is appropriate for (read-only) configuration info, but using it as a r/w storage format is just asking for a lot of time in your debugger.

Seth 2009-07-07 02:22:22

It really depends on the average/expected data size for your application. For something like a password safe the data would be likely in KB, not GB range, and XML may be a better choice, especially for portability (e.g. synchronizing between machines). If the data model is complicated (e.g. more than, say 10, significant entities) or stores thousands of items then a SQL-style database is more appropriate.

An example of an application that uses encrypted XML for storage: ToDoList from AbstractSpoon - source is available too.

Another easy-to-deploy database (1 assembly) is VistaDB.net - recommended, syntax is very compatible with MS SQL Server.

devstuff 2009-07-07 23:32:41

I'm not sure that anyone asked you what you are trying to store. There are cases where a native xml DB has huge advantages over a relational model. That's why there is so much commercial development (MarkLogic, Documentum xDB, etc.) and open-source development (eXist, Berkeley) begin done around non-relational approaches.

However, as you can see by the assumptions made on this thread, most of the data that developers consider to be worth persisting can be handled by an RDB and many even choose to store xml this way.

2009-08-04 20:57:28

ansaurus

tags:

views:

answers:

XML or SQL?

related questions