Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2008-04

Looking for a Firebird book?

40 messages · 11 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

Anybody know of a Firebird book I can purchase? Language needs to be in English.

I'm looking for something that covers the SQL syntax, DB tuning and importantly, security.

The latter is one major issue I have with Firebird. It's security model is very different to MS SQL Server, and I'm struggling to find information on how I should implement my applications with Firebird security.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Damien Gerard
to Graeme Geldenhuys
Graeme Geldenhuys wrote 12 lines
Hi, Anybody know of a Firebird book I can purchase? Language needs to be in English. I'm looking for something that covers the SQL syntax, DB tuning and importantly, security. The latter is one major issue I have with Firebird. It's security model is very different to MS SQL Server, and I'm struggling to find information on how I should implement my applications with Firebird security.

Does their documentation not suitable to you ?

From MSSQL To Firefird
http://www.firebirdsql.org/manual/migration-mssql.html Books
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_publications

Damien Gerard "Intelligence is 10 million rules." -- Douglas Lenat

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys: Anybody know of a Firebird book I can purchase? Language needs to be in English. I'm…
Graeme Geldenhuys wrote 11 lines
Hi, Anybody know of a Firebird book I can purchase? Language needs to be in English. I'm looking for something that covers the SQL syntax, DB tuning and importantly, security. The latter is one major issue I have with Firebird. It's security model is very different to MS SQL Server, and I'm struggling to find information on how I should implement my applications with Firebird security.

What's wrong with the firebird book by helen borrie ?

http://www.ibphoenix.com/

Michael.

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt
Michael Van Canneyt wrote
What's wrong with the firebird book by helen borrie ? http://www.ibphoenix.com/

I only found their book section now... :-)
Most books are in Portuguese, German (including yours <wink>)... I'm trying to find a Table of Contents for the 'Firebird Book', to see what it covers. I'll google some more. Pity the eBook version is so outdated with a terrible layout (as mentioned on there website). That means I'll have to wait 3-4 weeks for the hard-copy (yes the postal service to South Africa takes forever) as non our our book stores actually have stock of computer books, everything is on order from USA or UK.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Damien Gerard: Does their documentation not suitable to you ? From MSSQL To Firefird…
Damien Gerard wrote 5 lines
Does their documentation not suitable to you ? From MSSQL To Firefird http://www.firebirdsql.org/manual/migration-mssql.html

I did find that, but it doesn't cover security access from applications to Firebird.

eg:
* MSSQL has server access, database access and table access.
* Firebird has roles, which I'm trying to figure out now, but it's still hard to find good information. From what I can see is that if you have a username and password to the firebird server, you can access all connected databases! Weird? Our applications use login the moment we simply hard-code a firebird
username and password in the application to create the connection, then access our own 'users' table to manage access to our application. Is that how everybody else does it with Firebird?

Thanks, I only found that link a little while ago.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys
Graeme Geldenhuys wrote 16 lines
On 09/04/2008, Damien Gerard wrote: > > Does their documentation not suitable to you ? > > From MSSQL To Firefird > http://www.firebirdsql.org/manual/migration-mssql.html I did find that, but it doesn't cover security access from applications to Firebird. eg: * MSSQL has server access, database access and table access. * Firebird has roles, which I'm trying to figure out now, but it's still hard to find good information. From what I can see is that if you have a username and password to the firebird server, you can access all connected databases!

You can access them, i.e. connect to the database, but unless the database owner granted you access to some tables, you can't see anything.

Show quoted text 5 lines
Weird? Our applications use login the moment we simply hard-code a firebird username and password in the application to create the connection, then access our own 'users' table to manage access to our application. Is that how everybody else does it with Firebird?

I do it like that too, because the security model of any RDBM is ridiculous, firebird is no exception.

Security must be specified at a functional level, never at the table level.

I tried once at the table level, and ended up giving everybody access to everything, because it's relational and everyone at some point ended up writing in some table. So I dumped that, and implemented a separate security mechanism that looks at functions - what is a person allowed to do ?

What data he needs to perform these functions is then irrelevant - worse even, it changes over time.

Ever since, I have no more worries over security.

Michael.

Reply by email

