13

I began my programming career in web development using PHP and MySQL. I got quite accustomed to utilizing db for storage of most dynamic data as well as some setting/parameter data. Sometimes there would be a lot of data while other times entries in the tables would be few. To me this just seemed natural and as far as I'm aware this is more or less an acceptable approach in web development. (Please correct me if I'm wrong...)

I'm delving into desktop applications now and my natural inclination is to again utilize a db to store a lot of information that will be generated through the usage of the application. However, as far as I can tell I don't see applications (that I use) utilizing a db very often. [EDIT: It has since been pointed out that this was a faulty assumption in that many applications do use lightweight dbs embedded into the program itself.] What is the reason for this? At what point is it appropriate to utilize a db? Are there any standards on this matter? Also what are the reasons to NOT use a db to develop a desktop application?

Kenneth
  • 2,703
  • 2
  • 21
  • 30
  • 2
    "However, as far as I can tell I don't see applications (that I use) utilizing a db very often"? Based on what? If they used SQLite, how could you tell if they were or were not using a database? – S.Lott Mar 23 '11 at 00:44
  • That was why I said as far as I can tell as I knew there was a possibility I was wrong. I figured there might be some apps that use embedded db's... Is it pretty common for apps to use dbs? – Kenneth Mar 23 '11 at 00:55
  • @Kenneth: Please Google for embedded DB's like SQLite. There are many. They're widely used. AFAIK, Apple's iOS uses it for *all* persistence. Please Google. – S.Lott Mar 23 '11 at 01:24
  • 2
    I Google a lot. Sometimes though nothing replaces experienced opinions which you can't always find googling. – Kenneth Mar 23 '11 at 01:39
  • @Kenneth: "I Google a lot." I'm sure you do. Keep it up. Google first, ask detailed questions later. In this case, you can google for the various kinds of embedded databases, and **update** your question to remove your faulty assumption. – S.Lott Mar 23 '11 at 02:06
  • 1
    I think these comments are sufficient to correct the faulty assumption. I apologize for the error. I feel I use a healthy mix of googling and asking questions. Sometimes there's no substitute for latter IMHO. Now my googling will be better directed and more productive. – Kenneth Mar 23 '11 at 02:30
  • @S.Lott Perhaps I should add too that I don't usually take answers to my questions to heart as the honest truth without further research. After asking the question, I then research what I'm told to either confirm or reject that information and come to a decision based on further study. I just got thinking that perhaps you were concerned I asked questions then gave it no more thought? – Kenneth Mar 23 '11 at 02:34
  • @S.Lott I should add (just incase it seems otherwise) that I do appreciate the reminder of how important self-study is. I definitely hope to never forget that fact. – Kenneth Mar 23 '11 at 03:46
  • @Kenneth: "I think these comments are sufficient to correct the faulty assumption". I disagree strongly. The questions still stands, and will be found by others (thousands of others) only as written. No search can piece together a more sensible version of the question by integrating the comments. That requires thinking. Hence my suggestion to update the question. – S.Lott Mar 23 '11 at 09:43

7 Answers7

7

A database system has traditionally been seen as a relatively heavy service - that you didn't necessarily want to install on every client machine out there. I've actually been in situations (desktop GUI app development where a lot of data needed to be saved) where a real DB system would have been an "ideal" solution - but because back in the day the only available databases were relatively heavy, we went with flat data files instead.

Despite there being some lighter databases out there these days, this is still a valid argument against client-side databases. Imagine some simple little desktop app (such as say, a simple desktop toy or game) that has to store a few dozen settings and parameters. It seems way over the top to make a person install MySQL just to run your app.

With web development, the server is naturally a back end, where having a database is par of the course. eg. The users don't have to worry about installing a database at their end.

Bobby Tables
  • 20,516
  • 7
  • 54
  • 79
  • So you would recommend not using a db for stand-alone apps then unless heavy volumes of data really warranted it? – Kenneth Mar 23 '11 at 00:42
  • what are your thoughts on using lightweight db's... same as the full-scale db's? – Kenneth Mar 23 '11 at 00:44
  • 1
    @Kenneth: I'd say "it depends". If the app calls for large volumes of tabular data that really calls for being in a proper DB, then the argument might be strong enough to ship the app with a lightweight DB. But if it's just configuration/settings kind of data, then it's probably overkill. – Bobby Tables Mar 23 '11 at 03:28
5

Desktop applications maintain state while they are running. Whereas web development typically doesnt. So while you might need to store a user setting in a database in between page loads, in a desktop app you just keep them in memory. That greatly reduces the need for such types of persistant storage. When you want to store preferences between uses, you can save them all to one file, or put them someplace like the Windows registry.

