[DUG] Why InterBase

[Edward Huang]

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