In-house or not, your data *is* your business. And the time factor is not
that bad, and in most cases it is faster because you can create generic,
reusable data services. The ease of deployment *alone* is enough to at
least give it proper analysis. DCOM, although clunky, is very well suited
for this kind of work if you are already running a SMB (windows) network.
Set Client = CreateObject("DBServices.Client", APPSERVER1) 'DCOM call
With Client.GetBySocial(SSN)MsgBox .FirstName & " " & .LastName
End With
Set Client = Nothing
This is an over simplified example, but you can see the end result...
Joel
-----Original Message-----
From: Adam Lang [mailto:aalang@rutgersinsurance.com]
Sent: Thursday, November 02, 2000 2:57 PM
To: pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] Connecting remotely - multi tier
But if you are an inhouse developer and the database is only in huse and the
client is only in house and the database is not open to the public, do you
still have to use development time to build that "middle tier" just so you
can roll out an app that uses the company database?
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Greg Speegle" <Greg@10happythings.com>
To: <pgsql-interfaces@postgresql.org>
Sent: Thursday, November 02, 2000 2:42 PM
Subject: Re: [INTERFACES] Connecting remotely - multi tier
>
>
> keke abe wrote:
>
> > Adam Lang wrote:
> >
> > > Ok... so if I am writing a distributed application in windows that
will use
> > > a Postgresql backend, I should have the client interface another
"server"
> > > application, which will inturn access/retrieve informaton from the
database?
> >
> > I'd like to know if this kind of layering is mandatory or not. Is it
really
> > unacceptable to expose the Posgresql backend to the rest of the world?
Is
> > there anything that I should be aware of if I let the clients to talk to
> > the backend directly.
> >
> > regards,
> > abe
>
> I'd say it is mandatory. You are opening yourself up as an easy target for
> hackers if they can go directly to your database. Think about it. If any
> hole in the database security is discovered, then your goose is cooked
> right away. Getting the database off the web and behind a firewall should
> be the least you do. That gives you two levels of protection -- the
firewall
> and the database.
>
> Plus, on the postgresql side, it is much easier to have one restricted
user
> account from one specific machine than to try to manage thousands of
> dynamically created accounts.
>
> Just my opinion, of course.
>
> Greg Speegle
>
