Re: dbus and GNOME 2.8

[jamie <jamiemcc blueyonder co uk>]

On Tue, 2004-04-06 at 16:46, Alan Cox wrote:
> On Maw, 2004-04-06 at 00:31, Jan Morén wrote:
> > Let Markus run Postgres, let Jamie run Firebird, let me run MySQL, and
> > perhaps have SQlite as the default, built-in provider in case no DB is
> > actually installed by the user?
> 
> Agreed. SQlite's great strength is the zero-setup side of things, a big
> database strength is the centralisation, LDAP's is mirroring and so on.
> Its not useful to try and define a "one true solution" here

Well SQLite is not an RDBMS - yes its a database but nothing more. If
all we want is dumb data storage then yes SQLite is all we need but the
biggest advantage of having an RDBMS with stored procedures and triggers
is that we can centralise business rules for the data in order to
protect its integrity and avoid additonal coding effort by duplication
of said business rules in multiple clients (the clients become thin
clients which are quicker to code and less buggy as a result).

E.G. consider a diary or appointments facility that we store in a DB. If
all we care about is the storage of the appointments in a table then all
client apps that use this facility have a responsibility to make sure
the data for it is correct and that it adheres to some business rules.
So say a business rule is that appointments must never overlap each
other timewise (ie they exist within a unique timeslot on any given
day). On Firebird/Postgres you can easily enforce this business rule via
a trigger on the "Before Insert" operation on the appointments table -
all client apps that use this facility do not have to worry about any of
the rules so if they blindly add an erroneous appointment the server
will throw an exception and inform the app. On a non-RDBMS like SQLite
every client app that wants to make use of this has to enforce and code
this rule separately which means additional coding effort. Now heres the
killer - what happens if a client app is buggy or does not enforce that
rule? Of course your appointments data is now potentially screwed up and
you have no data integrity. And who's to say what the business rules are
- surely it would be left to the developers of the clients to decide
what data rules to implement so you are bound to have inconsistency
here.  Data validation aside, there is also additional value in having
stored procedures which are typically used to perform multiple
queries/calculations in one step. The client apps need only call a
stored proc to perform a complex task as opposed to each of them coding
out the task in multiple queries/calculations.

I believe it is essential to have a schema + business rules clearly
defined for whatever facilities/entities we want to use be they storage,
calendars, appointments, contacts or something else. It clearly makes
sense to enforce these rules once on the server rather than duplicating
effort in all the client apps and its the only way we can guarantee the
integrity of this data against rogue/buggy/incomplete apps.
Unfortunately as I have said, stored procs, triggers, check constraints
and such like are specific to a partcular RDBMS so if we want this we
have to standardise on a single RDBMS. 

Hope that makes sense.

jamie.

> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
>