Board index » delphi » Standard Database Application To Support Many Databases

Standard Database Application To Support Many Databases

I want my new application to support many databases, can be local versions
like Advantage Local Server or C/S.
What should I do? What I need? I don't have any experience with that kind of
design.

Thanks! Bye!

--
Bruno Lovatti
Hortifruti - Tecnologia da Informa??o
www.hortifruti.com.br

 

Re:Standard Database Application To Support Many Databases


Quote
> Eric exagerates at steps 3-4. You only have to throw everything away the
> first 2-3 times. After that pieces start getting salvageable <g>.

<g> How true!

Re:Standard Database Application To Support Many Databases


have a look at kbmMW it looks very promessing plus it's all done :c)

http://www.components4developers.com

Christian

Re:Standard Database Application To Support Many Databases


Thanks to all!

Bruno Lovatti
Hortifruti - Tecnologia da Informa??o
www.hortifruti.com.br

Re:Standard Database Application To Support Many Databases


Quote
Bob Dawson wrote:
> Eric exagerates at steps 3-4. You only have to throw everything away the
> first 2-3 times. After that pieces start getting salvageable <g>.

Hmm.... I am working with my 2nd persistent framework now.  Just about
to start.

Probably I should stop and throw it away now, so next one will be
usable.... <VBG>

Wien.

Re:Standard Database Application To Support Many Databases


"Kyle Cordes" <k...@kylecordes.com> wrote

Quote

> Now back to the first part: why would you necesssary end up with
> something unflexible and hard to extend?

Lack of sufficient domain knowledge to understand _how_ to build flexibly?

bobD

Re:Standard Database Application To Support Many Databases


"Kyle Cordes" <k...@kylecordes.com> wrote

Quote

> I'd agree that it takes a while to learn to build things flexibly.  I
> would not call that domain knowledge, though, unless the domain is "how
> to write software well".

Strenuous disagreement.

Certainly there are design principles that support flexibility, and we can
distinguish between well-structured code and poorly structured code.
Nevertheless, correctly applying those principles to any specific problem
unavoidably demands an intimate knowledge of the problem domain itself, and
that is as true of writing an OPF as it is of anything else: domain
knowledge is indispensable.

Here, the domain just happens to be largely internal to the machine, but
there is no fundamental (design relevant) difference between generic object
persistence (as a problem domain) and customer service, production control,
order tracking, or any of the myriad other domains to which we apply
ourselves. I think the idea that knowing "how to write software well" is
sufficient for any project as absurd as the idea that you can be a good
manager by following generic management principles and without knowing
anything about the specific business you're in.

I'm reminded of the lament I wrote to Joanna in this forum just over two
years ago:
===
A layered, object-based framework for a system of business applications has
this in common with a bridge:

(1) it's far from being a trivial undertaking,

(2) if you don't already know what you're doing, it's generally impossible
to see whether what you've done so far is right until it's too late (and the
bridge collapses, or it becomes obvious that the support piers aren't in the
right place, or that your traffic estimate was way off, etc. etc.),

(3) in important ways, nothing works until and unless everything works,

(4) everything you already know how to do (like finishing the road surface)
is secondary and dependent on the things that you don't know how to do (like
designing the understructure)--so you can't work naturally from the known
into the unknown, and

(5) ultimately, it's well to remember that you weren't hired to have fun
learning to design better bridges, no matter how much that appeals to
you--you were hired to build them.
===

Point being: one has to know what an OPF is before one can design one
flexibly, just as one has to know something about how chemical manufacturing
works to write a chemical process control system. My first OPF didn't far
short for lack of flexibility or bad design decisions, if fell short because
I didn't understand the problem domain, resulting in me not really knowing
what was desirable or possible.

bobD

Re:Standard Database Application To Support Many Databases


Quote
"Bob Dawson" <RBDaw...@prodigy.net> wrote in message

news:3d724ac2@newsgroups.borland.com...

Quote
> "Kyle Cordes" <k...@kylecordes.com> wrote
> > I'd agree that it takes a while to learn to build things flexibly.
I
> > would not call that domain knowledge, though, unless the domain is
"how
> > to write software well".

> Strenuous disagreement.

> Certainly there are design principles that support flexibility, and we
can
> distinguish between well-structured code and poorly structured code.
> Nevertheless, correctly applying those principles to any specific
problem
> unavoidably demands an intimate knowledge of the problem domain
itself, and
> that is as true of writing an OPF as it is of anything else: domain
> knowledge is indispensable.

