Re: The Zen nature of a Delphi database application

On Fri, 16 Feb 2007 23:37:18 +0100, "Bjřrge" <bjorge@xxxxxxx> wrote:

If you do want to use them objects, consider using a proxy technique: If you
load a list of objects for some sort of display, don't retrieve all data
fields. Only those needed for display or locating purposes. Whenever you
need the guts of the object, reread the data, but now all field values.

This is what I've been planning/trying to do; or at least to read blob
fields on demand. What I'm wary of is peppering all units with db-related
code, which is where this has been leading me so far.

To be honest, I have dreamt of the perfect OO database application framework
since I learned about OO. But I feel that you somehow address one major
obstacle; no single scheme will work well in a wide range of application
sizes and kinds.

That's one important point. I'm working on reviving a project that I put on
hold for a long time. When I wrote it initially, I never imagined what
users were going to want to do with it. It handles files of 1-2 MB in size
without a problem, but then I started getting emails about it opening
slowly because the file was 30 MB in size :) At that point a lightweight
database and on-demand loading start to make sense.

What's drawing me to databases specifically is the ability to store
individual records/entries, as opposed to streaming in and out whole
sollections. But since I've never used databases before, I'm finding it
hard to switch to the "db-aware" mode of thinking, so to speak.

I spent a few years trying to come up with a general
storage interface that would be possible to implement in storages based on
flat files, databases and application servers. I ended up using a sream-like
interface, but I never solved one of the major issues in my model: How to
implement a collection whose total count in unknown, like db datasets are
(you access them by "next;", "prior";, etc., as opposed to "for i:=0 to
count-1") ?

Similarly, I've been trying to figure out if I can abstract out the storage
model so that the application "engine" doesn't care if storage is
stream-based or db-based, but the two seem too dissimilar to be bridged
cleanly.

I find myself writing less OO every day. OK, I use OO more for metadata than
for production data containers. If you don't need polymorphism, don't use
OO.

What about storing polymorphic objects in a DB? That's another bit of a
snag for me. What used to be a single collectin of polymoprhically-accessed
objects is now a number of different tables, since each subclass needs its
own set of fields.

Most databases come with an ID generator, or you could create one. Before
creating any db record, get this ID. Stay away from "autoinc" fields - the
use of them cause your trouble.

Thanks for that :) When I learn about autoinc fields, I figure hey, that's
useful! But then it seems to make things harder than they need to be.

Thank you and others for responding; I'm beginning to feel a firmer ground
:)

marek


--
No ads, no nags freeware: http://www.tranglos.com

--
No ads, no nags freeware: http://www.tranglos.com
Skype: tranglos GG: 5967086

"If you're happy and you know it, clunk your chains."
.

Relevant Pages