| Subject | RE: [firebird-support] Install Firebird |
|---|---|
| Author | Ken Galbraith |
| Post date | 2004-10-08T15:47:29Z |
Lester Caine wrote
time. My application (Accommodation Reservation System) like (I imagine) any
application, has quite a few "static" tables which end users can't (& I
don't want them to) update in any way. When the "Embedded" version of
Firbird was announced, I was hoping that I could use this to access "read
only" tables & access "read/write" tables from a server. This does not seem
to handle my requirement of multiple "instances" of my application running
on the same workstation. Your mention of running multiple servers looks like
it would handle my requirements.
Please correct me if I am making the wrong assumption, but I have
ascertained from the entries in the support n/g that while the "embedded"
version of Firebird allows accessing db's from a server as well as access
to a local DB, only "one" task on the W/s can access the local DB.
It would be really nice if "read only" db's could be accessed from the
client m/c & the dynamic R/W db be accessible from a server! I don't believe
I am an orphan in regard to this requirement as many applications need
access to read only DB's (such as Location, Postal Code lookup, Country Code
lookup [in fact a whole range of "lookup tables"] which if they were located
on client m/c's would eliminate a heck of a lot of network traffic).
Maybe the question I am asking is "if a DB is "read only", can multiple
instances of embedded Firebird access it from a client m/c"? & if not - why
not, because to me that would be an invaluable facility for any application
I can think of! With the horsepower of current client m/c's, I can't see the
overheads you have mentioned being a problem. Lester, I seem to remember you
mentioning using UK Postal code lookup and that DB must be an order of
magnitude larger that Australia's (~14,000 post codes) due to the UK having
PC's down to the street number level (I believe). Even with N/W's going to
the 1 & 10 Gbps range, lookup tables of a large size are a drain on the
server Disk I/O and would be better serviced as you have intimated by local
access thru' a local server.
Ken A Galbraith
PS: When I mentioned r/o & r/w tables above, I am aware that they would need
to be in separate DB's!
>Lester, I believe you have answered a ? I have wanted to ask for a long
> Clark Asd wrote:
>
> > Is it a failure (regarding performance) to install on
> > every client machine the server installation of
> > firebird instead of the client installation. Soemtimes
> > I do this because it may be possible to change the
> > machine which acts as server without new installation
> > of firebird.
>
> If the copy of Firebird server is only started when needed, then there
> will be no impact. If you start a copy on every machine, then will use
> up a bit of memory space and may give a little slowdown, but nothing too
> big until you start using that particular server.
>
> I run server on many clients, and maintain a local copy of static
> information. This reduces the load on the main server, and gives me a
> speed increase as the network traffic is reduced. Just another way of
> doing things.
time. My application (Accommodation Reservation System) like (I imagine) any
application, has quite a few "static" tables which end users can't (& I
don't want them to) update in any way. When the "Embedded" version of
Firbird was announced, I was hoping that I could use this to access "read
only" tables & access "read/write" tables from a server. This does not seem
to handle my requirement of multiple "instances" of my application running
on the same workstation. Your mention of running multiple servers looks like
it would handle my requirements.
Please correct me if I am making the wrong assumption, but I have
ascertained from the entries in the support n/g that while the "embedded"
version of Firebird allows accessing db's from a server as well as access
to a local DB, only "one" task on the W/s can access the local DB.
It would be really nice if "read only" db's could be accessed from the
client m/c & the dynamic R/W db be accessible from a server! I don't believe
I am an orphan in regard to this requirement as many applications need
access to read only DB's (such as Location, Postal Code lookup, Country Code
lookup [in fact a whole range of "lookup tables"] which if they were located
on client m/c's would eliminate a heck of a lot of network traffic).
Maybe the question I am asking is "if a DB is "read only", can multiple
instances of embedded Firebird access it from a client m/c"? & if not - why
not, because to me that would be an invaluable facility for any application
I can think of! With the horsepower of current client m/c's, I can't see the
overheads you have mentioned being a problem. Lester, I seem to remember you
mentioning using UK Postal code lookup and that DB must be an order of
magnitude larger that Australia's (~14,000 post codes) due to the UK having
PC's down to the street number level (I believe). Even with N/W's going to
the 1 & 10 Gbps range, lookup tables of a large size are a drain on the
server Disk I/O and would be better serviced as you have intimated by local
access thru' a local server.
Ken A Galbraith
PS: When I mentioned r/o & r/w tables above, I am aware that they would need
to be in separate DB's!
> --
> Lester Caine
> -----------------------------
> L.S.Caine Electronic Services