| Subject | Re: [firebird-support] Firebird file questions |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2011-01-25T22:15:01Z |
On 1/25/2011 4:52 PM, tseyfarth wrote:
disks got enormous, when it was possible that a database would
exceed the disk capacity, people created secondary files - it's
still possible - but the second (and subsequent files) were just
extensions of the original file. There's no placement control.
The single file architecture is deliberate and reflects some
behaviors of Firebird and attitudes of its designers.
First, it simplifies system management and allows the database to
be moved within a system or across systems with similar processor
architectures by copying a single file. The addition of configuration
files and user defined function libraries complicates that a bit,
but its still very simple to move a database on a single system.
Second, early on, the designers decided that striping and similar
schemes to reduce disk contention belonged with the disk system not
the database. Database administrators have plenty to worry about
without figuring out where the disk blocks of their database live.
Third, a major reason for placement control is to avoid moving
back and forth between the index and the data on indexed queries.
Firebird finds all the index matches first, then reads the records
in storage order, so there is not back and forth between index
and data in the general case. In the specific case of a "LIMIT"
(also called FIRST) query with an order clause that matches an
index, Firebird will read the data in index order.
Back in the ancient days, some operating systems (e.g. Solaris)
had very low limits on the number of files that could be opened
at once. Having a single file database reduced the suffering
on those systems.
One drawback of this approach is that the database size cannot
be reduced without backing up and restoring the whole database.
On the other hand, it's hard to make a living by saving disk
space giving the current cost of storage. Firebird does reuse
space internally, so the need for cleanup is less than in some
of the databases you've used.
Good luck,
Ann
> Hello all.All flavors of Firebird create a single database file. Before
>
> I am a new user to Firebird and to this forum. I noticed with FB, there is only a single file created with the extension .FDB
>
> In other SQL relational DB's I've used (mySQL, Postgre, Pervasive/Btrieve) there is always a file for each table.
>
> Am I using the correct flavor of FB?
>
disks got enormous, when it was possible that a database would
exceed the disk capacity, people created secondary files - it's
still possible - but the second (and subsequent files) were just
extensions of the original file. There's no placement control.
The single file architecture is deliberate and reflects some
behaviors of Firebird and attitudes of its designers.
First, it simplifies system management and allows the database to
be moved within a system or across systems with similar processor
architectures by copying a single file. The addition of configuration
files and user defined function libraries complicates that a bit,
but its still very simple to move a database on a single system.
Second, early on, the designers decided that striping and similar
schemes to reduce disk contention belonged with the disk system not
the database. Database administrators have plenty to worry about
without figuring out where the disk blocks of their database live.
Third, a major reason for placement control is to avoid moving
back and forth between the index and the data on indexed queries.
Firebird finds all the index matches first, then reads the records
in storage order, so there is not back and forth between index
and data in the general case. In the specific case of a "LIMIT"
(also called FIRST) query with an order clause that matches an
index, Firebird will read the data in index order.
Back in the ancient days, some operating systems (e.g. Solaris)
had very low limits on the number of files that could be opened
at once. Having a single file database reduced the suffering
on those systems.
One drawback of this approach is that the database size cannot
be reduced without backing up and restoring the whole database.
On the other hand, it's hard to make a living by saving disk
space giving the current cost of storage. Firebird does reuse
space internally, so the need for cleanup is less than in some
of the databases you've used.
Good luck,
Ann