Jeremy Zawodny wrote:
>On Tue, Dec 16, 2003 at 12:01:55PM +0700, David Garamond wrote:
>
>
>>Sven K?hler wrote:
>>
>>
>>>I was very disappointed by Interbase/Firebird. It seemed to me like a
>>>MS-Access: a database-engine that works on regular files
>>>
>>>
>>Firebird seems simple, but it doesn't mean it's inferior or
>>[intentionally] crippled like MS-Access. SQL server also works on
>>"regular files" (db is stored as single files) and I believe FB is
>>comparable to SQL server.
>>
>>In fact, I personally hate the fact that InnoDB can't work on "regular
>>files" (db is not stored on single files or single directories).
>>
>>
>
>That's already fixed in 4.1.1.
>
>
Looking at the facts, the number of files used to store your data is of
very little consequence at the end of the day. Looking
at the following:
* MS SQL Server stores database data in a single file and logs in another.
* Oracle and FoxPro both have a pretty large number of files, for very
different reasons
* MySQL stores MyISAM each table in a few files: FRM for the schema,
MYD for data and MYI for the index
* FileMaker Pro stores each table along with a bunch of interface stuff
in a single file
* SQLBase (popular in the contract / "closed market" segment) has a
single file unless you tell it to partition the database. This
single file stores tables, stored procedures, views, triggers, indexes
and all transaction logs
* MySQL requires 3 types of file for InnoDB storage in 3.23.x and 4.x -
ibdata*, ib_arch_log_* and iblogfile*, in 4.1.1 and higher
you can go to 4 files with individual table spaces
The last point is particularly worthy of note. The new option in 4.1.1
and higher has implications for performance - you can have your
InnoDB data dictionary (ibdata*), logs and individual table/index spaces
on physically seperate devices. Backing things up becomes
more complicated though.
To be honest, the vast majority of database installations experience
problems in performance caused by poor query and schema design,
bad application logic or grossly underspecified hardware. A change in
the number of files used to store the data is extremely unlikely
to resolve these problems given all other variables in the environment
remain fixed.
What does everyone else think?
Regards,
Chris