That being said, database systems are used quite a lot in desktop apps. Long before the web, desktop applications have been connectiong to DBMS's. Primarily for applications that are not document based. Though these days, with the better availability of light weight engines, you're seing the lines blurred a little bit. For ex, I use SQLite db's as documents in a few of my apps.

GrandmasterB
  • 37,990
  • 7
  • 78
  • 131
  • +1 If you don't have complex persistence issues, like multi-user, multi-location, simultaneous blocking updates a traditional database might be overkill. If the data in question is fairly static (it may grow or get appended to, but does not evolve or get updated), and contension/competition isn't frequent or perverse (side effects/user-experience for waiting on a lock to free isn't unacceptable considering performance and complexity tradeoffs), you may not need a database. – JustinC Mar 23 '11 at 05:38
4

if your application is document-oriented, store things in a document file

if you application deals with more structured data, too much for a single document (like an XML document), use a database

Steven A. Lowe
  • 33,808
  • 2
  • 84
  • 151
4

One thing you might want to look into are lightweight databases that don't require an actual running database service. e.g. on the Microsoft front there is SQL Server Compact, which is free, only requires a single file for the database and some DLLs added to your app, and from a developer's perspective, behaves much the same way as a "real" SQL Server.

I am positive there are similar options on other platforms.

Carson63000
  • 10,510
  • 1
  • 28
  • 50
  • 1
    A very similar example on the Java side is Derby. I think there are others, too. – jprete Mar 23 '11 at 00:32
  • 1
    This sounds like it might be an ideal solution... I really enjoy utilizing db's! lol – Kenneth Mar 23 '11 at 00:43
  • Are there downsides to using lightweight db's? – Kenneth Mar 23 '11 at 00:44
  • @Kenneth: They make your installation larger and can increase the codebase. But that is much less than installing a whole database server on a client, that is only usually done when the application is distributed and needs a more substantial database. The [Berkeley DB](http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html) is one of the most commonly used. – Orbling Mar 23 '11 at 00:53
  • another option is SQLite, which is _far_ lighter on both RAM and disk space, and doesn't have any arbitrary limitations. No wonder it's used by all non-MS smartphones and web browsers. – Javier Mar 23 '11 at 01:55
2

On web applications, it's important to store any persistent state on a centralized storage. Since the web app is usually first bottleneck, it's important to be able to just distribute it without having to question which copy has the data (the 'Shared Nothing' principle). Not just a database, but memcached and queue systems are there for the same reason.

Desktop apps don't have the same scalability goal. Typically, most of the data is locally stored on each workstation. Data sharing is a different issue in most cases. That eliminates one big reason to use a database.

GUI applications also can have complex documents which might be handled as a complex web of objects in memory. Normalizing the structure into a relational DB schema can add significant complexity to the problem, sometimes it's easier to just serialize the whole thing in a single bytestream. Many OOP frameworks include some facilities just for that.

Still, making the stored documents readable with tools outside of the main application is a big advantage in many cases, so either using human-readable formats (XML, JSON, YAML, etc), or a zipfile amalgamating several simpler pieces are getting more and more common.

On the same vein, using an embeddable database library (BDB, Tokyo Cabinet, SQLite, MS-SQL*server Compact, etc.) is another great approach.

Javier
  • 9,888
  • 1
  • 26
  • 35
1

Databases can be overkill but they usually don't have to be. Very simple programs just don't need them. If your document can load up in memory in a trivial amount of time and stay there without issues, you don't really need one for many programs.

For instance consider:

#include "superheader.h"

int main()
{
    int row=2, column=2;
    DatabaseType db;
    db.ConnectTo("programDB", "user", "pass");
    db.setTable("messages");
    string hello_world=db.fetch(row, column);
    cout<<hello_world;
    return 0;
}

Well that is overly simplistic, but obviously this is just too much. There's no real point to having that level of data management for "Hello World"

Usually the rule of thumb I go by is use a database if you have many sets of data, especially if they are uniquely different OR use a database if the amount of data is rather massive. Databases in general are associated with some overhead, but there are many which don't really have much. Small, lightweight, in-memory databases for instance are sometimes useful for small projects with heavy processing, scheduling or lots of dynamic changes to the data.

There are different coding styles, many many times there is nothing wrong with a database but most of us just wont go 'that far' for basic tasks. There are still other times the right database would offer performance benefits. Try to especially understand the differences in where the data will be, how long it will be there and what will change it during it's lifespan.

That Realtor Programmer Guy
  • 826
  • 6
  • 18
1

Using a db is always the right thing and with SQLite implementations for practically every language out there not using one is just poor design decision making. The only reason not to use one is if you're doing embedded programming or some other type of non-application form of programming. Querying data and settings with a declarative language like SQL is much more natural than traversing flat files or other objects in memory with imperative syntax. Plus, it cleanly separates the data operations from other application code which in the long run makes code more modular and maintainable.