Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Loosing one table [one data file] is less affecting than 10. My view is that MySQL is good because it uses different data files. If one data file gets corrupt, you will loose less information since it is only one table [meaning one data file] that is affected. I am not an expert though!! Just an Idea. Thanks Emery - Original Message - From: Martijn Tonies [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 16, 2003 10:07 Subject: Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ? 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] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Loosing one table [one data file] is less affecting than 10. My view is that MySQL is good because it uses different data files. If one data file gets corrupt, you will loose less information since it is only one table [meaning one data file] that is affected. I am not an expert though!! Just an Idea. If you're loosing files, you have a different problem :-) 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]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Hi Mike, I've asked this question a year ago on the Borland forums but didn't get any replies. Do you know of any websites (non-programming related) that are using Interbase/Firebird for their primary webserver database? I don't mean programmer hangouts like www.mers.com or www.tamaracka.com etc., but Fortune 1000 companies who are using IB/FB on the web to serve up web pages? It would be interesting to get a list of who's using it online. TIA I have no idea :-) ... With a chat I recently had with someone from Opera Software, he told me that they recently migrated their entire my.opera.com to Firebird, but that's the only one I can come up with right now. 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]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Hi, Jerry, Interbase/Firebird looks good on paper. But there are a couple of things to watch out for. 1) Check the Borland Interbase newsgroups for corruption to see if it is still an issue. I know from reading their newsgroups a few years back , there were quite a few postings. It could of been due to inadequate hardware or some external source like a misconfigured server or power failure. There are many sites that use IB without such problems but it is worth checking it out (especially how to successfully repair a damaged IB/FB database because all the tables are stored in one file). Most of these problems have been fixed in Firebird. 2) Speed problems. I don't know how much data your tables will have, but IB/FB has a habit of slowing down as more rows are added/deleted. Really? Howcome there are many people using Firebird without speed problems? It depends on the size of the tables. WIth 50k rows you're not going to notice it. With 50 million rows the slow down becomes apparent. Then what are you doing? Summing all rows? Counting them? (Cause a count is slow in InterBase/Firebird). Indexed searches etc should be nearly as fast as with 50K rows. They have an automated Sweep process that cleans out the updated/deleted rows (deleted updated rows still take up space until the database is swept). Even so a large db will still slow down. I suspect the problem is due to unbalanced indexes. The only way to fix it is to unload all your data and reload it back in. Some people do it once a week. That's not true. The sweep process doesn't kick in until there's actually a problem with long running transactions and new transactions. Updated and deleted rows will remain in the table until a sweep is done. If 100,000 rows are updated, then the old rows will remain in the table and the sweep cleans them out. A heavily updated table will need to be swept often. When sweeps fail to speed up the table, the data has to be unloaded and reloaded. That's not something you want to do very often if you want to have a 24/7 installation especially with millions of rows. There are plenty of systems running or almost running 24/7 without an unload/reload. The sweep process is different from the garbage collection process, which is what you are describing. Perhaps that's where I got confused when you started about sweeping. The GC process has been improved in the recent years in Firebrid and in IB 7 as well. Also, you cannot sweep a table: if you want to sweep, you will sweep the entire database. 3) The server CPU load will increase rapidly after the first 5 or 6 users. In other words IB/FB requires a much faster CPU than the same number of users for MySQL. It is a very CPU intensive DB server. Most CPU problems are related to the above mentioned problems. This isn't usually the case. IB/Fb is actually more of a disk-intensive database engine, because of the ability to use very little memory. However, Firebird has some new stuff (and IB does too) that allows it to use more memory when available (and allowed) making it even faster. IB eats up a lot of memory on large queries, something that should be avoided if at all possible. All queries are fetched into memory, and when physical memory is exhausted, IB will use the page file (in Windows) and swaps the physical memory out to disk. This can be *very* disk intensive. I've had IB 6 leave as little as 5MB of physical memory and Windows was pretty much dead in the water until the query was closed. (Large queries are necessary for report or when summarizing data.) If this has been improved in the latest IB/FB version, then this memory problem should be a non-issue. The more memory you can throw at IB, the better. I'm surprised here. Actually, the much heard complaint about IB/Fb is that it takes _too little_ memory and starts swapping to disk too soon. If you're having IB eating memory, you have a different problem. There was an earlier problem with IB Super Server not running well on multiple processors (it actually slowed things down). I believe this has been fixed in IB version 6.5. I don't know if this was fixed in FB because FB may be running IB Classic (single processor) version. Classic is not the single processor version, it runs much better on multiple CPUs than the SuperServer architecture. SS still has these problems on multiple CPU machines, Classic does not. I was under the impression that Classic version could have only 1 thread running at one time (each connection is a separate process), it would block other threads if they referenced the same table(s). There's no blocking in IB/Fb. Never. Except for a transaction lock (writers blocking other writers). In heavy systems, people prefer the Classic architecture because it runs better and you can throw in additional CPUs. The SuperServer was was suppose to solve that with a
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
On Dec 17, 2003, at 7:35 AM, Matthew Stanfield wrote: Wouldn't it be great if all mailing lists and newsgroups were as friendly and helpful as the mysql ones are. shameless plug I host a couple of lists: ProLinux and ProPython, which are for developers that are new to Linux and Python, and want help getting started. While the number of subscribers there are small, they are growing, and the atmosphere is very much like this list. Check 'em out at http://leafe.com/mailman/listinfo/prolinux and http://leafe.com/mailman/listinfo/propython, respectively. /shameless plug ___/ / __/ / / Ed Leafe Linux Love: unzip;strip;touch;finger;mount;fsck;more;yes;umount;sleep -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Jerry Apfelbaum wrote: I have been tasked with evaluating open source databases for a large upcoming project: e-commerce, B2B, high availability. Jerry -- See what I meant when I said: very active mailing lists where list subscribers are helpful and quick to respond. I think we all deserve a pat on the back for giving Jerry a comphrensive response to his initial posting. :-) --and it's still going... Wouldn't it be great if all mailing lists and newsgroups were as friendly and helpful as the mysql ones are. ..matthew -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Yes, Matthew, the response to my original query here has been almost overwhelming, far surpassing what I had expected. Yes, you certainly all deserve a pat on the back. Thanks to everyone who took the time to respond. This has proven to be a useful short cut to ascertaining some of strengths and weaknesses of the various Open Source DB offerings. Jerry Apfelbaum Toronto From: Matthew Stanfield [EMAIL PROTECTED] Date: 2003/12/17 Wed AM 07:35:25 EST Jerry -- See what I meant when I said: very active mailing lists where list subscribers are helpful and quick to respond. I think we all deserve a pat on the back for giving Jerry a comphrensive response to his initial posting. :-) --and it's still going... Wouldn't it be great if all mailing lists and newsgroups were as friendly and helpful as the mysql ones are. ..matthew 1 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Martijn, I've asked this question a year ago on the Borland forums but didn't get any replies. Do you know of any websites (non-programming related) that are using Interbase/Firebird for their primary webserver database? I don't mean programmer hangouts like www.mers.com or www.tamaracka.com etc., but Fortune 1000 companies who are using IB/FB on the web to serve up web pages? It would be interesting to get a list of who's using it online. TIA Mike -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
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]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Hi! --cut 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? --cut (sigh) You're so right. Almost every day I find myself hammering on database developers that 'there should be an index' , 'that index should not be used', 'the join order is wrong', 'the app designer should be punished', 'don't use a function around an indexed column (unless you use Oracle and have function-based indexes)', 'know your data to be able to write the right queries and to be able to help the poor optimizer to do a good job', 'test concurrency, test scalability, test realistically' and so on ... But that's the funny thing: when everything is done and deployed and __slow__ then 'the database is so slow, do something (immediately!)'. Regards, Frank. -- Dr. Frank Ullrich, DBA Netzwerkadministration Heise Zeitschriften Verlag GmbH Co KG, Helstorfer Str. 7, D-30625 Hannover E-Mail: [EMAIL PROTECTED] Phone: +49 511 5352 587; FAX: +49 511 5352 538 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Dr. Frank Ullrich wrote: Hi! --cut 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? --cut (sigh) You're so right. Almost every day I find myself hammering on database developers that 'there should be an index' , 'that index should not be used', 'the join order is wrong', 'the app designer should be punished', 'don't use a function around an indexed column (unless you use Oracle and have function-based indexes)', 'know your data to be able to write the right queries and to be able to help the poor optimizer to do a good job', 'test concurrency, test scalability, test realistically' and so on ... But that's the funny thing: when everything is done and deployed and __slow__ then 'the database is so slow, do something (immediately!)'. Regards, Frank. The part about helping out the optimizer rings especially true for me. One one box I take care of: SELECT message FROM syslog WHERE date1 '2003-12-01' AND message LIKE 'sshd%username'; Execution time: 20.85 seconds SELECT message FROM syslog FORCE INDEX(date1, message) WHERE date1 '2003-12-01' AND message LIKE 'sshd%username'; Execution time: 0.25 seconds On that topic, how have all the veteran MySQL users found the optimizer compared to the other offerings out there? I remember various interviews with Monty asking questions along the lines of What's the most interesting thing to do in DB development and similar have almost always been answered with Getting an optimizer to actually optimize queries really well. Regards, Chris -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
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 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Chris Nolan wrote: Regarding mysqldump, it handles binary data through escaping the required characters. pg_dump is similar if memory serves me correctly. Thanks Chris. So dumping binary data / large objects using myslqdump is fine. I looked up if this is ok with pg_dump as well and it is but you must use a non-text output option Eg. a tar file. Regards, ..matthew -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Usually, i'll use enum('0','1') in place of a boolean type.
Curtis
For JDBC stuff, I've found that if you really want to call this a
shortcoming, then that's about as far as you can take it
- the MySQL JDBC driver makes the BIT field act just like a single-bit
field.
Regards,
Chris
Sure -- but I did say it was only 'slightly annoying'.
TINYINT(1) which works fine but is slightly annoying because
of the extra type conversion needed every time you use it.
It just means with an ODBC programming library that, say, a method
GetBoolean does not work and you need to do say...
int i = odbcReader.GetInt(index);
bool b = i 0 ? true : false;
every time instead of:
bool b = odbcReader.GetBoolean(index);
It's just tedious, that's all.
Regards,
..matthew
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Matthew Stanfield wrote:
Usually, i'll use enum('0','1') in place of a boolean type.
Curtis
For JDBC stuff, I've found that if you really want to call this a
shortcoming, then that's about as far as you can take it
- the MySQL JDBC driver makes the BIT field act just like a
single-bit field.
Regards,
Chris
Sure -- but I did say it was only 'slightly annoying'.
TINYINT(1) which works fine but is slightly annoying because
of the extra type conversion needed every time you use it.
It just means with an ODBC programming library that, say, a method
GetBoolean does not work and you need to do say...
int i = odbcReader.GetInt(index);
bool b = i 0 ? true : false;
every time instead of:
bool b = odbcReader.GetBoolean(index);
It's just tedious, that's all.
Regards,
..matthew
True, but this isn't too massive an issue either if you think about it -
ODBC is closely tied to everyone's favourite programming language,
Prolog...err...
I mean Haskell...errr...I mean LISP. :-) Of course, I actually mean C. C
has very few primitive types, so delegating true boolean fields to a
low priority
makes a little bit of sense.
As you have said, only slightly annoying but perhaps much less annoying
than my posts! :-)
Regards,
Chris
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
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. :-) High-end database systems perfer more files, as they can be spread across multiple (usually fast SCSI) disks. Most databases recommend logs be kept on seperate disks than database files. Changes in the number of files can resolve problems if the problems are the result of low disk IO and you have money to throw at the problem. David -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
David Griffiths wrote: 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. :-) High-end database systems perfer more files, as they can be spread across multiple (usually fast SCSI) disks. Most databases recommend logs be kept on seperate disks than database files. Changes in the number of files can resolve problems if the problems are the result of low disk IO and you have money to throw at the problem. David True, but this isn't always the case. Let's look at the almighty InnoDB for instance. It happily uses multiple files for the data dictionary (ibdata*) if you tell it but, as far as I know, treats them like one big space, not doing striping or anything fancy. Additionally, if you have money to throw at the problem, you'd throw money at RAID and LVM. To prove my point, I pose the following question: * Would all those that enjoy extending database files as needed due to upgrading disks etc please raise their hands? Please? Come on! I promise that I won't tell SCO where you live With RAID you get performance and additional reliability if you want it. With LVM you get online growth of your storage if you are geeky and/or rich enough. Regarding logs being kept seperately, you will get no argument from me! In fact, if you can keep your logs on a HA cluster of NAS boxes, in a safe, covered in concrete, connected by multiply-redundant fibre-channel links, guarded by half the population of Wagga Wagga and plastered with images from random links from the awful, awful bowels of the internet I still reckon that you'd probably be able to find a way to go one better with log protection. Look at SQLBase - Zero Administration they reckon. Log files do not exist seperately, they exist inside the same file that holds everything else! Not good! You need to do a reorganise every few weeks or things start to...well..err...suck! Give me MySQL any day! Regards, Chris -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
High-end database systems perfer more files, as they can be spread across multiple (usually fast SCSI) disks. Most databases recommend logs be kept on seperate disks than database files. Changes in the number of files can resolve problems if the problems are the result of low disk IO and you have money to throw at the problem. David True, but this isn't always the case. Let's look at the almighty InnoDB for instance. It happily uses multiple files for the data dictionary (ibdata*) if you tell it but, as far as I know, treats them like one big space, not doing striping or anything fancy. It fills up the data-files sequentially (not writing a bit here, a bit there), but that could change. Of course, if you have all the data files spread across 5 disks, and you needed 10 non-sequential blocks (that aren't in memory), you will probably utilize more than one disk, which is a good thing. There is also a size issue. Each of our databases is about 25 gig of data. I don't want to cram that into one file. Some of our tables are in the 4-6 gig range. I don't want to be bumping up against 32-bit file-size limits. On Oracle, we have 9 tablespaces just for data (and each tablespace is 3 datafiles). Indexes have their own tablespaces. We have three mirrored disks, so each datafile goes on one mirrored-set. Our new server will be hot-swappable a RAID SCSI setup. The more drives you can get working at one time, the faster your database server will be (if you end up going to disk a fair bit). Backups in Oracle are not done by saving the datafiles. And if you use the InnoDB hot-backup tool (which we will have to), the same will apply to MySQL/InnoDB. So the # of files is not a hinderance to backups in that case. Finally, you can cram all your data into one InnoDB datafile if you so desire. It's one extra file to backup. In fact, with Oracle, you can just have one big data file. No FRM files or anything. Regarding logs being kept seperately, you will get no argument from me! In fact, if you can keep your logs on a HA cluster of NAS boxes, in a safe, covered in concrete, connected by multiply-redundant fibre-channel links, guarded by half the population of Wagga Wagga and plastered with images from random links from the awful, awful bowels of the internet I still reckon that you'd probably be able to find a way to go one better with log protection. Time to cut back on the coffee, my friend :) Seriously, log files are kept on different disks not for security, but for performance.Writing a 20-meg file to disk is a big performance hit; if you are trying to read and write database data from that disk at the same time, you'll notice it. Look at SQLBase - Zero Administration they reckon. Log files do not exist seperately, they exist inside the same file that holds everything else! Not good! You need to do a reorganise every few weeks or things start to...well..err...suck! Give me MySQL any day! That's brain-dead. The best database allows dba's and users to be as flexible as they want/need to be. David -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
At 01:59 PM 12/14/2003, you wrote: Hello. I have been tasked with evaluating open source databases for a large upcoming project: e-commerce, B2B, high availability. The O/S is most likely to be Linux, although FreeBSD could possibly be used (lower probability). So far, it seems that MySQL, MaxDB, PostgreSQL, and Interbase/Firebird are possible candidates. Does anyone know why we should or should not use any of these? Does anyone know of other possibilities? I'd very much appreciate hearing your comments and recommendations. I have only recently started these evaluations. BTW, my own background is from the Oracle DBA world. MySQL is certainly popular and seems to have very good performance, but I am concerned that the lack of Triggers, Stored Procedures, User-Defined Functions, and Views (to a lesser degree ) will be a disadvantage. MaxDB appears to be more feature-rich and possibly more industrial-strength. How does its performance and stability compare to the others? Many Thanks. Jerry Apfelbaum Toronto Jerry, Interbase/Firebird looks good on paper. But there are a couple of things to watch out for. 1) Check the Borland Interbase newsgroups for corruption to see if it is still an issue. I know from reading their newsgroups a few years back , there were quite a few postings. It could of been due to inadequate hardware or some external source like a misconfigured server or power failure. There are many sites that use IB without such problems but it is worth checking it out (especially how to successfully repair a damaged IB/FB database because all the tables are stored in one file). 2) Speed problems. I don't know how much data your tables will have, but IB/FB has a habit of slowing down as more rows are added/deleted. They have an automated Sweep process that cleans out the updated/deleted rows (deleted updated rows still take up space until the database is swept). Even so a large db will still slow down. I suspect the problem is due to unbalanced indexes. The only way to fix it is to unload all your data and reload it back in. Some people do it once a week. 3) The server CPU load will increase rapidly after the first 5 or 6 users. In other words IB/FB requires a much faster CPU than the same number of users for MySQL. It is a very CPU intensive DB server. There was an earlier problem with IB Super Server not running well on multiple processors (it actually slowed things down). I believe this has been fixed in IB version 6.5. I don't know if this was fixed in FB because FB may be running IB Classic (single processor) version. Mike -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Hi, Many Thanks. Jerry Apfelbaum Toronto Jerry, Interbase/Firebird looks good on paper. But there are a couple of things to watch out for. 1) Check the Borland Interbase newsgroups for corruption to see if it is still an issue. I know from reading their newsgroups a few years back , there were quite a few postings. It could of been due to inadequate hardware or some external source like a misconfigured server or power failure. There are many sites that use IB without such problems but it is worth checking it out (especially how to successfully repair a damaged IB/FB database because all the tables are stored in one file). Most of these problems have been fixed in Firebird. 2) Speed problems. I don't know how much data your tables will have, but IB/FB has a habit of slowing down as more rows are added/deleted. Really? Howcome there are many people using Firebird without speed problems? They have an automated Sweep process that cleans out the updated/deleted rows (deleted updated rows still take up space until the database is swept). Even so a large db will still slow down. I suspect the problem is due to unbalanced indexes. The only way to fix it is to unload all your data and reload it back in. Some people do it once a week. That's not true. The sweep process doesn't kick in until there's actually a problem with long running transactions and new transactions. 3) The server CPU load will increase rapidly after the first 5 or 6 users. In other words IB/FB requires a much faster CPU than the same number of users for MySQL. It is a very CPU intensive DB server. Most CPU problems are related to the above mentioned problems. This isn't usually the case. IB/Fb is actually more of a disk-intensive database engine, because of the ability to use very little memory. However, Firebird has some new stuff (and IB does too) that allows it to use more memory when available (and allowed) making it even faster. There was an earlier problem with IB Super Server not running well on multiple processors (it actually slowed things down). I believe this has been fixed in IB version 6.5. I don't know if this was fixed in FB because FB may be running IB Classic (single processor) version. Classic is not the single processor version, it runs much better on multiple CPUs than the SuperServer architecture. SS still has these problems on multiple CPU machines, Classic does not. 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]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
32-bit filesystem limits? Looking at any modern Linux FS, your file size limits are not hindered by 32-bit anything or even the FS itself. On kernel 2.4, internal kernel structures limit the maximum size of block devices to around 1 TB. As a result, you can only have files of about that size (even though ReiserFS and XFS support hideously bigger files). As far as I know, almost every OS aimed at doing anything non-trivial (so everything other than DOS 2.11), has no problem with files of any size up to some rather massive limit like the one above. Additionally, you could just point InnoDB at a raw partition sitting on an LVM set on top of a RAID and be happy. Or you could do what my friend tried once, and see if you can hot-swap a bog-standard IDE drive Regarding SQLBase, it is indeed a joke. The latest version includes sorting methods that are up to 250% faster! If that's the case, which idiot coded the first set? Almost every other DB vendor has figured out how to sort quite well for ages now... David Griffiths wrote: High-end database systems perfer more files, as they can be spread across multiple (usually fast SCSI) disks. Most databases recommend logs be kept on seperate disks than database files. Changes in the number of files can resolve problems if the problems are the result of low disk IO and you have money to throw at the problem. David True, but this isn't always the case. Let's look at the almighty InnoDB for instance. It happily uses multiple files for the data dictionary (ibdata*) if you tell it but, as far as I know, treats them like one big space, not doing striping or anything fancy. It fills up the data-files sequentially (not writing a bit here, a bit there), but that could change. Of course, if you have all the data files spread across 5 disks, and you needed 10 non-sequential blocks (that aren't in memory), you will probably utilize more than one disk, which is a good thing. There is also a size issue. Each of our databases is about 25 gig of data. I don't want to cram that into one file. Some of our tables are in the 4-6 gig range. I don't want to be bumping up against 32-bit file-size limits. On Oracle, we have 9 tablespaces just for data (and each tablespace is 3 datafiles). Indexes have their own tablespaces. We have three mirrored disks, so each datafile goes on one mirrored-set. Our new server will be hot-swappable a RAID SCSI setup. The more drives you can get working at one time, the faster your database server will be (if you end up going to disk a fair bit). Backups in Oracle are not done by saving the datafiles. And if you use the InnoDB hot-backup tool (which we will have to), the same will apply to MySQL/InnoDB. So the # of files is not a hinderance to backups in that case. Finally, you can cram all your data into one InnoDB datafile if you so desire. It's one extra file to backup. In fact, with Oracle, you can just have one big data file. No FRM files or anything. Regarding logs being kept seperately, you will get no argument from me! In fact, if you can keep your logs on a HA cluster of NAS boxes, in a safe, covered in concrete, connected by multiply-redundant fibre-channel links, guarded by half the population of Wagga Wagga and plastered with images from random links from the awful, awful bowels of the internet I still reckon that you'd probably be able to find a way to go one better with log protection. Time to cut back on the coffee, my friend :) Seriously, log files are kept on different disks not for security, but for performance.Writing a 20-meg file to disk is a big performance hit; if you are trying to read and write database data from that disk at the same time, you'll notice it. Look at SQLBase - Zero Administration they reckon. Log files do not exist seperately, they exist inside the same file that holds everything else! Not good! You need to do a reorganise every few weeks or things start to...well..err...suck! Give me MySQL any day! That's brain-dead. The best database allows dba's and users to be as flexible as they want/need to be. David -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
At 04:07 PM 12/16/2003, you wrote: Hi, Many Thanks. Jerry Apfelbaum Toronto Jerry, Interbase/Firebird looks good on paper. But there are a couple of things to watch out for. 1) Check the Borland Interbase newsgroups for corruption to see if it is still an issue. I know from reading their newsgroups a few years back , there were quite a few postings. It could of been due to inadequate hardware or some external source like a misconfigured server or power failure. There are many sites that use IB without such problems but it is worth checking it out (especially how to successfully repair a damaged IB/FB database because all the tables are stored in one file). Most of these problems have been fixed in Firebird. 2) Speed problems. I don't know how much data your tables will have, but IB/FB has a habit of slowing down as more rows are added/deleted. Really? Howcome there are many people using Firebird without speed problems? It depends on the size of the tables. WIth 50k rows you're not going to notice it. With 50 million rows the slow down becomes apparent. They have an automated Sweep process that cleans out the updated/deleted rows (deleted updated rows still take up space until the database is swept). Even so a large db will still slow down. I suspect the problem is due to unbalanced indexes. The only way to fix it is to unload all your data and reload it back in. Some people do it once a week. That's not true. The sweep process doesn't kick in until there's actually a problem with long running transactions and new transactions. Updated and deleted rows will remain in the table until a sweep is done. If 100,000 rows are updated, then the old rows will remain in the table and the sweep cleans them out. A heavily updated table will need to be swept often. When sweeps fail to speed up the table, the data has to be unloaded and reloaded. That's not something you want to do very often if you want to have a 24/7 installation especially with millions of rows. 3) The server CPU load will increase rapidly after the first 5 or 6 users. In other words IB/FB requires a much faster CPU than the same number of users for MySQL. It is a very CPU intensive DB server. Most CPU problems are related to the above mentioned problems. This isn't usually the case. IB/Fb is actually more of a disk-intensive database engine, because of the ability to use very little memory. However, Firebird has some new stuff (and IB does too) that allows it to use more memory when available (and allowed) making it even faster. IB eats up a lot of memory on large queries, something that should be avoided if at all possible. All queries are fetched into memory, and when physical memory is exhausted, IB will use the page file (in Windows) and swaps the physical memory out to disk. This can be *very* disk intensive. I've had IB 6 leave as little as 5MB of physical memory and Windows was pretty much dead in the water until the query was closed. (Large queries are necessary for report or when summarizing data.) If this has been improved in the latest IB/FB version, then this memory problem should be a non-issue. The more memory you can throw at IB, the better. There was an earlier problem with IB Super Server not running well on multiple processors (it actually slowed things down). I believe this has been fixed in IB version 6.5. I don't know if this was fixed in FB because FB may be running IB Classic (single processor) version. Classic is not the single processor version, it runs much better on multiple CPUs than the SuperServer architecture. SS still has these problems on multiple CPU machines, Classic does not. I was under the impression that Classic version could have only 1 thread running at one time (each connection is a separate process), it would block other threads if they referenced the same table(s). The SuperServer was was suppose to solve that with a separate thread for each connection, but had some speed issues on SMP machines (ran slower). IB requires a lot more work in tweaking than say MySQL because it is a much more sophisticated database. Properly configured it can work well, but is a higher maintenance database than MySQL and requires more memory and CPU. If the programmer needs all those bells and whistles, then IB may be the solution they're looking for. Mike -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Hi, So far, it seems that MySQL, MaxDB, PostgreSQL, and Interbase/Firebird are possible candidates. Does anyone know why we should or should not use any of these? Does anyone know of other possibilities? I was very disappointed by Interbase/Firebird. It seemed to me like a MS-Access: a database-engine that works on regular files What gave you that idea? Firebird (and InterBase of course) use a at least 1 file per database, but that's all. Can you define regular files? OK, there is a network-server component, but it really has nothing to do with an enterprise-DB. There's a server side process waiting for incoming connections just like with MySQL, MS SQL Server, Oracle etc etc... What exactly are you missing in Firebird? 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]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
So far, it seems that MySQL, MaxDB, PostgreSQL, and Interbase/Firebird are possible candidates. Does anyone know why we should or should not use any of these? Does anyone know of other possibilities? I was very disappointed by Interbase/Firebird. It seemed to me like a MS-Access: a database-engine that works on regular files OK, there is a network-server component, but it really has nothing to do with an enterprise-DB. It is a mystery to me how the PostGreSQL work. I cannot recomm to use any feature discovered in PostGreSQL since some of the more uncommon feature are broken. I have only recently started these evaluations. BTW, my own background is from the Oracle DBA world. Well, the DBMS comparable to Oracle is neither MySQL nor Firebird. It's MaxDB. MySQL is certainly popular and seems to have very good performance, but I am concerned that the lack of Triggers, Stored Procedures, User-Defined Functions, and Views (to a lesser degree ) will be a disadvantage. And foreign-keys are a feature you shouldn't miss to. MySQL does offer them by patching it with InnoDB. MaxDB appears to be more feature-rich and possibly more industrial-strength. How does its performance and stability compare to the others? I'm using MaxDB and it's running 24/7 without problem on a web-server with a Java-WebApp. Before using MaxDB you should first look at the limits that MaxDB has. For example a row in a table may only store data up to 8KB. BLOP and CLOP columns don't count, but even for varchar-columns 8KB is a bit few. MaxDB has Unicode-support (UCS2) which is extremely important for Java-Clients. If using Unicode, 8KB means 4000chars. CLOB and BLOB-columns in MaxDB aren't comparable. You cannot use like or ,,= on them. MaxDB even doesn't have a FullText-Search, but to me it's not that important since i can replace them with Java-based search-engines like Lucene. MaxDB has a mechanism to backup your database without breaking anything. MaxDB supports Server-side prepared statement. The JDBC-driver is of good quality. Bugs are fixed relativly fast. My favourite DBMS could be PostGreSQL if i only knew which features are stable and which are not. A strange thing is, that the PostGreSQL-people decided to use UTF-8 for their unicode-support. In my eyes that makes it different to calculate string-lengthts and comparisons. But their argument is, that UTF-8 usually causes less disk-io. But does varchar(400) now mean 400bytes or 400chars? i don't know. I didn't take a close look at PostGreSQL yet, so all features that i mentioned about MaxDB might apply to PostGreSQL too. On both, MaxDB and PostGreSQL, you need to perform regular tasks. You must update the optimizer statistics for MaxDB, and run VACUUM for PostGreSQL. MySQL, well, i wouldn't know how to backup it, except by using a dump. How can i dump a table with binary data? I don't wanna know. A dump is not a backup, it's crap. Than there's the lack of Unicode-support, Foreign Keys, prepared statements (emulated by client-lib if available as far as i know), ... That all doens't make me feel comfortable about MySQL. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
It is a mystery to me how the PostGreSQL work. I cannot recomm to use any feature discovered in PostGreSQL since some of the more uncommon feature are broken. Would you care to elaborate? I've used both PostgreSQL and mySQL, but certainly not all features, and I'm curious about what issues you had with PGSQL. Cheers, Joshua Thomas Network Operations Engineer PowerOne Media, Inc. tel: 518-687-6143 [EMAIL PROTECTED] --- In theory there is no difference between theory and practice. In practice there is. - Yogi Berra ---
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Huh? Not know how to backup a MySQL database? *sigh* Every night, I do a backup of our MySQL database server that's holding all of our mail and various other things (20GB+). I set the isolation level to READ_REPEATABLE and use mysqldump | bzip2 to get the result. I've tested the restore and it's fine! A uni project I was working on this year that stored images and other binary stuff in BLOB fields was successfully backed up in a similar fashion. This all applies to InnoDB tables. I've heard cases of needing to use READ_COMMITED as the isolation level in some cases, as one can run into issues with memory consumption / table space problems if your traffic is high. To backup those funky sleek MyISAM tables, you could just issue a LOCK TABLE statement or two (LOCK DATABASE?), do a FLUSH and copy the files. If I recall correctly, (and I'm sure sirs DuBois and Zawodny will find out where I live and deal with me if I don't :-) ), this might be how the mysqlhotcopy script works. Regarding Interbase/Firebird - you're talking about a database with a very long and detailed history. The fact there is one file per database doesn't mean much - InnoDB has one file per server should you want to configure it that way and no stable release allows you to break up your databases or tables into files in any fashion other than what InnoDB itself decides to do with the ibdata* files you allow it to have. Interbase is still one of the most popular embedded databases in the world! Even more popular than (ick) FileMaker Pro and (vomit) FoxPro! Just looking at the number of third party tools out there that support development using it is a pretty decent vote of it's industry acceptance. I'm curious as to why you're not comfortable with MySQL. It truly features the best of all worlds when it comes to performance options and I've found the community support (Read: The MySQL mailing list) to be far more valuable than any course I've looked at or taken. I'd be very interested in hearing more from you, as I'm betting a few other readers on both lists would. Best regards, Chris Sven Köhler wrote: So far, it seems that MySQL, MaxDB, PostgreSQL, and Interbase/Firebird are possible candidates. Does anyone know why we should or should not use any of these? Does anyone know of other possibilities? I was very disappointed by Interbase/Firebird. It seemed to me like a MS-Access: a database-engine that works on regular files OK, there is a network-server component, but it really has nothing to do with an enterprise-DB. It is a mystery to me how the PostGreSQL work. I cannot recomm to use any feature discovered in PostGreSQL since some of the more uncommon feature are broken. I have only recently started these evaluations. BTW, my own background is from the Oracle DBA world. Well, the DBMS comparable to Oracle is neither MySQL nor Firebird. It's MaxDB. MySQL is certainly popular and seems to have very good performance, but I am concerned that the lack of Triggers, Stored Procedures, User-Defined Functions, and Views (to a lesser degree ) will be a disadvantage. And foreign-keys are a feature you shouldn't miss to. MySQL does offer them by patching it with InnoDB. MaxDB appears to be more feature-rich and possibly more industrial-strength. How does its performance and stability compare to the others? I'm using MaxDB and it's running 24/7 without problem on a web-server with a Java-WebApp. Before using MaxDB you should first look at the limits that MaxDB has. For example a row in a table may only store data up to 8KB. BLOP and CLOP columns don't count, but even for varchar-columns 8KB is a bit few. MaxDB has Unicode-support (UCS2) which is extremely important for Java-Clients. If using Unicode, 8KB means 4000chars. CLOB and BLOB-columns in MaxDB aren't comparable. You cannot use like or ,,= on them. MaxDB even doesn't have a FullText-Search, but to me it's not that important since i can replace them with Java-based search-engines like Lucene. MaxDB has a mechanism to backup your database without breaking anything. MaxDB supports Server-side prepared statement. The JDBC-driver is of good quality. Bugs are fixed relativly fast. My favourite DBMS could be PostGreSQL if i only knew which features are stable and which are not. A strange thing is, that the PostGreSQL-people decided to use UTF-8 for their unicode-support. In my eyes that makes it different to calculate string-lengthts and comparisons. But their argument is, that UTF-8 usually causes less disk-io. But does varchar(400) now mean 400bytes or 400chars? i don't know. I didn't take a close look at PostGreSQL yet, so all features that i mentioned about MaxDB might apply to PostGreSQL too. On both, MaxDB and PostGreSQL, you need to perform regular tasks. You must update the optimizer statistics for MaxDB, and run VACUUM for PostGreSQL. MySQL, well, i wouldn't know how to backup it, except by using a dump. How can
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
I was very disappointed by Interbase/Firebird. It seemed to me like a MS-Access: a database-engine that works on regular files What gave you that idea? Firebird (and InterBase of course) use a at least 1 file per database, but that's all. Can you define regular files? My idea of Firebird is the following: There a library that can access a file and use it as a database. that very much like using the MS-Jet-Engine which is the backend to MS-Access. OK, there is a network-server component, but it really has nothing to do with an enterprise-DB. There's a server side process waiting for incoming connections just like with MySQL, MS SQL Server, Oracle etc etc... Well, the network-server seemed to me like an application that uses the library i mentioned above. It doesn't seem to me like a big application like MySql or MaxDB. In other words: Firebird seems to be light weight DBMS. MySQL and MaxDB have a multi-threaded kernel that maintains its own cache, coordinates locks, etc. I don't think that Firebird's architecture is like that. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Hi Sven, I was very disappointed by Interbase/Firebird. It seemed to me like a MS-Access: a database-engine that works on regular files What gave you that idea? Firebird (and InterBase of course) use a at least 1 file per database, but that's all. Can you define regular files? My idea of Firebird is the following: There a library that can access a file and use it as a database. that very much like using the MS-Jet-Engine which is the backend to MS-Access. Actually, this is Firebird Embedded. Indeed, a single DLL (with some additional DLLs if you want additional character set support) that acts like the engine. Firebird Embedded is single user. OK, there is a network-server component, but it really has nothing to do with an enterprise-DB. There's a server side process waiting for incoming connections just like with MySQL, MS SQL Server, Oracle etc etc... Well, the network-server seemed to me like an application that uses the library i mentioned above. Not at all. It's the other way around: the embedded version is almost the same as the server-side engine process, but wrapped into a library. It doesn't seem to me like a big application like MySql or MaxDB. In other words: Firebird seems to be light weight DBMS. Light weight it sure is. Very modest on memory requirements, for example. A bit too modest sometimes :-) MySQL and MaxDB have a multi-threaded kernel that maintains its own cache, coordinates locks, etc. I don't think that Firebird's architecture is like that. On the contrary, Firebirds architecture is exactly like that. 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]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
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 What gave you that idea? Firebird (and InterBase of course) use a at least 1 file per database, but that's all. Can you define regular files? My idea of Firebird is the following: There a library that can access a file and use it as a database. that very much like using the MS-Jet-Engine which is the backend to MS-Access. OK, there is a network-server component, but it really has nothing to do with an enterprise-DB. There's a server side process waiting for incoming connections just like with MySQL, MS SQL Server, Oracle etc etc... Well, the network-server seemed to me like an application that uses the library i mentioned above. It doesn't seem to me like a big application like MySql or MaxDB. In other words: Firebird seems to be light weight DBMS. MySQL and MaxDB have a multi-threaded kernel that maintains its own cache, coordinates locks, etc. I don't think that Firebird's architecture is like that. Hmmmyou'll find that the SQL products worth mentioning that are like Access are the following: SQLite, FoxPro, FileMaker I could be wrong about the last two on some of these points, but all of the above are accessed via a library and are not wrapped in a server process (FileMaker Server is available, and it seems to alleviate this). Additionally, you won't get much in the way of write concurrency with the above products (which isn't a problem with SQLite, as it's designed for embedded stuff). Firebird/Interbase have all those nice things like row-level locking (although it doesn't seem to have multiversioning like InnoDB, PostgreSQL or Oracle), deadlock detection, prepared statements, views, stored procedures, automatic index management, proper SQL-92 isolation levels and funky caches for indexes, rows and other weird and wonderful metadata. Here's something you might want to do to see if my research is correct: 1. Install Firebird. Dump massive amounts of data in it and then do something like this: ALTER TABE test_table ADD INDEX(some_column) while the DB is being accessed. 2. Install some FoxPro or Jet application (or ACT! You'll either laugh or cry after trying this with ACT!). Dump lots of data into it and attempt a reindex whle the DB is being accessed. Guess which DB comes out alive? Regards, Chris -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Firebird/Interbase have all those nice things like row-level locking (although it doesn't seem to have multiversioning like InnoDB, PostgreSQL or Oracle), deadlock detection, prepared statements, views, Yes it DOES have multi-versioning. Actually, I believe it was the first (InterBase that is) multi-versioning engine around! 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]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Martijn Tonies wrote: Firebird/Interbase have all those nice things like row-level locking (although it doesn't seem to have multiversioning like InnoDB, PostgreSQL or Oracle), deadlock detection, prepared statements, views, Yes it DOES have multi-versioning. Actually, I believe it was the first (InterBase that is) multi-versioning engine around! With regards, Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL MS SQL Server. Upscene Productions http://www.upscene.com Really? I feel smarter already! Do you have any documentation regarding Firebird's workings that you would recommend looking through (of similar or deeper detail than PostgreSQL's, MySQL's and the stuff in the internals.texi file that comes with 4.1.1). If I can avoid reading source code though, I'd like to at this point (wxWindows programming has been getting to me lately). Chris -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Hi Chris, Firebird/Interbase have all those nice things like row-level locking (although it doesn't seem to have multiversioning like InnoDB, PostgreSQL or Oracle), deadlock detection, prepared statements, views, Yes it DOES have multi-versioning. Actually, I believe it was the first (InterBase that is) multi-versioning engine around! Really? I feel smarter already! Do you have any documentation regarding Firebird's workings that you would recommend looking through (of similar or deeper detail than PostgreSQL's, MySQL's and the stuff in the internals.texi file that comes with 4.1.1). If I can avoid reading source code though, I'd like to at this point (wxWindows programming has been getting to me lately). Well, there's usually lots of documentation available at www.ibphoenix.com but the site seems to be down for some reason. For a quick reference on the history of InterBase (and Firebird): http://www.cvalde.net/IbRoadmap.htm And for fun reading: http://www.cvalde.net/misc/how_appeared.htm Wanna know who invented BLOBs? http://www.cvalde.net/misc/blob_true_history.htm As you perhaps know, Firebird is relatively new to the Open Source market, but as it started from the InterBase 6 source code, it does have quite the history :-) 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]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
I set the isolation level to READ_REPEATABLE and use mysqldump | bzip2 to get the result. I've tested the restore and it's fine! So how does mysqldump handle binary data? If it does embed the data into the SQL-statement somehow, that's crap, since SQL-Statements are limited in length. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Are they? Shoving in rows that are several meg in size didn't pose any problems. The restore procedure looked like this: bunzip2 dumpfile | mysql -u db_grunt -p projectdb May I ask where the limitation you mentioned is documented? Maybe the situations we were using it in didn't come close to the limit. Regards, Chris Sven Köhler wrote: I set the isolation level to READ_REPEATABLE and use mysqldump | bzip2 to get the result. I've tested the restore and it's fine! So how does mysqldump handle binary data? If it does embed the data into the SQL-statement somehow, that's crap, since SQL-Statements are limited in length. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Sonntag, 14. Dezember 2003 20:59 schrieb Jerry Apfelbaum: Hello. I have been tasked with evaluating open source databases for a large upcoming project: e-commerce, B2B, high availability. So, you should choose SapDB 7.3 or 7.4 due License issues. 7.3 ands 7.4 are GPL/LGPL, since 7.5 aka MaxDB LGPL is dropped, so you are forced to pay for Userlicences. Refer to http://www.mysql.com We are thinking about to fork the SapDB 7.3/7.4 Brances to continue in GPL/LGPL. mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, [EMAIL PROTECTED] ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.deICQ: #344389676 ** -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/3cjVW7UKI9EqarERAn3DAJ9Z7J+gSVYRc+l+tTKuV5hbgnq15gCfZsVw hoX59ewH2XefYSMIn5rNGGY= =TMeG -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Sven Köhler wrote: I set the isolation level to READ_REPEATABLE and use mysqldump | bzip2 to get the result. I've tested the restore and it's fine! So how does mysqldump handle binary data? If it does embed the data into the SQL-statement somehow, that's crap, since SQL-Statements are limited in length. On Tue, 16 Dec 2003, Chris Nolan wrote: Are they? Shoving in rows that are several meg in size didn't pose any problems. The restore procedure looked like this: bunzip2 dumpfile | mysql -u db_grunt -p projectdb May I ask where the limitation you mentioned is documented? Maybe the situations we were using it in didn't come close to the limit. Regards, Chris This is limited by the max_packet_size variable. In 3.23.x it's limited to 16Mb, in 4.0+ it is limited by 2Gb or the amount of physical memory the machine has, whichever is less. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Tobias Asplund wrote: Sven Köhler wrote: I set the isolation level to READ_REPEATABLE and use mysqldump | bzip2 to get the result. I've tested the restore and it's fine! So how does mysqldump handle binary data? If it does embed the data into the SQL-statement somehow, that's crap, since SQL-Statements are limited in length. On Tue, 16 Dec 2003, Chris Nolan wrote: Are they? Shoving in rows that are several meg in size didn't pose any problems. The restore procedure looked like this: bunzip2 dumpfile | mysql -u db_grunt -p projectdb May I ask where the limitation you mentioned is documented? Maybe the situations we were using it in didn't come close to the limit. Regards, Chris This is limited by the max_packet_size variable. In 3.23.x it's limited to 16Mb, in 4.0+ it is limited by 2Gb or the amount of physical memory the machine has, whichever is less. I don't think any of our rows were more than 10 - 20 MB, and we were using 4.0.13 or higher the entire time. If I recall correctly, the way around this is to use InnoDB Hot Backup for InnoDB tables and mysqlhotcopy for MyISAM tables. I guess you're on your own for BDB tables! Regards, Chris -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Hi, I've used both PostgreSQL and MySQL on a Linux server and found both setting up (using RPM) and maintaining them very easy (MySQL was slightly easier to set up but I set it up after I was already proficient on PostgreSQL, so perhaps comparing the ease of setup is unfair). Both are well documented and each have very active mailing lists where list subscribers are helpful and quick to respond. I have no idea how the commercial support services compare in quality and price. I have not used the more 'advanced' features, that you mentioned, of either (such as: 'Triggers, Stored Procedures, User-Defined Functions') so can't comment on them. Backups on both are straightforward using pg_dump and mysqldump. Both of these allow you to dump databases as files containing the relevant sql commands to recreate the entire database quickly and easily. Another responder mentioned a possible problem dumping MySQL databases containing binary data, I have no idea whether this is an issue with pg_dump as well, as I have no tables at all with binary data, but suspect dumping these kind of backup files is generally inconsistent with binary data (unless the dumping utilities do something clever, which I don't know about, like uuencoding binary data). Anyway both servers can be backed up by copying the actual database table files (on the local linux filesystem). To achieve this the PostgreSQL server must be shut down (making it an inferior backup technique to dumping which does not require a shutdown). MySQL, however, has something called 'mysqlhotcopy' which will lock and flush tables and copy the files using 'cp' and does not require a server shutdown, it allows queries by different threads to continue, blind to the backup in progress. --I must admit to being a bit wary of this as I don't know enough about the underlying file systems and so personally have no intention of using mysqlhotcopy. --Perhaps someone that knows more can explain whether this is always safe to use and why?? Both PostgreSQL and MySQL have free GUI frontends (pgAdmin and Control Center, respectively) that I have used on Windows 2000; both have been adequate for my basic needs, EG. Quick database and table creation and deletion, sql commands, and basic administration such as vacuuming (PostgreSQL) and optimizing (MySQL). Of these PostgeSQL's is better (far more features), while MySQL's is still at 0.9.3 beta (stable but feature poor). My use of both has been low scale and is client program orientated using .net and C# from Win2000. The ODBC drivers for Windows both function well. The only annoying thing I can think of, from a programming perspective, is MySQL's lack of a Boolean type - the manual says use TINYINT(1) which works fine but is slightly annoying because of the extra type conversion needed every time you use it. Apparently MySQL will be implementing the Boolean type soon in accordance with whatever SQL standard requires it. Quite why it still has not been implemented, even though MySQL is into version 4, I have no idea - as a programmer I find this a staggering omission but presumably they have their reasons and perhaps most people are happy with TINYINT(1), but for clarity of code TINYINT(1) is inferior to a Boolean type. I hope this helps, ..matthew Jerry Apfelbaum wrote: Hello. I have been tasked with evaluating open source databases for a large upcoming project: e-commerce, B2B, high availability. The O/S is most likely to be Linux, although FreeBSD could possibly be used (lower probability). So far, it seems that MySQL, MaxDB, PostgreSQL, and Interbase/Firebird are possible candidates. Does anyone know why we should or should not use any of these? Does anyone know of other possibilities? Id very much appreciate hearing your comments and recommendations. I have only recently started these evaluations. BTW, my own background is from the Oracle DBA world. MySQL is certainly popular and seems to have very good performance, but I am concerned that the lack of Triggers, Stored Procedures, User-Defined Functions, and Views (to a lesser degree ) will be a disadvantage. MaxDB appears to be more feature-rich and possibly more industrial-strength. How does its performance and stability compare to the others? Many Thanks. Jerry Apfelbaum Toronto -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Matthew Stanfield said:
Hi,
Usually, i'll use enum('0','1') in place of a boolean type.
Curtis
[snip]
well. The only annoying thing I can think of, from a programming
perspective, is MySQL's lack of a Boolean type - the manual says use
TINYINT(1) which works fine but is slightly annoying because of the
extra type conversion needed every time you use it. Apparently MySQL
will be implementing the Boolean type soon in accordance with whatever
SQL standard requires it. Quite why it still has not been implemented,
even though MySQL is into version 4, I have no idea - as a programmer I
find this a staggering omission but presumably they have their reasons
and perhaps most people are happy with TINYINT(1), but for clarity of
code TINYINT(1) is inferior to a Boolean type.
I hope this helps,
..matthew
Jerry Apfelbaum wrote:
Hello.
I have been tasked with evaluating open source databases for a large
upcoming project: e-commerce, B2B, high availability.
The O/S is most likely to be Linux, although FreeBSD could possibly be
used (lower probability).
So far, it seems that MySQL, MaxDB, PostgreSQL, and Interbase/Firebird
are possible candidates.
Does anyone know why we should or should not use any of these? Does
anyone know of other possibilities?
Id very much appreciate hearing your comments and recommendations.
I have only recently started these evaluations. BTW, my own
background is from the Oracle DBA world.
MySQL is certainly popular and seems to have very good performance,
but I am concerned that the lack of Triggers, Stored Procedures,
User-Defined Functions, and Views (to a lesser degree ) will be a
disadvantage.
MaxDB appears to be more feature-rich and possibly more
industrial-strength. How does its performance and stability compare
to the others?
Many Thanks.
Jerry Apfelbaum
Toronto
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Hi, Regarding backups, mysqlhotcopy locks all MyISAM tables named for backup before copying the files. As a result, they are in a consistant state. InnoDB and BDB tables need to be handled differently though, so you're looking at 1 of 4 methods: 1. Shut the database down and copy the table space and logs. 2. Use mysqldump 3. Get a copy of InnoDB Hot Backup for InnoDB and MyISAM 4. Set up replication and shutdown the slave when you need to do a backup and use method 1 on it. Regarding mysqldump, it handles binary data through escaping the required characters. pg_dump is similar if memory serves me correctly. Regards, Chris Matthew Stanfield wrote: Hi, I've used both PostgreSQL and MySQL on a Linux server and found both setting up (using RPM) and maintaining them very easy (MySQL was slightly easier to set up but I set it up after I was already proficient on PostgreSQL, so perhaps comparing the ease of setup is unfair). Both are well documented and each have very active mailing lists where list subscribers are helpful and quick to respond. I have no idea how the commercial support services compare in quality and price. I have not used the more 'advanced' features, that you mentioned, of either (such as: 'Triggers, Stored Procedures, User-Defined Functions') so can't comment on them. Backups on both are straightforward using pg_dump and mysqldump. Both of these allow you to dump databases as files containing the relevant sql commands to recreate the entire database quickly and easily. Another responder mentioned a possible problem dumping MySQL databases containing binary data, I have no idea whether this is an issue with pg_dump as well, as I have no tables at all with binary data, but suspect dumping these kind of backup files is generally inconsistent with binary data (unless the dumping utilities do something clever, which I don't know about, like uuencoding binary data). Anyway both servers can be backed up by copying the actual database table files (on the local linux filesystem). To achieve this the PostgreSQL server must be shut down (making it an inferior backup technique to dumping which does not require a shutdown). MySQL, however, has something called 'mysqlhotcopy' which will lock and flush tables and copy the files using 'cp' and does not require a server shutdown, it allows queries by different threads to continue, blind to the backup in progress. --I must admit to being a bit wary of this as I don't know enough about the underlying file systems and so personally have no intention of using mysqlhotcopy. --Perhaps someone that knows more can explain whether this is always safe to use and why?? Both PostgreSQL and MySQL have free GUI frontends (pgAdmin and Control Center, respectively) that I have used on Windows 2000; both have been adequate for my basic needs, EG. Quick database and table creation and deletion, sql commands, and basic administration such as vacuuming (PostgreSQL) and optimizing (MySQL). Of these PostgeSQL's is better (far more features), while MySQL's is still at 0.9.3 beta (stable but feature poor). My use of both has been low scale and is client program orientated using .net and C# from Win2000. The ODBC drivers for Windows both function well. The only annoying thing I can think of, from a programming perspective, is MySQL's lack of a Boolean type - the manual says use TINYINT(1) which works fine but is slightly annoying because of the extra type conversion needed every time you use it. Apparently MySQL will be implementing the Boolean type soon in accordance with whatever SQL standard requires it. Quite why it still has not been implemented, even though MySQL is into version 4, I have no idea - as a programmer I find this a staggering omission but presumably they have their reasons and perhaps most people are happy with TINYINT(1), but for clarity of code TINYINT(1) is inferior to a Boolean type. I hope this helps, ..matthew Jerry Apfelbaum wrote: Hello. I have been tasked with evaluating open source databases for a large upcoming project: e-commerce, B2B, high availability. The O/S is most likely to be Linux, although FreeBSD could possibly be used (lower probability). So far, it seems that MySQL, MaxDB, PostgreSQL, and Interbase/Firebird are possible candidates. Does anyone know why we should or should not use any of these? Does anyone know of other possibilities? Id very much appreciate hearing your comments and recommendations. I have only recently started these evaluations. BTW, my own background is from the Oracle DBA world. MySQL is certainly popular and seems to have very good performance, but I am concerned that the lack of Triggers, Stored Procedures, User-Defined Functions, and Views (to a lesser degree ) will be a disadvantage. MaxDB appears to be more feature-rich and possibly more industrial-strength. How does its performance and stability compare to the others? Many
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Curtis Maurand wrote:
Matthew Stanfield said:
Hi,
Usually, i'll use enum('0','1') in place of a boolean type.
Curtis
[snip]
For JDBC stuff, I've found that if you really want to call this a
shortcoming, then that's about as far as you can take it
- the MySQL JDBC driver makes the BIT field act just like a single-bit
field.
Regards,
Chris
well. The only annoying thing I can think of, from a programming
perspective, is MySQL's lack of a Boolean type - the manual says use
TINYINT(1) which works fine but is slightly annoying because of the
extra type conversion needed every time you use it. Apparently MySQL
will be implementing the Boolean type soon in accordance with whatever
SQL standard requires it. Quite why it still has not been implemented,
even though MySQL is into version 4, I have no idea - as a programmer I
find this a staggering omission but presumably they have their reasons
and perhaps most people are happy with TINYINT(1), but for clarity of
code TINYINT(1) is inferior to a Boolean type.
I hope this helps,
..matthew
Jerry Apfelbaum wrote:
Hello.
I have been tasked with evaluating open source databases for a large
upcoming project: e-commerce, B2B, high availability.
The O/S is most likely to be Linux, although FreeBSD could possibly be
used (lower probability).
So far, it seems that MySQL, MaxDB, PostgreSQL, and Interbase/Firebird
are possible candidates.
Does anyone know why we should or should not use any of these? Does
anyone know of other possibilities?
Id very much appreciate hearing your comments and recommendations.
I have only recently started these evaluations. BTW, my own
background is from the Oracle DBA world.
MySQL is certainly popular and seems to have very good performance,
but I am concerned that the lack of Triggers, Stored Procedures,
User-Defined Functions, and Views (to a lesser degree ) will be a
disadvantage.
MaxDB appears to be more feature-rich and possibly more
industrial-strength. How does its performance and stability compare
to the others?
Many Thanks.
Jerry Apfelbaum
Toronto
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
On Tue, Dec 16, 2003 at 01:11:21AM +1100, Chris Nolan wrote: To backup those funky sleek MyISAM tables, you could just issue a LOCK TABLE statement or two (LOCK DATABASE?), do a FLUSH and copy the files. If I recall correctly, (and I'm sure sirs DuBois and Zawodny will find out where I live and deal with me if I don't :-) ), this might be how the mysqlhotcopy script works. Yes, that's basically what mysqlhotcopy does. Jeremy -- Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo! [EMAIL PROTECTED] | http://jeremy.zawodny.com/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
I have only recently started these evaluations. BTW, my own background is from the Oracle DBA world. MySQL is certainly popular and seems to have very good performance, but I am concerned that the lack of Triggers, Stored Procedures, User-Defined Functions, and Views (to a lesser degree ) will be a disadvantage. I had a bad experience with Triggers Stored Procedures wiht SAPDB. If you are going to use have if..else like conditions, then it is not easy to work with in SAPDB. While in PostgreSQL it works flawlessly and syntaxis also very similar to Oracle plSql. Vinod -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
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). -- dave -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
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. -- Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo! [EMAIL PROTECTED] | http://jeremy.zawodny.com/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
MySQL or MaxDB or PostgreSQL or Interbase/Firebird or ?
Hello. I have been tasked with evaluating open source databases for a large upcoming project: e-commerce, B2B, high availability. The O/S is most likely to be Linux, although FreeBSD could possibly be used (lower probability). So far, it seems that MySQL, MaxDB, PostgreSQL, and Interbase/Firebird are possible candidates. Does anyone know why we should or should not use any of these? Does anyone know of other possibilities? Id very much appreciate hearing your comments and recommendations. I have only recently started these evaluations. BTW, my own background is from the Oracle DBA world. MySQL is certainly popular and seems to have very good performance, but I am concerned that the lack of Triggers, Stored Procedures, User-Defined Functions, and Views (to a lesser degree ) will be a disadvantage. MaxDB appears to be more feature-rich and possibly more industrial-strength. How does its performance and stability compare to the others? Many Thanks. Jerry Apfelbaum Toronto -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