Damien Gerard
to Graeme Geldenhuys: I did find that, but it doesn't cover security access from applications to Firebird. eg:…
Graeme Geldenhuys wrote 20 lines
On 09/04/2008, Damien Gerard wrote: > > Does their documentation not suitable to you ? > > From MSSQL To Firefird > http://www.firebirdsql.org/manual/migration-mssql.html I did find that, but it doesn't cover security access from applications to Firebird. eg: * MSSQL has server access, database access and table access. * Firebird has roles, which I'm trying to figure out now, but it's still hard to find good information. From what I can see is that if you have a username and password to the firebird server, you can access all connected databases! Weird? Our applications use login the moment we simply hard-code a firebird username and password in the application to create the connection, then access our own 'users' table to manage access to our application. Is that how everybody else does it with Firebird?

If I remember well (of an old time), each database uses its own file. But it may have changed since.

You should read this :
http://www.firebirdsql.org/manual/qsg2-config.html

and this :

http://www.firebirdfaq.org/cat7/

May be it could help

Show quoted text 17 lines
> Books > http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_publications Thanks, I only found that link a little while ago. Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Damien Gerard "Intelligence is 10 million rules." -- Douglas Lenat

Reply by email

Matt Emson
to Graeme Geldenhuys: Anybody know of a Firebird book I can purchase? Language needs to be in English. I'm…

Graeme Geldenhuys wrote:

Any documentation for Interbase 5.5 or 6.0 should be fairly helpful.

TBH, the way Firebird did security last time I looked, was pretty similar to the way SQL Server does it if you don't use integrated security. Adding users was hell, but adding grants etc was pretty simple.

The bigger issue with Firebird was that it was so unstable (but then, so is Interbase) and required a lot of fiddling to stop it misbehaving (some of which might have been the archaic components and poor code I inherited.) I won't vent my spleen about Interbase/Firebird, except to say: it works really well till you start writing UDF libraries in Pascal. The Free UDF lib is buggy and also there are a number of subtly different versions floating around and no real version control. It has some nice features (Stored Procedures and the "for select ... suspend" mechanism) but I would never use Interbase in production again and would need to see pretty conclusive proof that Firebird had improved greatly. I did read they now have a PL/SQL emulation layer... that sounds really nice.

M

Show quoted text 25 lines
Hi, Anybody know of a Firebird book I can purchase? Language needs to be in English. I'm looking for something that covers the SQL syntax, DB tuning and importantly, security. The latter is one major issue I have with Firebird. It's security model is very different to MS SQL Server, and I'm struggling to find information on how I should implement my applications with Firebird security. Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply by email

Michael Van Canneyt
to Matt Emson
Matt Emson wrote 19 lines
Graeme Geldenhuys wrote: Any documentation for Interbase 5.5 or 6.0 should be fairly helpful. TBH, the way Firebird did security last time I looked, was pretty similar to the way SQL Server does it if you don't use integrated security. Adding users was hell, but adding grants etc was pretty simple. The bigger issue with Firebird was that it was so unstable (but then, so is Interbase) and required a lot of fiddling to stop it misbehaving (some of which might have been the archaic components and poor code I inherited.) I won't vent my spleen about Interbase/Firebird, except to say: it works really well till you start writing UDF libraries in Pascal. The Free UDF lib is buggy and also there are a number of subtly different versions floating around and no real version control. It has some nice features (Stored Procedures and the "for select ... suspend" mechanism) but I would never use Interbase in production again and would need to see pretty conclusive proof that Firebird had improved greatly. I did read they now have a PL/SQL emulation layer... that sounds really nice.

Strange that you say this. We have firebird databases in production at more than a thousand sites, ranging from simple desktop installations to sites with more than 500 simultaneous users. Firebird didn't fail on us once.

I must say that we don't use UDFs at all, except the pretty trivial BIN_AND and BIN_OR.

The only negative thing I can say about Firebird is that it can produce a corrupt backup file.

Michael.

Reply by email

Matt Emson
to Graeme Geldenhuys: I did find that, but it doesn't cover security access from applications to Firebird. eg:…
Graeme Geldenhuys wrote
... At the moment we simply hard-code a firebird username and password in the application to create the connection, then access our own 'users' table to manage access to our application. Is that how everybody else does it with Firebird?

Yes. I've seen that in a number of IB/FB apps. It is fairly common. But, also common to create a non SYSDBA user too for that purpose. Be careful about grants.. if you have two users, IB and FB management tools tend to grant for that specific user by default. If someone logs on as SYSDBA, I've seen mad things where people have made random grants for various users because of this.

The EMS tools are pretty cool. We used to use their manager, forget what it is called now. I did use Marathon for a while, but it was quite buggy and unstable.

Reply by email

Graeme Geldenhuys
to Matt Emson: Any documentation for Interbase 5.5 or 6.0 should be fairly helpful. TBH, the way…
Matt Emson wrote
The bigger issue with Firebird was that it was so unstable (but then, so is Interbase) and required a lot of fiddling to stop it misbehaving

We have not detected any stability issues with Firebird in the last three years that we used it. It's a simply deploy and forget RDMS. Pretty cool.

Then again, the same as what Michael said. We do not use any UDF goes for Store Procedures - but that's our design
choice to be flexible with DB backends if the need arises. Plus business rules belong in the Business Objects where they can be unit tested (but that's a whole other debate). :-)

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: You can access them, i.e. connect to the database, but unless the database owner granted…
Michael Van Canneyt wrote 5 lines
I do it like that too, because the security model of any RDBM is ridiculous, firebird is no exception. Security must be specified at a functional level, never at the table level.

I'm glad we are not the only ones that think like that. :-)

I tried once at the table level, and ended up giving everybody access to everything, because it's relational and everyone at some point ended up writing in some table. So I dumped that, and implemented a separate security mechanism that looks at functions - what is a person allowed to do ?

We are moving over to exactly the same process. Security moves over to the application (or middle-tier) level. Based on the users security level, things like menu items get disabled or hidden.

I'm glad we are heading in the right direction then... ;-)

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Matt Emson: Yes. I've seen that in a number of IB/FB apps. It is fairly common. But, also common to…
Matt Emson wrote
Yes. I've seen that in a number of IB/FB apps. It is fairly common. But,

Excellent!

also common to create a non SYSDBA user too for that purpose. Be careful

Yes, we do not use the SYSDBA account in our applications. Each DB has it's own 'owner' account.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Matt Emson
to Michael Van Canneyt: Strange that you say this. We have firebird databases in production at more than a…
Michael Van Canneyt wrote
Strange that you say this. We have firebird databases in production at more than a thousand sites, ranging from simple desktop installations to sites with more than 500 simultaneous users. Firebird didn't fail on us once.

Interbase 7.1 and 7.5 were very bad. Interbase 6 was poor.

Firebird 1.x was bad. We stopped using Firebird when the compatibility was lost. Like I said, Firebird was bad last time I used it - Interbase was awful in the 2 and a half years I used it. Guilt by association? ;-)

UDF was biggest issue. The database relied heavily on using custom UDF functions, as well as the greater amount of FreeUDFLib. It also tried to do *everything* in stored procs, which is a really bad idea IMHO. A server process would have solved a lot of the instanility, which were caused mostly by implied logical second tier issues due to the design mentioned above.

Reply by email

Codebue Fabio - P-Soft
to Matt Emson

Take a look to a new Firebird 2.1 next month and probably you will change your idea about it...
UDF: FreeAdHocUDF, a lot of internal SQL function... and if you wanna a good book www.ibphoenix.com Helen Borrie book... a MUST!

Codebue Fabio
.-----------------------------.
_ \ __| _||
__/____|\__ \ _ \ _| _|
_| ____/\___/_| \__|

P-Soft di Codebue Fabio & C. sas
via B.Storti, 19
24060 - Chiuduno - BG
Italy
Phone: +39.030.839435
Fax: +39.030.5100306
Mobile: +39.348.3515786
.-----------------------------.
Web : www.p-soft.biz
EMail:

Earlier message 26 lines
-----Original Message----- From: On Behalf Of Matt Emson Sent: Wednesday, April 09, 2008 12:48 PM To: FPC-Pascal users discussions Subject: Re: [fpc-pascal] Looking for a Firebird book? Michael Van Canneyt wrote: > Strange that you say this. We have firebird databases in production at > more than a thousand sites, ranging from simple desktop installations to > sites with more than 500 simultaneous users. Firebird didn't fail on > us once. Interbase 7.1 and 7.5 were very bad. Interbase 6 was poor. Firebird 1.x was bad. We stopped using Firebird when the compatibility was lost. Like I said, Firebird was bad last time I used it - Interbase was awful in the 2 and a half years I used it. Guilt by association? ;-) UDF was biggest issue. The database relied heavily on using custom UDF functions, as well as the greater amount of FreeUDFLib. It also tried to do *everything* in stored procs, which is a really bad idea IMHO. A server process would have solved a lot of the instanility, which were caused mostly by implied logical second tier issues due to the design mentioned above.

Reply by email

Matt Emson
to Marco van de Voort: IIRC Mass insertion could bring down the db (slow to an effective DOS to other users)…
Marco van de Voort wrote 8 lines
> On Wed, 9 Apr 2008, Matt Emson wrote: > > The only negative thing I can say about Firebird is that it can produce > a corrupt backup file. > IIRC Mass insertion could bring down the db (slow to an effective DOS to other users) unless you commit the transaction every 10000 items or so.

Yep, we definitely saw that. We ended up going a little insane with committing transaction (bad original design relied on keeping transactions open slightly too often.) Even so, the Delphi controls we used (Delphi 5, whatever the latest IBExpress Borland shipped) were appalingly buggy wrt transactional stuff. I always liked the other ones, IBObjects, personally - even if they were quite odd. IBExpress could not handle the server disconnecting - totally unrecoverable. IBO did handle it quite well.

M

Reply by email

Graeme Geldenhuys
Damien Gerard wrote
However needs are not the same so I wanted to know when it would be a good choice to use Firebird if someone asks me.

Considering we are still using MS Access (1) which currently handles 20-40 connections - any upgrade to a 'real' database server is a big plus for us developers! :-)

Easy deployment and low maintenances is huge in our case. We deploy in franchises where we still need to explain to them when to left click or right click the mouse. :-(

Regards,
- Graeme -

(1): until the next release of our product which is Q3 this year

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Tom York
to Codebue Fabio - P-Soft: Take a look to a new Firebird 2.1 next month and probably you will change your idea about…
Codebue Fabio - P-Soft wrote 7 lines
Take a look to a new Firebird 2.1 next month and probably you will change your idea about it... UDF: FreeAdHocUDF, a lot of internal SQL function... and if you wanna a good book www.ibphoenix.com Helen Borrie book... a MUST!

Will 2.1 have a true auto increment attribute? A boolean field perhaps? Those are the only things that I miss when using FB. I am aware that all of these issues can be resolved by using generators/triggers and a validating domain. That is what I like about MySQL, MSSQL and others that are missing from FB.

Do not misunderstand though. I've used FB for 8+ years with great success in embedded, small and large transactional systems without flaw. Never had a corrupt DB. AFAIK, never had a corrupt backup. Most of the time, I deploy FB on Linux servers and backup using gbak.

Tom

Reply by email

Joost van der Sluis
to Graeme Geldenhuys: Anybody know of a Firebird book I can purchase? Language needs to be in English. I'm…

Op woensdag 09-04-2008 om 09:02 uur [tijdzone +0200], schreef Graeme Geldenhuys:

Show quoted text 11 lines
Hi, Anybody know of a Firebird book I can purchase? Language needs to be in English. I'm looking for something that covers the SQL syntax, DB tuning and importantly, security. The latter is one major issue I have with Firebird. It's security model is very different to MS SQL Server, and I'm struggling to find information on how I should implement my applications with Firebird security.

I have this book: http://ibexpert.biz/ibe/index.php?n=Main.IBExpertBook

And when I bought it I had two options: printed or PDF. So prabably that's suefull for you too if you don't trust the postmen

It's based on IBExpert but also contains a full sql-manual.

Joost

Reply by email

Inoussa OUEDRAOGO
to Michael Van Canneyt: You can access them, i.e. connect to the database, but unless the database owner granted…

2008/4/9, Michael Van Canneyt :

I do it like that too, because the security model of any RDBM is ridiculous, firebird is no exception. Security must be specified at a functional level, never at the table level.

Absolutely. And security model at the RDBM level prevents connection pooling in a multi tiers
solution. The common use of the security model at the RDBM level is for readonly users
in web applications. Even in this case, only one such user is defined at the RDBMS, in
order to be able to use connection pooling.

Inoussa O.

Reply by email

Michael Van Canneyt
to Marco van de Voort: IIRC Mass insertion could bring down the db (slow to an effective DOS to other users)…
Marco van de Voort wrote 7 lines
> On Wed, 9 Apr 2008, Matt Emson wrote: > > The only negative thing I can say about Firebird is that it can produce > a corrupt backup file. IIRC Mass insertion could bring down the db (slow to an effective DOS to other users) unless you commit the transaction every 10000 items or so.

Not in my experience: over 600.000 records inserted in 1 transaction. Maybe with interbase this was so ?

Michael.

Reply by email

Matt Emson
to Michael Van Canneyt
Michael Van Canneyt wrote 10 lines
On Wed, 9 Apr 2008, Marco van de Voort wrote: > IIRC Mass insertion could bring down the db (slow to an effective DOS to > other users) unless you commit the transaction every 10000 items or so. > Not in my experience: over 600.000 records inserted in 1 transaction. Maybe with interbase this was so ?

If you bring a UDF in to the equation, it will happen. Easily.

Reply by email

Michael Van Canneyt
to Matt Emson
Matt Emson wrote 13 lines
Michael Van Canneyt wrote: > On Wed, 9 Apr 2008, Marco van de Voort wrote: > > > > IIRC Mass insertion could bring down the db (slow to an effective DOS to > > other users) unless you commit the transaction every 10000 items or so. > > > > Not in my experience: over 600.000 records inserted in 1 transaction. > Maybe with interbase this was so ? > If you bring a UDF in to the equation, it will happen. Easily.

That could be. I don't use them.
My point of view is that a database is for storage, not for logic...

Michael.

Reply by email

Bee
to Michael Van Canneyt
My point of view is that a database is for storage, not for logic...

I used to think that way too. But, based on my personal experience, in certain conditions and requirements, implementing logic in database is inevitable. That's why many databases support server side logic though it's implemented in various ways (UDF, SP, SF, etc).

But I also agree that we shouldn't use this mechanism at all time. Each decision and choice has its own consequences. ;)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: That could be. I don't use them. My point of view is that a database is for storage, not…
Michael Van Canneyt wrote
My point of view is that a database is for storage, not for logic...

A very logical assumption. ;-) And one I fully agree with. Use the correct tool for the job, hence the reason we don't use stored procedures either.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Bee: I used to think that way too. But, based on my personal experience, in certain conditions…
Bee wrote 8 lines
I used to think that way too. But, based on my personal experience, in certain conditions and requirements, implementing logic in database is inevitable. That's why many databases support server side logic though it's implemented in various ways (UDF, SP, SF, etc). But I also agree that we shouldn't use this mechanism at all time. Each decision and choice has its own consequences. ;)

The reason we stopped using stored procs..... The speads business rules across layers.... Business rules do no belong in the storage layer - the same reason business logic does not belong in Forms (gui layer). If they are mixed like that, you cannot write unit tests for them and makes it very hard to debug business rules!

But as I said in a earlier post, that's a whole other discussion, and I have no interest in starting a flame war. :)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Inoussa OUEDRAOGO
to Graeme Geldenhuys

Hi,

2008/4/9, Graeme Geldenhuys :

Show quoted text 16 lines
On 09/04/2008, Bee wrote: > > I used to think that way too. But, based on my personal experience, in > certain conditions and requirements, implementing logic in database is > inevitable. That's why many databases support server side logic though it's > implemented in various ways (UDF, SP, SF, etc). > > But I also agree that we shouldn't use this mechanism at all time. Each > decision and choice has its own consequences. ;) The reason we stopped using stored procs..... The speads business rules across layers.... Business rules do no belong in the storage layer - the same reason business logic does not belong in Forms (gui layer). If they are mixed like that, you cannot write unit tests for them and makes it very hard to debug business rules!

Why couldn't SP be unit tested ? I did it myself numerous time. Tests do not have to be
written in Object Pascal.

But as I said in a earlier post, that's a whole other discussion, and I have no interest in starting a flame war. :)

Stored procedures have their uses, they should not be abused as OOP should not be abused. Making the business rules in the middle layer is a good point, but it should not be done at any price; I saw some code where data are selected and sorted on the middle layer because of _this_ rule and make the application _very slow_ and consume too much memory (it could has
been done very efficiently with a few sql commands in a SP). I do think thatevery method, technic must remain a mean, not a goal.

Thanks.

Inoussa O.

Reply by email

afpTeam
to Graeme Geldenhuys: A very logical assumption. ;-) And one I fully agree with. Use the correct tool for the…
Show quoted text 10 lines
>On 09/04/2008, Michael Van Canneyt wrote: > My point of view is that a database is for storage, not for logic... From: "Graeme Geldenhuys Wednesday, April 09, 2008 3:35 PM A very logical assumption. ;-) And one I fully agree with. Use the correct tool for the job, hence the reason we don't use stored procedures either. Regards, - Graeme -

Actually a hard-drive or other durable memory is for storage. A database is for "efficient" organization of data to aid efficient utilization

In most cases aggregation of that data is part of efficient utilization.

Aggregation of related data and several other math intensive ops inside the DB engine (i.e. stored procs), will boost net performance VERY substantially, when deployed in a properly cached and threaded environment. Banks, Brokerages, Real Time Inventory managers, large store operations all depend on these operations to be as efficiently as possible.

