On Tue, Dec 16, 2003 at 12:01:55PM +0700, David Garamond wrote: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
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 filesFirebird 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.
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
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