If I was going to create an OPF for widespread use, commercial sale,
etc., I'd surely follow all of your excellent advice, I'd use developers
with extensive experience in that area, etc.  On the other hand, in the
situation of creating just enough of an object persistence mechanism to
implement the application at hand, I'd be quite comfortable with using
just generic, but very good, programmers for the job.

Why the difference?

Because when creating something for your own team's use, you the ability
to change it going forward.  If you discover partway in to the
application development that you need the design to be a bit different,
that's a good thing; you can apply your greater knowledge to make the
design better.  Change it.  Add a another layer of classes.  Adjust an
interface, whatever.

On the other hand, if you're building a framework for commercial sale,
getting it right the first time is much more important - because the
people using it generally won't have the skills, inclination, or perhaps
even the source code to change it.  You need to use long experience in
knowing what kinds of things they will need to get it right.  If you get
it wrong, your customers and revenue stream could stop.  This is where
the bridge metaphor has some merit.  Basically, Bob, I'd hire you to do
it.  :-)

The most hazardous situation is in a building a framework of any kind
(including an OPF) as a corporate standard for company-wide use.  In
such a situation, there will often be a strong political structure in
the organization to ensure that the framework is used, even if it turns
out to be technically inappropriate, productivity-draining,
bug-inducing, and demoralizing.  The "safety valve" of customers
deciding not to buy/use it is not there, so the importance of making the
design really, really good in the first place is even higher.  This
situation is so perilous that I recommand that no framework
(particularly something like an OPF that gets embedded in the middle of
an application) be made a corporate standard until after it has been
used in, and improved by, several substantial projects.

Another comment, along a different axis:  Having used (and built) a
number of object persistance mechanisms, I'm not yet convinced that a
generalized OP mechanism across widely dissimilar projects is always a
good idea.  I've found that different project tend to have different
needs for object persistance, to the extent that using one for all of
them can cause unnecessary complexity.

--
[ Kyle Cordes * k...@kylecordes.com * http://kylecordes.com ]
[ Consulting, Training, and Software development tips and   ]
[ techniques: Java, Delphi, ASTA, BDE Alternatives Guide,   ]
[ JB Open Tools, EJB, Web applications, methodologies, etc. ]

Re:Standard Database Application To Support Many Databases


Maybe this:

1- The OPF is primary or only for SQL or also XML, TXT, etc...?? - Like
happend with techinsite
2- Include or not a GUI side?? - That it, develop custom VCL component or
wirte gui code at hand - Like with VS.NET
3- Is for any languaje,or is target to a especific language?? - Support for
Java, .NET, Delphi???
4- Is for 1 tier-n-tier or client/server or n-tier only??? (A lot of tuned
is required for n-tier)
5- Use viusal help to design and build (i.e. like BoldSoft) or is for write
at hand???
6- Use a common fundation (like javabeans and taht things), help for things
like COM+??
7- You option here :)

Re:Standard Database Application To Support Many Databases


"Kyle Cordes" <k...@kylecordes.com> wrote

Quote
> [...]  On the other hand, in the situation of creating
> just enough of an object persistence mechanism to
> implement the application at hand,

Hmmm---might be a slippery slope definition. At what point does a
disciplined, patterned approach to persistence in a small application become
worthy of being called an OPF? For example, an application deals with a half
dozen persistent classes, each of which goes to a persistence service
manager that isolates it from the database. But the back end is entirely
hard coded for those specific classes, so that we have functional layering
but no generic services. That the kind of 'just enough' mechanism you mean?

Quote
> Because when creating something for your own team's use, you the
> ability to change it going forward.  If you discover partway in to the
> application development that you need the design to be a bit different,

I think this is the scenario that Eric and I had in mind originally--and the
one in which discovering that the design needs to be 'a bit different' is,
at least initially, frequent and massive. It's not just a matter of good
design enabling you to change the sauce without modifying the noodles, it's
more a matter of deciding that the whole idea of lasagna was wrong, and even
the garlic bread has to go, great as it is. (Sorry--I trained as a lit major
and tend to think in metaphor).

Quote
>    I've found that different project tend to have different
> needs for object persistence, to the extent that using one for all
> of them can cause unnecessary complexity.

Certainly I agree on the parameter of scale: there may be different 'best
practice' OPF approaches to desktop, C/S and distributed or n-tier
applications. And I think whether one is working green field or rebuilding
an existing system fundamentally changes design goals and constraints. Did
you have other parameters in mind?

