[DUG] Why InterBase

[Trevor Jones]

Come on Ed,
  There are about 85 firebird databases that interface with your Teradata
database on a regular basis.

  There is a stored procedure defined in each of those firebird databases
which provides data to the Teradata system.

  The stored procedure provides nothing more than a consistent interface
which, when called, spits out the data that your Teradata system requires in
a format that it can understand.

  I suspect a certain amount of squeaky-wheel syndrome here: the stored
procedure interface provided by the firebird databases is so simple and
reliable that no-one even remembers that it is there.  The only calls I have
ever had about it are to do with the Teradata systems's login not being
available when a machine has been replaced due to hardware failure (and some
support person hasn't done their job properly).

  The structure of the tables which provide the data has changed many times
since the original interface was designed.  The interface hasn't changed at
all.  The original program which links Teradata to firebird has also been
tweaked many times, but with a consistent interface, who cares?

  Isn't that the point of interfaces?  And what better to provide an
interface than a selectable stored procedure?

  I appreciate that a web service could do the same job, but that would
require (at the very least) a web server, and corporate rules precluded
providing one.

  Some other kind of middle-ware could also do the same job, but why bother?
The database is there, it is secure, it is a service, it can be called, and
it provides exactly what is required.

  I've even had arguments with your boss about it.  The SP solution I
suggested was put in place until someone could come up with a better way of
providing the data.  That was several years ago.

  Strangely, the firebird databases also have a (limited) capability to get
live data from your DMSII database.  I know that the DMSII database provides
a trickle-feed to the SQL-Server and Teradata databases, but as far as I am
aware, only the firebird databases can get live data.  And once again, they
use stored procedures (and UDFs) to do it.  Aren't interfaces cool?

  I don't know if I could do all of this stuff with SQL-Server, Oracle,
Postgres or MySQL, but I know that Interbase and Firebird can do it.

  Currently I see nails, and my Firebird hammer is just the right shape and
size.

Trevor

-----Original Message-----
From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz] On
Behalf Of Edward Huang
Sent: Wednesday, 7 June 2006 8:50 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: RE: [DUG] Why InterBase


Well, primarily MS SQL 2000 as front line / satellite databases, and
Teradata as backend data warehouse.
MSSQL is pretty treated as light weighted fast-response application
databases.  Compare to Teradata, MSSQL 2000 is still missing lots of SQL
capabilities, although it's much more powerful than Sybase, Interbase 6 as I
used before.  MSSQL 2005 implemented a few new nice features.  I suppose
that new IB would do the same.  I just don't know where it's up to.

Come back to IB/FB discussion, so far the impression is that they are most
suitable for embedded environment, i.e. database is light weighted, almost
invisible, and SQL capability requirement is not very high, usually
Application layer will handle most of functions.  When it want to compete in
the database server field that Oracle (and MSSQL) are competing, I think
that more SQL capability is required.


> -----Original Message-----
> From: delphi-bounces at ns3.123.co.nz
> [mailto:delphi-bounces at ns3.123.co.nz]On Behalf Of Kyley Harris
> Sent: Tuesday, 6 June 2006 10:30 p.m.
> To: edwardh at bigfoot.com; NZ Borland Developers Group - Delphi List
> Subject: RE: [DUG] Why InterBase
>
>
> What is the warehouse using? Oracle? MSSQL? Have they stayed with only
> one?
>
> -----Original Message-----
> From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz]
> On Behalf Of Edward Huang
> Sent: Tuesday, 6 June 2006 9:45 p.m.
> To: NZ Borland Developers Group - Delphi List
> Subject: RE: [DUG] Why InterBase
>
> Well, we are another group of programmers that put as much of business
> logic
> into database layer (views, user defined functions, SPs, triggers and
> referential integrities) as we can sensibly do.
>
> It's not exactly depends on personal style either, as I was mainly doing
> business logic in application layer only before this.  It just works
> best in
> the environment I'm currently in.  With some logic in database layer,
> many
> times you don't need to change the application layer when you need to
> change
> business logic.  When you need to change your database structure, you
> can
> make it transparent to application layer as well.  It's just make sense
> when
> your data has many values outside of your application.  In this type of
> case, I would think IB/FB just wouldn't quite cut, although I was a fun
> of
> IB before.
>
> It's kind of case by case, in my opinion.
>
> Cheers,
>
> Edward
>
>
> > -----Original Message-----
> > From: delphi-bounces at ns3.123.co.nz
> > [mailto:delphi-bounces at ns3.123.co.nz]On Behalf Of kurt
> > Sent: Thursday, 1 June 2006 10:47 p.m.
> > To: NZ Borland Developers Group - Delphi List
> > Subject: Re: [DUG] Why InterBase
> >
> >
> > Kyley Harris wrote:
> > > I agree. I actually don't put ANY business logic into the database.
> >
> > Urk, disagree.
> > Database is almost pure business logic already
> > (there shall be 3 addresses per client, and one shall be called
> > the contact address).
> > Only reasons for pulling stuff out are SQL's limited expression,
> > micro-managing performance (manipulating all the X's for
> > this Y only), and fitting a different logical structure on top
> > of the data.
> >
> > OTOH, I've not met another programmer that agrees with me yet :)
> >
> > Cheers, Kurt.
> >
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.2/357 - Release Date: 6/06/2006

_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi