> 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?
I fully agree with the part about performance and the number of
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL