Desktop Database

A DesktopDatabase is a system for managing data stored usually on local media. It may or may not be based upon a relational model. To allow for scaling and sharing of data some implement a peer-to-peer architecture.They usually come with rich, visual data-centric UI's, often allowing an entire desktop application to be developed, distributed and used by groups of other desktop users. They generally also include significant visual report writing capability.

Desktop products include:

• MicrosoftAccess
• ParaDox
• FileMakerPro
• ExBase and derivatives such as dBase, FoxPro and ClipperLanguage
• OpenOfficeBase
• SuperBase

{I think the term "real database" can be perceived as derogatory. I would suggest a better name that makes technical distinctions rather than a "goodness" label or ranking. I have seen some pretty useful multi-user systems written using DesktopDatabases.}

Anything that allows file system level access to data, rather than access via a database server. The access idiom is typically of opening live cursors, locking records and posting edits to records. The idiom of a real database is to retrieve static datasets, and perform updates with SQL.

I would not use SQL as the distinguishing factor. The distinguishing factor is probably that clients carry their own copy of the database engine and talk to a file server instead of a centralized database server. This approach scales up to about 10 simultaneous users on a LAN in my experience (but varies per product). After that, a centralized approach becomes more effective.

Desktop databases are widely used in smallish multi-user systems, typically ParaDox for DelphiLanguage systems, MicrosoftAccess for VisualBasic systems, etc. This is usually a bad idea, but I guess it happened because we were familiar with 'simple' table-based access idioms, and because until recently client-server databases were often too expensive.

• No! Desktop DBs are a good idea for personal data mining. Offload the archive server to the desktop of the guy who wants to run 24 hour statistical analysis of everything, whenever possible. This is distributed computation at its best.

Often a desktop database is good enough. Until such time as all major OSs come with a database server built in, for many tasks a stronger database would just make life to hard on the end user. This is one major area where non-MS systems (e.g. GnuLinux) suffer.

---

If you want a fully relational database that easily sists on a desktop and can be scaled - try Solid - http://sal.kachinatech.com/H/1/SOLID.html

---

Databases can mean many things to many people, The value and applicability of a particular database depends on what you are trying to do and for whom.

Casual and Home Users

A DesktopDatabase or even a SpreadsheetDatabase are often all a casual user ever needs in the way of a database.

---

Can anyone suggest a good freeware DesktopDatabase for Windows? For UNIX (i.e. Linux)?

How about SqlServerDesktopEngine for Windows?

MySql works just fine on many platforms; it even has third party add-ons for e.g. transactions. "msql" used to be considered a freeware competitor but I believe it has not progressed very rapidly over the years.

PostgreSql is the most powerful and complete freeware database, with full object-relational features. For many things it is a complete alternative to expensive commercial DBs.

The SqLite library is also ok for many small single user purposes. It is used internally for database functions in MacOsx. As well as AndroidOs? and FirefoxBrowser? and Xmms2

Many people have said positive things about sleepycat.com version of Berkeley DB, although I believe it is more a persistent store than a relational DB.

---

FoxPro, ClipperLanguage, and dBase (ExBase) have enough clout to run serious databases. I did this for more than ten years. Maybe not adequate for managing GeneralMotors? or other large enterprise, but we had production databases that ran city assessor calculations, hotel reservations and maintenance, credit collections agencies, insurance agencies, gaming (slot) floor management with player tracking, and a host of others.

Scalability is certainly possible with these languages, although you don't get it for free.

I've also written enterprise data warehouse stuff using big box OS with big box SQL for large outfits (Hiltons, Cendant, etc). I understand the difference in scalability requirements. I also understand the difference in agility and flexibility requirements.

FoxPro/ClipperLanguage may not be Informix or Oracle, but don't sell them short.

---

One cool feature of some of the ExBase dialect tools was to supply both a row-wise view and column-wise view of data. The row-wise view was convenient for editing of complex records. In some products one could swap between such views with a simple key command or two. AsciiArt example:

Column-wise view:

  Empl_Num |    Name     |  Salary
  --------------------------------
  1234     | Bob Smith   |  55000
  6372     | Laura Li    |  62000
  4726     | Bunge Bob   |  42700

Row-wise view:

  Column   |  Value
  ----------------------------------
  Empl_Num | 1234
  Name     | Bob Smith
  Salary   | 55000
  ----------------------------------
  Empl_Num | 6372
  Name     | Laura Li
  Salary   | 62000
  ----------------------------------
  Empl_Num | 4726
  ....

(In ExBase, the top view is known as the "browse" view and the bottom known as the "edit" view.)

---

See Also: NimbleDatabase

---

CategoryDatabase