'Standard' solution for incorporating databases in standalone applications 
Author Message
 'Standard' solution for incorporating databases in standalone applications

Hi there,

I am currently developing an application which heavily relies on data
residing in a Postgres database. I want to be able to distribute the
application though as one complete entity and not to have to have a fully
separate installation of postgres.

I'm sure that this situation must arise all the time - that is a data driven
application needs a SQL backend but is required to exist as a single
application.

Of course I could mutilate the postgres code to my own end, but that seems a
little sad.
Also I'm writing the application in Java so that it can run under UNIX, Mac
and Windows - this would mean such {*filter*} would be a little pointless.
If the solution was nice enough however, I might resort to writing it in
C/C++.

Does anyone have any idea how such a solution is normally implemented?

Many thanks for any help in advance,

Joel.



Tue, 04 May 2004 08:15:39 GMT
 'Standard' solution for incorporating databases in standalone applications

: I am currently developing an application which heavily relies on data
: residing in a Postgres database. I want to be able to distribute the
: application though as one complete entity and not to have to have a fully
: separate installation of postgres.
: I'm sure that this situation must arise all the time - that is a data driven
: application needs a SQL backend but is required to exist as a single
: application.

I see this come up from time to time, and I have never seen why people
insist that this means it must all run as one process.  You can easily
package Postgres to install in a custom location with the rest of the app,
use a non-standard port (or just shared mem) for client connects, add your
application to the mix and you have a 'single application'.

You don't need to squeeze the postgres code like silly putty to make it
fit.

: Of course I could mutilate the postgres code to my own end, but that seems a
: little sad.

And a waste of time.

: Also I'm writing the application in Java so that it can run under UNIX, Mac
: and Windows - this would mean such {*filter*} would be a little pointless.
: If the solution was nice enough however, I might resort to writing it in
: C/C++.

You might just be screwed on MacOS9 and below.  I hope when you say Mac
you mean 'OSX', otherwise known as 'BSD'.

: Does anyone have any idea how such a solution is normally implemented?

Take the above approach.  Accept the idea of distributing a multi-process
application.  And if your app takes off, and need multi-user support, or
very large datasets, you won't have to rework the goofy changes you made
in your backend.

HTH.



Wed, 05 May 2004 00:14:55 GMT
 
 [ 2 post ] 

 Relevant Pages 

1. TSReorg from Platinum / Database 'standards'

2. Integrated Manufacturing Management System Database(standalone for ibm's)

3. PRESS: INFORMIX'S SOLUTION ALLIANCE GUIDE AND SOLUTION NET NOW

4. Ansi standard for 'is not null'

5. Using XML for 'non standard' data

6. ideas for 'standard table code'

7. 'Thin client' reporting solution for blobs

8. ORACLE DOESN'T COMPLY TO BASIC STANDARD SQL: SIMPLE QUERIES DOESN'T WORK

9. San Diego Convention Center during Informix's Solutions Portal '9

10. What's up on DataB's Standards

11. parser for 'standard' delimited files


 
Powered by phpBB® Forum Software