It comes down to knowing when, how and where to separate business layers of integrated procedures relative to specific data sets so business logic that is related is not in conflict with properly designed DB integration of procs. But for the most general applications of DB's which do not rely on mission critical performance, knowing how to apply DB internal procs and functions is essential to large volume processing, timely. Otherwise, for general purpose operation, DB's are simply a convenience over a mess of flat files, so the question of procs is moot in these less demanding cases.

It doesn't mean Procs or Funcs don't belong in a DB, but that the need is "application specific", especially where clock cycles and turn-around time are critical.

Right tool for the right job. As much as ADO tried to benefit this idea and basically broke the whole concept. ;)

Mike

Reply by email

Matt Emson
to Michael Van Canneyt: That could be. I don't use them. My point of view is that a database is for storage, not…
Michael Van Canneyt wrote 22 lines
On Wed, 9 Apr 2008, Matt Emson wrote: > Michael Van Canneyt wrote: > >> On Wed, 9 Apr 2008, Marco van de Voort wrote: >> >> >> >>> IIRC Mass insertion could bring down the db (slow to an effective DOS to >>> other users) unless you commit the transaction every 10000 items or so. >>> >>> >> Not in my experience: over 600.000 records inserted in 1 transaction. >> Maybe with interbase this was so ? >> >> > If you bring a UDF in to the equation, it will happen. Easily. > That could be. I don't use them.

With the InterBase model, good move.

My point of view is that a database is for storage, not for logic...

Ah, this is basic use of resources. The benefit of Stored Procs is speed of execution. You are thinking in BDE terms - database stores data, I retrieve data, I manipulate/display data, I write changes and new data to database. This model works well until performance is essential. In an inherently single threaded framework (such as the VCL and most other libraries with a GUI), database access is costly. Using Stored Procs to do data selection, manipulation and insertion/updating hands that task to the database engine. In an RDBMS, this is extremely beneficial to the client code. The server needs to be beefier, but the GUI client machines can be Pentium 100MHz machines. Using the BDE style of database access (thinking Paradox and DBase here) you need to do all processing on the client, or at least in a process distinct from the data storage layer. I've worked on a system that used a home grown BTree based filing system instead of a database and it's much the same. Writing a server process to sit in the middle of your clients and load balance the database access is a magnitude more dificult than using the database systems in built load balancing mechanisms.

Try this:

Test 1: Create a database, add two identically structured tables. Write a stored proc to insert in to, update and select the contents of table
1. Write a client app that runs timed operations to add 10,000,000 records in to each table and then read them back. (use your imagination, either all in one go or mixed mode.) I promise you, the stored proc version will be faster, because the engine will cache the compiled stored proc.

Test 2: Add a second table that controls table 1 and 2. This has 2 columns, like an enumeration. The UID points to a value that dictates the use of the data in Tables 1 and 2. Now write code that only returns a subset of the tables given the rules in table 3. This can be as simple as an exclusion (e.g. Table 3 contains 4 rows, 1, 1 : 2, 0 : 3, 1: 4, 0) where table 1 and 2 join table 1 and the second column is used to determine inclusion (boolean logic) so that a column in table 1 or 2 must match the joined columns value. In the stored proc version, this is a simple "select" operation on he client. In the other version, the logic now sits more heavily on the client.

You could go on like this. The more complex the look up in, the more strain the client process is put under (or middle tier.) In the RDBMS version, the load is balanced because the database engine is explicitly designed to handle this model.

I'm not trying to preach to you, as your position is one of taste, but the logic you use is not as sound as you imply.

M

Reply by email

Marco van de Voort
to Matt Emson
Show quoted text 6 lines
Michael Van Canneyt wrote: > My point of view is that a database is for storage, not for logic... Ah, this is basic use of resources. The benefit of Stored Procs is speed of execution.

For dialy routines, only if they are not complex, and significantly reduce the amount of data transfered tuples (the result set), and it can not be expressed in a query.

With complex I mean is that if the stored proc needs to use temp tables or other state that consists out of a set of tuples, then it is usually slower.

Oh, and CPU is cheap compared to DB licenses nowadays.

Reply by email

Matt Emson
to Marco van de Voort
Marco van de Voort wrote 12 lines
> Michael Van Canneyt wrote: > > >> My point of view is that a database is for storage, not for logic... >> > Ah, this is basic use of resources. The benefit of Stored Procs is speed > of execution. > For dialy routines, only if they are not complex, and significantly reduce the amount of data transfered tuples (the result set), and it can not be expressed in a query.