bobD

Re:Standard Database Application To Support Many Databases


Quote
"Bob Dawson" <RBDaw...@prodigy.net> wrote in message

news:3d7558db@newsgroups.borland.com...

Quote
> Hmmm---might be a slippery slope definition. At what point does a
> disciplined, patterned approach to persistence in a small application
become
> worthy of being called an OPF? For example, an application deals with
a half
> dozen persistent classes, each of which goes to a persistence service
> manager that isolates it from the database. But the back end is
entirely
> hard coded for those specific classes, so that we have functional
layering
> but no generic services. That the kind of 'just enough' mechanism you

mean?

Yes, that's a good example.  If there are only 6 persistance classes,
you might get more benefit from coding them to meet your particular
needs very closely, then you would from using something generic.  On the
other hand, if you have 60 persistant classes (or 600), it would be most
unwise to do them manually.  You still might do a few manual "tweaks"
for performance reasons etc., while using a generic OPF for almost
everything.

I've spent a lot of time working with frameworks.  I now concentrate
very much on delivering application functionality, and letting
frameworks emerge from that.

Quote
> >    I've found that different project tend to have different
> > needs for object persistence, to the extent that using one for all
> > of them can cause unnecessary complexity.
> Certainly I agree on the parameter of scale: there may be different
'best
> practice' OPF approaches to desktop, C/S and distributed or n-tier
> applications. And I think whether one is working green field or
rebuilding
> an existing system fundamentally changes design goals and constraints.
Did
> you have other parameters in mind?

The scale / application model parameter is indeed an important one.  The
persistence problems in a desktop app can be quite different from those
of a piece of middle tier worker code.  For example, in mid-tier code
it's most common to pull data from the DB, modify, and write, in quitck
succession, then release the domain objects (either to a pool or free
them entirely).  In a desktop app, it's common to have the code work
with a set of domain objects over an extended time period.  These
different usage patterns call for different features for caching, cache
expiration, "dirty bits", etc.

Another axis is the level of domain logic complexity of the app.  For an
app that consist mostly of shuffling fields back and forth to a DB, I
want the persistance mechanism to make that very easy to do generically;
for example I might want the attributes to themselves be first class
objects, for highly generic handling.  For an app that will have lots of
logic added to the domain object classes, it's more important to have
the domain objects "feel" more native to the language, which may require
more compile-time and run-time trickery, but would pay off in clear,
easy to modify domain logic code.

--
[ Kyle Cordes * k...@kylecordes.com * http://kylecordes.com ]
[ Consulting, Training, and Software development tips and   ]
[ techniques: Java, Delphi, ASTA, BDE Alternatives Guide,   ]
[ JB Open Tools, EJB, Web applications, methodologies, etc. ]

Re:Standard Database Application To Support Many Databases


Quote
"Jerome Bouvattier" <jerome.bouvatt...@no.thanks.fr> wrote in message

news:3d74b954@newsgroups.borland.com...

Quote
> > Another comment, along a different axis:  Having used (and built) a
> > number of object persistance mechanisms, I'm not yet convinced that
a
> > generalized OP mechanism across widely dissimilar projects is always

a

Quote
> I am new to the OPFs scheme. Could you give some examples to specify
you
> idea ?

There are a couple of examples in a post of mine a minute or two ago,
expanding on an example that Bob gave.

--
[ Kyle Cordes * k...@kylecordes.com * http://kylecordes.com ]
[ Consulting, Training, and Software development tips and   ]
[ techniques: Java, Delphi, ASTA, BDE Alternatives Guide,   ]
[ JB Open Tools, EJB, Web applications, methodologies, etc. ]

Re:Standard Database Application To Support Many Databases


Here's one link
http://www.dimeric.com/DSWeb/Products.dsp
Igor
Quote
"Bruno Lovatti" <blova...@yahoo.com> wrote in message

news:3d6ccdbc@newsgroups.borland.com...
Quote
> I want my new application to support many databases, can be local versions
> like Advantage Local Server or C/S.
> What should I do? What I need? I don't have any experience with that kind
of
> design.

Re:Standard Database Application To Support Many Databases


On Thu, 5 Sep 2002 12:12:52 -0700, "Igor Ivanov"

Quote
<igiva...@infoserve.net.deletetoomuchspam> wrote:
>Here's one link
>http://www.dimeric.com/DSWeb/Products.dsp

Here is other

http://www.alphora.com/tiern.asp?ID=DAC

Alfredo

Other Threads