Re: The Zen nature of a Delphi database application

Jason King wrote:
Marek,
I'm a database guy with very little Delphi experience so our skill
sets are likely inverted images of each other. I'm not familiar with
Nexus, but spend my salaried hours working with Oracle so I've wound
up with a lot of database experience.
Were I building a db-aware application in Delphi I would use the
dbaware and just hook things up that way. First, that's the what
you'll find most tutorials and examples doing. Second, that scenario
you're more likely to get help for. Using the dbaware controls they
should take care of the autoincrement primary key (what you're
calling a uid). Building the 3-tier model you discussed below is
often necessary for applications like web applications that can't
maintain continuous database connections and are running in a
multi-user environment. Since your db and your application are on
the same box and it sounds like its a single user application that 3
tier is just a way to write and debug a bunch more code.

Now what's the point with a 3rd tier ? Then you will have:
a) A database with some model reinforcement
b) a middle tier with all relations, rules and registration functionality
c) a front-end tier with all of this "business logic" replicated to avoid
the client being a plain stupid working environment.

I dived into Delphi's 3-tier component suite - the DataSnap. 5 years later I
still don't understand what kind of applications they were meant for.

Taking the entire db and sucking it up into your application is indeed
missing part of the point of having a db. As far as when you commit
things (if I remember in Delphi that's called a post) do it whenever
the user has completed a business process. In database speak that's
called a unit of work.

If you were doing a banking application and
had a function to move money from one account to another you'd only
commit after both actions happened. To commit after adding to one
account makes the customer happy but might leave the bank short, to
commit after subtracting from one account leaves the bank safe but
makes unhappy customers.

....and many problems with creating database apps stem from db servers mainly
created to perform account transfers or it's like. They are in fact quite
primitive and have changed very little over the last two decades. So have
banks. But all applications are not banking applications. What about
applications who won't ever need to deal with multi-user problems or atomic
transactions ? They are not that rare...

--
Bjørge
bjorge@xxxxxxxxxxxx


.

Relevant Pages

  • Re: Newbee on web apps with Delphi
    ... > I need to develop my first web application with delphi for database ... I'll try to describe what I know about writing such applications: ... session (but I gave up on this as the Apache Web server couldn't handle it). ... ASP.NET (Delphi 8->): I've just started looking into this one, ...
    (comp.lang.pascal.delphi.misc)
  • Re: polymorphism (was: Poly Couples)
    ... but this is not really "business software"... ... Most of such applications are built as a combination of ... database with flat files or a different RDBMS vendor?" ... couldn't care less if I do it in using structured programming or OOP ...
    (comp.object)
  • Re: Unisys OS/2200 DMS / TIP / COBOL Migration
    ... support the legacy system api's that the application is using. ... differences in COBOL compiler dialects. ... What DBI does is to provide legacy database (DMS) ... the legacy database to the COBOL applications. ...
    (comp.sys.unisys)
  • Re: Database set up help
    ... let's see...I choose the y/n data type because I am using ... User opens up form and enters Employee Information in the fields ... 2 of the 38 options in my main menu are BPCS Applications ... I set up a database with this so far: ...
    (microsoft.public.access.gettingstarted)
  • Re: Advice needed for a growing Access 2000 project
    ... However, it turned out that quite a few of those were "leftovers" from previous releases, no longer accessible from anywhere but the database window, and, thus, no longer used. ... But that certainly isn't the _norm_ -- without any 'heroic' measures, there are routine reports of split Access DBs ... Finally, in my opinion, for "Windows apps", that is, individual-user applications, modest-sized multiuser applications, and client-server applications of any size, Dot Net does NOT "help along" any of these issues. ... The post I reference was in reference its self to the MS Access Help file under "Microsoft Access database general specifications" ...
    (comp.databases.ms-access)