Re: The Zen nature of a Delphi database application
- From: Jason King <jhking@xxxxxxxxxxx>
- Date: Thu, 15 Feb 2007 00:41:20 -0600
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.
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. Look at your business processes and commit when they are done. Think in terms of what you'd want to happen if the power went out at the end of each step. I don't know your application so I can't give you the answer as to whether to commit or rollback (erase) three steps of a hypothetical five step process in your application.
I know I've answered some of your questions with "it depends" but that's the best answer I can give at this point. Feel free to ask other questions, I'll answer as best I can. Getting your head around the first database application is the hard part, and you've already missed the first pothole by splitting your data between different tables. Your average database noob tries to put everything in one big table as though "create table" statements were expensive.
marek jedlinski wrote:
If I have a seemingly basic question about using a database in a Delphi.
app, but can't find the answer in Borland manuals, or in samples, or in
Mastering Delphi 5/6, or in Developers Guide ditto, or really anywhere
else, then either it's something everybody else was born with, or it's one
of those Zen questions that defy reason. I've no idea which it is.
I've used Delphi for years, but am completely new to db-backed projects. I
want to use a database (tinkering with Nexus embedded, so far) because the
size of data makes loading it all into memory and writing out to disk when
user clicks Save unsuitable. I've studied SQL and database design a little
and know how to create tables, run queries, etc. In the application, what
will look like a unit of data to the user will actually be distributed
among three separate tables, joined on a UID. I am not going to use
data-aware components. So now for what I just can't figure out:
Should I (a) use database functionality ONLY, and connect query results
directly to UI controls, then write data from the controls to the DB? Or,
should I (b) read from the DB into objects that represent the data (a "data
model"), populate UI controls from those objects, then write data back from
the modified objects to the DB for storage?
I really want to do (b), but I'm getting nothing but puzzles when I try.
How can I build a list of my business objects, if I just said their data is
to be too big to fit in RAM (due to "blob" content)? If I load the whole
contents of the database into my business objects, then I'm missing the
whole point of using a database, aren't I?
Or: each BO has a read-only UID property, passed as an argument to the
constructor. I cannot construct the object without the UID, but I don't
have the UID until I have stored the object in the DB, since the UID is the
autoincrement field. This one really puts a damp on my thinking.
Or, if my BOs are shown in a grid, and the user edits a value in a single
object, should I update just the BO, or both the BO and the DB at the same
time? If just the BO, when's a good time to update the DB? And how can I
ensure that the two don't go out of sync if a write operation fails?
I feel that all these questions are aspects of one and the same fundamental
issue. I've never had any of these problems when working with stream-based
storage, of course. What is eluding me?
Kind thanks in advance,
marek
--
No ads, no nags freeware: http://www.tranglos.com
--
No ads, no nags freeware: http://www.tranglos.com
Skype: tranglos GG: 5967086
"Anyone who incites violence, other than those elected, will have to face the law." -- Ethiopia's Information Minister Bereket Simon, asked why the Ethiopian government arrested 14 opposition leaders.
- Follow-Ups:
- Re: The Zen nature of a Delphi database application
- From: Bjørge
- Re: The Zen nature of a Delphi database application
- References:
- The Zen nature of a Delphi database application
- From: marek jedlinski
- The Zen nature of a Delphi database application
- Prev by Date: Re: Problem freeing components with .free
- Next by Date: Re: Problem freeing components with .free
- Previous by thread: The Zen nature of a Delphi database application
- Next by thread: Re: The Zen nature of a Delphi database application
- Index(es):
Relevant Pages
|