I don't doubt what you are saying, but in my experience, this is not the case. It really depends on the client and underlying protocol used to access the RDBMS. In a local database system, yeah, probably. In a RDMBS, no.

With complex I mean is that if the stored proc needs to use temp tables or other state that consists out of a set of tuples, then it is usually slower.

Again, not true in my experience. Writing the same code on the client that manipulates data from multiple tables and uses the resulting dataset is a lot slower. Using Interbase/Firebird, you can create stored procs that return datasets in a ad hoc fashion (multithreaded) or bulk. Something like:

create proc test ()
returns (a int, b int, c int, d int, e int)
for select a, b, c, d
from TZ
into :a, :b, :c, :d do
begin
  e = 0;
  if (b in [1, 2, 5, 200]) then
  begin
    e = 22;
    suspend;
  end
  else if (c = 250) and (b < 5) then
  begin
    e = 25;
    suspend;
  end
  else if (a > 250) and (b = 5) then
  begin
    e = 8;
    suspend;
  end
  else if (d = -1) then exit;
end

(forgive my syntax mistakes above, not done any Interbase for over a year.)

is far better than (pseudo code)

var
  table : table_class;
begin
  ...(some construction or whatever)
  table.execsql("select * from TZ")
   while (not table.Eof) do
   begin
     a := table.fieldbyname('a').AsInteger;
     b := table.fieldbyname('b').AsInteger;
     c := table.fieldbyname('c').AsInteger;
     d := table.fieldbyname('d').AsInteger;
     e = 0;
  if (b in [1, 2, 5, 200]) then
  begin
    e = 22;
    suspend;
  end
  else if (c = 250) and (b < 5) then
  begin
    e = 25;
    suspend;
  end
  else if (a > 250) and (b = 5) then
  begin
    e = 8;
    suspend;
  end
  else if (d = -1) then exit;
end
   end;
end;
Oh, and CPU is cheap compared to DB licenses nowadays.

Aha, the Microsoft defense! ;-) Chewbaka was a Wookie, don't you know? ;-)

Reply by email

Michael Van Canneyt
to Matt Emson: With the InterBase model, good move. Ah, this is basic use of resources. The benefit of…
Matt Emson wrote
I'm not trying to preach to you, as your position is one of taste, but the logic you use is not as sound as you imply.

No need to convince me :-)

You are correct, and we do use stored procs in a few simple cases where speed is essential. But these are the exceptions to the rule. We have 350 tables, well over 3000 queries and about 10 stored procs; So we stay true to our credo, but are not blind to reality :-)

Michael.

Reply by email

Marco van de Voort
to Matt Emson: I don't doubt what you are saying, but in my experience, this is not the case. It really…
Show quoted text 8 lines
Marco van de Voort wrote: > For dialy routines, only if they are not complex, and significantly reduce the amount of data > transfered tuples (the result set), and it can not be expressed in a query. > I don't doubt what you are saying, but in my experience, this is not the case. It really depends on the client and underlying protocol used to access the RDBMS. In a local database system, yeah, probably. In a RDMBS, no.

In my case, the middle tier was on a different machine than the (SQL Server) db.

Show quoted text 5 lines
Again, not true in my experience. Writing the same code on the client that manipulates data from multiple tables and uses the resulting dataset is a lot slower. Using Interbase/Firebird, you can create stored procs that return datasets in a ad hoc fashion (multithreaded) or bulk. Something like:

You example is prefectly covered by my exceptions, (it compares a case where the stored procedure reduces the number of tuples returned).

In (at least my) practice however, cases like this that can't be expressed in SQL (or at least that the first or second magnitudes of data reduction are done) are relatively rare.

> Oh, and CPU is cheap compared to DB licenses nowadays. Aha, the Microsoft defense! ;-) Chewbaka was a Wookie, don't you know? ;-)

I saw him whine yesterday in the Empire Strikes Back yes. And he was as realistic as buying P-I client machines nowadays.

Reply by email

Matt Emson
to Marco van de Voort
Marco van de Voort wrote 9 lines
>> Oh, and CPU is cheap compared to DB licenses nowadays. > > Aha, the Microsoft defense! ;-) Chewbaka was a Wookie, don't you > know? ;-) I saw him whine yesterday in the Empire Strikes Back yes. And he was as realistic as buying P-I client machines nowadays.

Geode, or the VIA processor line.

Reply by email

Michael Van Canneyt
to Tom York: On Wed, Apr 9, 2008 at 5:53 AM, Codebue Fabio - P-Soft Will 2.1 have a true auto…
Tom York wrote 15 lines
On Wed, Apr 9, 2008 at 5:53 AM, Codebue Fabio - P-Soft wrote: > Take a look to a new Firebird 2.1 next month and probably you will change > your idea about it... > UDF: FreeAdHocUDF, a lot of internal SQL function... > and if you wanna a good book www.ibphoenix.com Helen Borrie book... a > MUST! > > Will 2.1 have a true auto increment attribute? A boolean field perhaps? Those are the only things that I miss when using FB. I am aware that all of these issues can be resolved by using generators/triggers and a validating domain. That is what I like about MySQL, MSSQL and others that are missing from FB.

And it is exactly why I can't use MySQL, MSSQL: they don't have sequences or generators. I need the ID BEFORE I insert the record, not after.

So: Each his taste :-)

Michael.

Reply by email

Matt Emson
to Michael Van Canneyt
Michael Van Canneyt wrote
And it is exactly why I can't use MySQL, MSSQL: they don't have sequences or generators. I need the ID BEFORE I insert the record, not after.

YES!! This is also missing from SQL Server... or at least, using a GUID is complete overkill. The mechanisms SQL Server has for retrieving the last interted identity value are completely unsane too. Yes, they do work, but things get tricky in real world situations. I have no idea how anyone wrote reliable code to insert a record and retern the IDENTITY value prior to SQL Server 2005.

OT: does anyone know of a reliable generator style "atomic" robust multi user friendly auto IDENTITY generation mechanism for SQL Server? I'd love to be able to define one, but I don't think I have seen one yet that *really* works well.

So: Each his taste :-

Generators and "For select .. into .. suspend" are the features I really miss from Interbase/Firebird.

M

Reply by email

Inoussa OUEDRAOGO
to Matt Emson

2008/4/11, Matt Emson :

Show quoted text 19 lines
Michael Van Canneyt wrote: > And it is exactly why I can't use MySQL, MSSQL: they don't have sequences or > generators. I need the ID BEFORE I insert the record, not after. > > YES!! This is also missing from SQL Server... or at least, using a GUID is complete overkill. The mechanisms SQL Server has for retrieving the last interted identity value are completely unsane too. Yes, they do work, but things get tricky in real world situations. I have no idea how anyone wrote reliable code to insert a record and retern the IDENTITY value prior to SQL Server 2005. OT: does anyone know of a reliable generator style "atomic" robust multi user friendly auto IDENTITY generation mechanism for SQL Server? I'd love to be able to define one, but I don't think I have seen one yet that *really* works well.

Have you try SCOPE_IDENTITY() ? Available at least since SQL SERVER 2000. I have used it with success.

from MSDN :
<quote>
Returns the last identity value inserted into an identity column in the same scope. A scope is a module: a stored procedure, trigger, function, or batch. Therefore, two statements are in the same scope if they are in the same stored procedure, function, or batch. </quote>

Interesting article ( 10 Things You Shouldn't Do with SQL Server ) : http://www.sqljunkies.ddj.com/Article/92CC4817-604D-4344-8BE0-4490F8ED24B6.scuk

Inoussa O.

Reply by email

Matt Emson
to Inoussa OUEDRAOGO
Inoussa OUEDRAOGO wrote
Have you try SCOPE_IDENTITY() ? Available at least since SQL SERVER 2000. I have used it with success.

Well, yeah. But it's not perfect. I want generators, as in:

create generator an_atomic_counter;
set an_atomic_counter = 1 /*or something like that*/
....
declare variable next_atomic_value int
begin
  next_atomic_value = gen_id(an_atomic_counter, 1);
end

next_atomic_is is alway a unique incremental id, and is *not* tied to a specific table. It's not so much the ability to generate a unique id, it's the "use auto inc IDENTITY fields or be damned" attitude that Sql Server has. The only other option is a GUID. Microsoft's insane "SET IDENTITY_INSERT ON|OFF" is also dangerous. Have you ever tried to migrate data between to databases using Sql Server? Nightmare!

Show quoted text 12 lines
from MSDN : <quote> Returns the last identity value inserted into an identity column in the same scope. A scope is a module: a stored procedure, trigger, function, or batch. Therefore, two statements are in the same scope if they are in the same stored procedure, function, or batch. </quote> Interesting article ( 10 Things You Shouldn't Do with SQL Server ) : http://www.sqljunkies.ddj.com/Article/92CC4817-604D-4344-8BE0-4490F8ED24B6.scuk

Reply by email