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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Kyley Harris > Sent: Tuesday, 6 June 2006 10:30 p.m. > To: [EMAIL PROTECTED]; 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] 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 [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi
