> 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 files. :-) With regards, Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL Server. Upscene Productions http://www.upscene.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
