Subject | Re: optimizing query |
---|---|
Author | Svein Erling |
Post date | 2003-09-25T08:59:44Z |
Hi David, doesn't look like my answer yesterday made it to the list, so I'll answer again.
Firebird is vastly different from any desktop database you may ever have used. Desktop databases generally store things in a particular order and displaying entire tables (normally quite small) or counting records is no big deal.
Unlike desktop databases, Firebird is designed for multiple concurrent users and then things get more complicated. From other messages I see that you are about to learn about transactions, a fundamental part of Firebird. They make concurrent updating safe (once understood), but are also the reason for counting being expensive in Firebird since every record has to be examined to check whether this particular record is visible to the transaction.
Why transferring only a small number of records? Well, why would you need lots of records to be transferred? For batch processing - fine, but online people can only grasp a limited amount of information at any one time, and Firebird is better at selecting amongst its data than any user can possibly be. Firebird is not too pecky about size of the database - if you define your indexes properly (i.e. index fields for which a typical search will be unique or contain only a few duplicate records) your database may contain gigabytes of data with little problem, but transferring lots of records will appear slow for any user who is used to Access or Paradox displaying their "big" table in a couple of seconds.
As for Helens book, the main expert herself is monitoring this list and may answer this far better than I could possibly do.
Set
Firebird is vastly different from any desktop database you may ever have used. Desktop databases generally store things in a particular order and displaying entire tables (normally quite small) or counting records is no big deal.
Unlike desktop databases, Firebird is designed for multiple concurrent users and then things get more complicated. From other messages I see that you are about to learn about transactions, a fundamental part of Firebird. They make concurrent updating safe (once understood), but are also the reason for counting being expensive in Firebird since every record has to be examined to check whether this particular record is visible to the transaction.
Why transferring only a small number of records? Well, why would you need lots of records to be transferred? For batch processing - fine, but online people can only grasp a limited amount of information at any one time, and Firebird is better at selecting amongst its data than any user can possibly be. Firebird is not too pecky about size of the database - if you define your indexes properly (i.e. index fields for which a typical search will be unique or contain only a few duplicate records) your database may contain gigabytes of data with little problem, but transferring lots of records will appear slow for any user who is used to Access or Paradox displaying their "big" table in a couple of seconds.
As for Helens book, the main expert herself is monitoring this list and may answer this far better than I could possibly do.
Set
--- In firebird-support@yahoogroups.com, David Hay wrote:
> Hi Set,
>
> Would you mind elaborating on the following paragraph below:
>
> > If you come from a desktop database background, one big change is
> > that client/server databases encourage selecting only a few
> > records rather than a large number of records. It may not sound
> > like a big difference, but until you start doing this Firebird
> > will feel like a big, slow mastodont of a database, whereas the
> > real problem is more the way you use it (like pigeons are
> > suitable for carrying small messages, not the 700 pages Firebird
> > book that Helen is writing).
>
> I'm new to Firebird and trying to get my head around it.
>
> Many thanks,
>
> David
>
> PS Do you know when Helen's book is due out?