Slashdot Mirror
MySQL 4 Declared Production-Ready
Simprini writes "After absolute ages of testing MySQL 4.0.x in various versions of BETA through GAMMA it looks like MySQL AB finally released MySQL 4.0.12 as ready for prime-time production use. I know my company has been waiting for a long time for this because our customers absolutely refused to use beta releases of this product. Query caching here we come."
MySQL 4.0.x in various versions of BETA through GAMMA
Uh oh.. I flat out refuse to use code that isn't ALPHA... well at least as an OS on my Windows machine.
Trolling is a art,
I can't wait to test it out... with all the hype it might even give my Postgres a run for its money! It's so nice to see competitive databases freely available. Hand someone a PHP/MySQL book (there's tons) and let get cookin.
Now to start some benchmarking...
--------
Free your mind.
Oh that's reassuring!
Whatever happened to them releasing the Command Center (?) software for OSX in February ... 4.0 ... 4.0 ... pfft.
Does MySQL still do table-level locks and no foreign keys? If so, I'll stick to using a real database.
According to the MySQL site (manual) Gamma status was granted in December with version 4.0.6.
My MySQL 4 worm is also ready for your production environments. Get ready, sucka!
Now if I could just get MySQL 4.Anything to compile and run correctly on Solaris 2.5.1..
Most attempts thus far have ended in failure of libraries to link correctly or binaries that segfault...
Why?
We have been using 4.x for Slashdot for some time now. Its quite stable and the new query cache seems to be working for around 13% of our queries, which has been a great boon for us.
You can't grep a dead tree.
What other features might there be?
--------
Free your mind.
To reply to the original poster - MySQL 4.0 has not been beta for a long time. 4.0.x releases have been labeled "gamma" for many months.
I have been running most of 4.0.x releases on live servers without any problems whatsoever. Running 3.23.x today is equivalent to running a 2.2 Linux kernel.
Select * from "http://www.mysql.com/downloads/" where "version" = "mysql-4.0.12"
------
Random, useless fact: I type in startx entirely with my left hand.
MS SQL server has much better sharing capabilities.
According to the crash-me comparison page, there's not much differences with the previous stable release. Some current benchmarks would probably be more significant, performance-wise.
have you been defaced today?
Having had experience with Oracle, MySQL is still lacking a lot of the plush features that Oracle has. But, having run it for about 3+ years on my own slash type sites, the thing is ROCK solid. The feature set in MySQL increases with every version.
Now, look at the costs. Oracle - an Arm, leg, and your children. MySQL - Free. Gee, that is a no brainer.....
It's either on the beat or off the beat, it's that easy.
I moderate therefore I rule!
--
Do you really think it odd for a customer to refuse to use a beta of a program that their entire company is centered around?
Lord I hope not. I gave up on Perl after the Nth Camel Book.
...It's YourSQL
LOL
MySQL is already faster than postgres at the limited amount of things MySQL can do.
MySQL, even with 4, still lacks numerous features found in Postgres. Looking at MySQL's site, it won't have most of these features until 5.1 comes out.
Someone brought this up in the last MySQL thread, but there really haven't been any *recent* MySQL vs. Postgres comparisons.
I'm excited for 4.0, we'll probably make our slave a 4.0 box today.
soloris and linux average 6-8 megs?
Error : no rows returned.
We need views. While much of my work can be done in MySQL, until there are views I cannot switch completely from SQL Server 2K. Too many PHB's that need features like views to be overcome. Must control fist-of-death!
The preceding comment has been reviewed and declared to be compliant with HIPPA Phase II regulations.
We are also using MySQL for many web projects, but to create a complex CMS the future features in MySQL (that also exist in other current database systems - like postgreSQL and probably others) are needed.
We have initially created Komplete - http://komplete.interakt.ro/ only for PostgreSQL, and our users attitude indicated us that MySQL should have been supported. So we are releasing now the Komplete Lite version (GPL), for MySQL - but it's a real pain to simulate subselects, real unions (emulated with temporary tables now), cascaded deletes and stored procedures.
The speed is quite similar, but PostgreSQL is still much better for complex web applications.
I work at at the tech development dept. of a major car company and this is great news. We are finally able to throw MySQL onto production servers and give Oracle the boot for small RAD webapps.
What I've heard from MySQL officials in person is that MySQL 5.0 is set to be released late Q4 this year. Then stored procedures, sub selects (4.1) and constraints should be ready for primetime, then we talk real heavy enterprise applications. Hope they keep the schedule! =)
Well, Monty and the rest, Good Job! Keep it up!
Girls are strange. They don't come with a man page.
-- Michael Mattsson
This is great that it is ready for production use, are there any sitess out there that go over the pitfalls and things to look out for with upgrading from 3 to 4?
However in the upcoming 4.x releases there were quite a few cool features for the average joe, such as ability to change mysqld options without restarting the server. There was another proposed feature that was cryptic to me: it looked like it would provide support for database redundancy. Is this correct?
If it's good enough for such a reputable fraternity, it's good enough for me.
Best Windows Freeware
Foreign keys -- Pass
Replication -- Pass
Triggers -- FAIL
SO close.....
Software Wars
IMO, the very best new feature of MySQL 4 is multi-table deletes. No more having to query/for each in/delete type constructs across many-to-many relationship tables.
I've been using MySQL 4.0.5/PHP4 on RH8.0 without problems to date. Granted, only on a non-critical intranet for our small (70) office, but still, no problems.
There is no need to use a SlashDot sig for SEO...
doesn't gamma come right after beta? more like beta and gamma or alpha thru gamma.
now if it had gone through test releases beta through omikron...
"Karma can only be portioned out by the cosmos." -- Homer Simpson
48 hour count down well under way.
Just mirrored the file on Freenet, you can grab it here.
Try Firebird, I have switched from MSSQL 2K to Interbase/Firebird with success. It has all the good features from MsSql (Stored procs, triggers, views etc.)
Does PostgreSQL support point in time recovery and file system backups while the database is running? If not, I'll stick to using a real database.
any word on whether we have subselects yet. I couldnt see it in the change log. They are dearly missed..
The war with islam is a war on the beast
The war on terror is a war for peace
But, as the MySQL developers say, nobody appears to want views badly enough to finance their development. That's how MySQL got as developed as it is now--enough corporate users needed specific new pieces of functionality that they could pay MySQL AB to build them. It's one of the best open-source business models I've ever seen.
It's easy to complain. It's easy to preach. I'd rather see you pull out your (or your bosses') wallet.
As for myself, while I'd love the convenience of views, I'm not constrained by legacy code and I don't mind the mild programming burden their absence puts on me.
I know people really dig MySQL and everything, but seriously, PostgreSQL has all of those features, and it's ready for production use NOW.
Gabriel Ricard
What does 4.0 have that msyql-max 3.23 not have? I switched to mysql-max so I could use InnoDB.
http://www.windmeadow.com/
Yes it does.
Just because PHP doesn't let you write a proper database access layer doesn't mean that a database NEEDS those features to exist.
I've written multiple CMS-like applications, and seen several commercial systems which do fine without the features you listed...the key thing is that they are written in Java or even Perl so they can figure things out on their own.
Look in the mirror before throwing stones.
I must say I agree with you. Why the hype around MySQL when Postgres has all those features ready for primetime. I dunno.
Girls are strange. They don't come with a man page.
-- Michael Mattsson
I am wondering about caparative processing speed myself. MySQL has always been the speed leader in Open Source databases. Now that they have added some industrial strenght features (like ACID compliant transactions and row level locking) via InnoDB, how well does the speed difference hold up? Is it still way faster, or just a little faster or not faster at all?
If the difference isn't significant then there is no reason to choose MySQL over PostreSQL for applications requiring high levels of data integrity. Especially when PostreSQL also brings you stored procedures, views and so on.
- -
Are you an SF Fan? Are you a Tru-Fan?
What about integrity constraints, foreign keys, interval datatypes, full outer joins, subqueries, set operations, VIEWS for god's sake, and triggers? Too hard?
For cryin' out loud, half of these missing features put the "relational" in "relational database"!
First of all, kudos to the MySQL team for atleast getting as far as they have. Just because I'm not fond of thier product, doesn't mean they don't deserve credit.
I've been banging my head a little on this one too trying to figure out why so many people are pushing MySQL and not something stable and complete like PostgreSQL? After all, PostgreSQL has triggers, stored-procedures, functions, referential integrity, and tons of other features to make your life easier. You may not need all of these features now, but can you honestly say your app won't expand and require advanced features?
Is it the MySQL marketing engine? Does PostgreSQL sound intimidating? Are there actually technical advantages that MySQL have over PostgreSQL? If so, what are they?
The most common argument I've heard in defense of MySQLs lack of basic features is: "It's good enough for 90% of the problems out there." However, everytime they implement a basic feature that every other RDBMS has had for decades (like UNION), people respond as if MySQL is getting close to be taken seriously.
Secondly, In my experience, I've found that 90% of the applications I've worked on end up using those advanced features sooner or later. Those features usually save a tremendous amount of time I would have otherwise had to spend writing code to make my database jump through hoops. In addition to saving time, there a lot of features which simply allow me to make my applications more useful or intuitive to the end user, which is the whole point.
Am I missing something here, or is the Emperor not wearing any clothes?
"Communism is like having one [local] phone company " - Lenny Bruce
As one of the testers of the 4.0.x line, I can say that MySQL AB should be proud of this release.
I've seen some posts here about instability and data loss, but I assume this is from the Postgres 'but WE have the better database - everybody look over here' crowd. I've done some pretty stupid things to our MySQL box - like running Imagemagick's 'convert' on over 200MB of images and running the box out of virtual memory, which made the kernel start killing processes - starting with MySQL. When it came back up - no data loss at all. InnoDB recovers VERY well from this sort of thing.
MySQL also handles multiple MS Access clients far better than MS SQL Server. We have over 10 tables now which basically can't be accessed if placed on SQL Server because of the way MS Access grabs record locks willy nilly. If I place the tables in MySQL as MyISAM tables, I get a little bit (3 or 4 months) use out of them. Then record locking issues start up again. So then I put them in MySQL's InnoDB tables with row-level locking, and I've never had any further issues with those tables. Quite impressive.
And as well as being 100% stable for me, MySQL is so incredibly fast... When we convert standard Acccess queries to pass-through queries we get up to 15x speed increases. We actually use pass-through queries as substitues for views. Works nicely.
The tech support it great. When I was having type-conversion issues with our pass-through queries I got responses from the developers on the same day - often in the same hour. And we haven't paid for any support - just downloaded the source.
The lead-up to MySQL-4.0.x being stable has felt like the lead up to Mozilla-1.0; everyone using it felt it was ready, but the developers insisted on thoroughly testing everything to make sure they could stand by their decision to declare it stable.
Congrats to the MySQL team. I will be compiling 4.0.12 when I get to work...
I don't mean to start a flame war here, but I have to ask... Why is MySQL so popular when PostgreSQL does more and is also open source and free like beer? Are there any real benefits to MySQL over PostgreSQL?
3 = Sell support contracts
Be careful about this. Some areas, like San Francisco, actually prohibit good ol' boys from coming in and catchin' their Querys. Even in the south, some areas like Chappel Hill only allow Catchin' Querys on a catch and release program. Bummer.
MySQL used to be significantly faster than PostgreSQL, mainly because it COULD be faster because it didn't have to worry about pesky features like transactions. Now that PostgreSQL has been better optimized and MySQL actually has some (a couple anyway) of these more advanced features, the speed difference is not a factor anymore. Now I think it is just a matter of inertia -- since MySql had such a long run, getting people to change is hard.
Why the hype around MySQL when Postgres has all those features ready for primetime.
MySQL is easier to install on a Windows machine is my guess. I know thats the reason my group went with mysql on a project last year. We could not require that our customer installed a Linux (or similar) server.
MySQL doesn't "have these features" - some table types "have these features." The same MySQL server can use any of MyISAM, BDB and InnoDB tables; the difference is MyISAM doesn't have transactions, but it's twice as fast as InnoDB which does.
I really want to use postgresql but i've tried it and its really unfriendly to use. :-)
Maybe i'm dumb but dumb people need databases too
Bush and Blair ate my sig!
Now, I'm not sure if the middleware/library support is the same, but PostgreSQL runs pretty well on Windows.
"Communism is like having one [local] phone company " - Lenny Bruce
lets see, which DB is ACID-compliant? Whch supports relational operations, foreign keys, views, subselects, etc?
That's right, the answer is "not mySQL." Now go back to your toy databases and let the rest of us get some work done. No brainer indeed....
I've been using MySQL 4.x for a huge stock market analysis program I've been pounding out as my life's work, and unfortunately, I'm finding in some respects, it's slower than MS-SQL Server (same machine, dual boot):
Number of listed NYSE symbols: ~3200
Number of listed NASDAQ symbols: ~4000
Number of total stock quotes from 1980 to today, each including open, close, high, low, and volume: 6.2 Million
Time to fully index those 6.2M records on SQL Server: 0:42:33
Time to fully index those 6.2M records on MySQL: 2:12:27
And using Python...
SQL Server time to pull all quotes within a given date range (no indices): 1min, 28sec.
MySQL time to pull all quotes within a given date range (no indices): 7min, 18sec.
Has SQL Server used implicit indices I am not aware of?
"Twice half-assed makes an ass whole." --Solomon K. Chang
The word on the grapevine is that Pg 7.4 will have a standard, out of the box replication mechanism. There's some stuff in the 7.3.x tree for this but for now it's all development-only, there are two "competing" mechanisms akin to the linux 2.4 VM situtation...
In most cases when you need to do multi-table delete, this should be done with ON DELETE CASCADE rule (welcome to real *relational* databases). Which is also present in MySQL 4 -- very good!
Same for updates -- ON UPDATE CASCADE.
Manual multitable updates could be very handy, though...
And you can use it for commercial projects for free, unlike MySql and MSSQL.
We too are migrating from MSDE (MSSQL embedded) to firebird. No problems so far.
"I think this line is mostly filler"
"aluminum" uses both hands (all the right except the "a").
Now, how about "typewriter"?
Tuus crepidae innexilis sunt.
Win32 or Unix?
While much of my work can be done in MySQL, until there are views I cannot switch completely from SQL Server 2K.
Why the hell would you even try to switch to MySQL from MS-SQL when there are such open source offerings as SAPDB, PostgreSQL, and Firebird? Oh well, I hope you enjoy the wait for MySQL 5.1.
They can really only do two things: hide columns for security reasons and simplify queries by hiding part of that query.
In general, the first applcation is usually better served by planning, data seperation, and implementing a good security policy. There are times when views are a legitimate solution to problems of this type, and a database is definately better for supporting them in such cases.
The second case, however, is commonly misunderstood by developers, who think a view is some magic incarnation of a snapshot. I frequently see views based on views based upon views, frequently each of which is a poorly-optimized sql statement. The developers seem surprised that performance is abysmal in such cases. A view is a just a convenience, a means to "store" a query, and run that query each time the view is accessed, nothing more.
Since I spend a fair bit of time trying to fix performance problems reusulting from the many myths and rumors about views and their ubiquitous misapplication, I'm not sure that I would consider their omission a bad thing -- it might teach developers better coding habits. . .
I've been extensively using MySQL 4 for over one year on very loaded production systems.
.
It has actually always been faster and more solid than the 3.23.x series.
I only had some small issues with InnoDB (the same issues were in 3.23.x as well). But the InnoDB maintainer, Heiki Turri, is someone that really cares about bug reports. All reported bugs were immediately fixed.
The query cache is efficient, and the fulltext indexing was greatly enhanced (if only it worked with InnoDB tables...)
I've not installed any 3.23.x version for a while, and I'll never go back.
Probably a lot of system administrators will wait. They will read that MySQL AB blessed 4.x as production-ready, but they will wait, as if it was an 1.0 version that still needs some maturity.
It's not. MySQL 4.x has already received a lot of testing, and it is already being used on large production sites. Just read the MySQL mailing-lists.
Upgrading from MySQL 3.x is also easy. You only need to run a little script to upgrade the grant tables (and even if you don't, everything will work). No need to export/reimport the databases. So upgrading is straight forward.
{{.sig}}
I keep hearing how postgresql has "caught up" to mySQL plus has all kinds of wonderful features, yet my own testing shows postgresql to be a fair bit slower when you have about an equal mix of selects and updates with a few inserts thrown in here and there. For example, 82 seconds for postgresql, 35 for MyISAM and 49 for InnoDB (not MySQL 4 however) Yes, the postgresql had fsync turned off and the table vacuumed (full & analyze.)
I'd love to use Postgresql, but with mysql adding all these features plus being so much faster, it's hard to move that way, as the fancy features are things I'd use but don't really need. (Previously foreign keys were a reason for me to switch)
Or is there a way to make postgresql keep up to mysql so I can justify using it and right away get access to those cool things like views, triggers, functions, etc ?
Linux and windows 2000, but we used it more on linux.
"I think this line is mostly filler"
This is like ext2 vs. ffs. One is safe, one is fast. A lot of speed is gained by running things multiple time so the optimizer has a chance to do the work. Views and stored procs can also speed things up.
Maybe PostgreSQL justs a name change and a new PR department. Many people don't even know how to pronounce PostgreSQL. Consider the name's awkward evolution: Ingres --> Postgres --> PostgreSQL. They've already got a decent logo (the blue elephant). Presumably, the elephant never forgets your data?
Looks like the PostgreSQL team is taking an active role to update their PR: A Call for PostgreSQL Case Study Participants
cpeterso
read: especially as it concerns web sites, its hard to get users to upgrade from a good or engrained product...
If it does the job, why switch. If I ever find MySQL can't handle something that I need to do with an app, then I will certainly start looking at Postgres. Right now, I'm not concerned with a lot of the features that postgres has. I'm using it to do simple table queries in small apps. I first started using it because that's what the hosting company had installed on my web server. So I used it. I've been using it ever since because I haven't had any problems with it. - keith
-- Does anybody know where the 'any' key is on the keyboard?
What kind of a driver do you use?
The hype around MySQL is that it is quite fast and more than adequate for most Web applications. Why would I want the bloat of PostgreSQL (or other "primetime" database) when MySQL does the job well?
Many people seem to misunderstand the goals (in my opinion) of the MySQL team. They aren't there to compete with Oracle, for instance. Their database was designed to have a small footprint, work extremely fast, etc... For most of my Web applications, I don't want a full-featured database - there is just too much stuff to get in my way.
Are you running both MySQL and PostgreSQL with the same optional constraints?
For example, what startup settings (optional parameters) are you using for PostgreSQL?
By default, PostgreSQL uses very conservative settings that favor reliability over speed (like not buffering any writes to disk).
Just flip one or two simple switches in the startup parameters and you might find HUGE speed boosts in PostgreSQL because it would be running under similar constraints as MySQL.
Also, are you using PostgreSQL 7.3.2 or an older version? The 7 series gained a lot of optimizations...
I've found that 90% of the applications I've worked on end up using those advanced features sooner or later. Those features usually save a tremendous amount of time I would have otherwise had to spend writing code to make my database jump through hoops.
If you are coding against MySQL with Perl it is always just as easy to do what the trigger or stored procedure will do for you in code in a very short amount of time. That is why none of the real users of it could care less about such features.
I'd be satisfied if mysql supported just the easiest cases of views. i.e. no update/insert/delete, no joins. I'd still gain the abilities to restrict the set of rows/columns which can be seen by certain users, and to group similar tables (using UNION).
Are moderator points awarded for stupidity? Too often when you see a comment from a registered user that has a score of +3 or greater, it is dead wrong. Wrong, like the parent post. Why would a moderator give it a +4? The binary MySQL distributions all use static libraries. How could this be the difference between the two? Hey poster, how about RTFM before spouting nonsense? Hey moderators, how about RTFM before making asses of yourselves and making /., yet again, a little less useful.
Since when does Postgres support hot backups? Reference?
There's really not enough information here to help you out very much: database optimization is a complex task. However, the PostgreSQL mailing lists (such as pgsql-performance) frequently handle questions about performance tuning -- if you'd like to improve the performance of PostgreSQL for your application, my suggestion is to post more details about your particular configuration and workload to one of the mailing lists.
However, two easy tasks you can do to improve performance are too tweak the configuration (for example, increase the default shared_buffers setting), and upgrade to the llatest release of PostgreSQL (7.3.2 is current).
I wanted views, stored procedures, triggers, etc. I wanted them badly enough to pull out my wallet and finance them. I wrote a check to Microsoft and bought MS SQLServer 2000.
The truth doesn't care what I think.
MySQL makes a fucking awesome, free, fast as shit persistence layer for people who need to store data in tables. If you want all that other shit, use something else. In a real app I was working on (using JDBC), we were developing on MSSQL cause that was company policy. Switching the other end of the JDBC connection to MySQL and changing the driver to org.gjt.mm made the app roughly 2X faster. No recoding at all. We had tried I think 3 JDBC drivers for MSSQL and had gotten vastly different results, so that's probably a huge part of it, but for someone who needs to use some sort of code to store large amounts of tabular data and access it quickly (in our case, it was actually the insertions that were grossly faster) without using a lot of other features, MySQL is a really great product.
I sure hope my boss doesn't hear about this. I told him we weren't using ANY pre-release software on our production boxes. ;-)
We run postgres and we're doing our damndest to get rid of it. We have some databases that get 50-100% data turnover rate daily, making hourly vacuums essential to not having the Ever Expanding Database problem. Not to mention that vacuum doesn't clean up indexes, so you'll also have to re-index periodically if you don't want those to grow to thousands of times their optimal size.
I should probably say that such reindexes require full table locks, so you could get contention issues under heavy load when reindexing your database. Mysql gets by this by making indexes in a temporary space, and switching when the index is done. This means I can select from a table, with full benefit of an existing index, even while I change an index, or even redo the index. Not that I have to... mysql doesn't require vacuum or reindex to avoid continuous linear bloat.
So... we don't like having to babysit our database to get good performance out of it. We're willing to work around lack of foreign keys to avoid having to do full database import/exports on a weekly basis, and multiple hourly cron jobs to make sure we don't randomly fill our disks. Faster? Slower? Who cares. Postgres is just too annoying to use in production.
Read: Rabbit Rue - Free serial nove
where do you get your data from? Is there a single, free place to download price data for every NYSE and NASDAQ stock since 1980?
its hard to get users to upgrade from a good or engrained product...
Try the upgrade before saying that. Unlike Apache2, the upgrade is painless. Though you MAY have to recompile your user-defined functions (which 99.9% of people don't use anyway), I'm not sure.
Stored procedures run inside the database server. This means they can be hella fast (compared to doing the same operations externally by sending SQL and results back and forth). Also the language for stored procedures (Oracle's PL/SQL or Postgres's PGPLSQL or whatever it's called) can be typechecked against the database schema, so you get immediate notification if you try to add a stored procedure that uses invalid column names or whatever. Finally, the code for stored procedures can be compiled just once and then stored as bytecode inside the database.
Really it comes down to: trust the database developers. They have very long, grey beards and they know all sorts of stuff about making things run quickly, so if they have gone to the trouble of implementing a programming language that runs inside the RDBMS you can be pretty sure it will give better performance, and possibly better error reporting, than doing the same job with an external language and a database access library.
-- Ed Avis ed@membled.com
Yes, it's good that there is a small, easy-to-set-up database that may not have all the features of Oracle or Postgres or DB2, but is good enough for many applications.
What's annoying is that every time MySQL adds some new feature which real RDBMSes have had for a long time, it gets lots of hype and publicity, while free databases which already full ACID properties (I think this means Postgres nowadays, and most likely SapDB too) don't get nearly as much coverage.
Perhaps this is a case of more joy over one sinner who repents, than...
-- Ed Avis ed@membled.com
Postgresql has the *intellegence* built in. You can write all sorts of georgous functions to do stuff, especially if, like us, your shop uses several languages... PHP, Perl, Java, Python, C++, etc. Why replicate your data related logic in every client language?
Transaction support and file/record locking are the least of your problems. If you do serious database stuff, at some point, you are *going* to want VIEWS, TRIGGERS, RULES, and STORED PROCEDURES (functions). Having this functionality in the database engine, instead of in your code makes a heck of a lot of difference when the time comes to scale.
Coming from a MySQL backgroud in a multi-language shop, we clearly saw the limitations, and decided to switch the entire database platform over to Postgresql a year ago. We haven't looked back since.
Also, I dont think the developers will be able to make MySQL into an *ACTIVE* database anytime soon, simply because of the current architecture of the system as it is now. They are going to need a heck of a lot of system tables and new code, to accomplish even the simplest stored procedure functionality.
I can see VIEWS being a quick hack, but going beyond that with MySQL as it is, will be quite a stretch, and I don't believe they will finish those features until perhaps the end of next year, as it will require almost a complete rewrite of the base engine IMHO.
Newsfollow.com
Now there's an opening begging to be taken! (dons his asbestos undies)
MySQL has only ever been shown by anyone but MySQL AB* to be faster at very simple mostly-or-all-read-only tasks, even with row-level locking. PostgreSQL, for example, multiplexes writes - which effectively removes even row-level-locking delays. As soon as you pile on the load, get complex in your queries, or start doing a serious amount of writing, the bencharks go all wahoonie-shaped.
On top of that, innoDB is a bandaid to try bringing real SQL features to MySQL, which leads to two observations:
I'd also be interested in seeing Firebird and SAP DB in any benchmarks done. And MS SQL Server, if you're in a place where the NDA-style thou-shalt-not-publish-benchmarks EULA clause doesn't matter. I do like choice, but most firmly believe that some of the attention falling on almost-GPL MySQL would be better spent if devoted to some of the more capable really-GPL alternates.
* now who (M<cough>ro<cough>t) does that remind you of?
Got time? Spend some of it coding or testing
When I design a view in MSSQL, I can copy and paste the query in my code and use it. That is exactly what I always do. MySQL supports joins correct, so it it just that you cannot save the view that makes so many get their panties in a bunch? Can't these people just write the query? If you need it stored bad enough, can't you just write a function to call your 'view' sql query?
What?
Point 1:
PostgreSQL lacked many of those features just 2 years ago. Did you ever try to use it before 7.0? You had triggers, but no cascading or outer join.
Point 2:
It was slower, and you had to recompile (according to the readme) to get it to use more than 32 (or was it 64) simulatious connections. Not that that should be a big problem, execpt for the fact that posrgreSQL had serious problems closing a connection after use.
Point 3
(Much) better support for mysql than postgreSQL in PHP. You can argue all you want that php isn't something you would like do develop with, but a whole lot of websites use it.
Point 4:
If you already have started using mysql for a project, it is often more work to change DBMS.
Point 5:
Most ISPs support mysql if they offer hosting on linux servers, and sometimes on ms servers as well. I've not found one ISP (in Norway) who offer PostgreSQL. Our company ended up looking quite stupid when we couldn't find a ISP who would host the site we had developed for our customer. We ended up having to place a server in a server farm somewhere, and admin the server ourself (this was while posrgres was in a 6.x version, after 2 years we tried again after 7.1 was released, but noone were able to provide it). The universities I've attended or know of offer mysql for all students, and oracle for (some of the) comp students.
So the 4.0 release are great for all of us who for some reason *have* to stick with mysql for most of our work. I prefer posrgreSQL in most cases, but if it's web related, I don't allways have that option.
- Ost
---- Sig. gone.
For me, NextGreSQL is much easier to pronounce :)
Less is more !
Why we use Mysql... (and use it for for our customers)
1. quick, easy setup, with easy to find documentation. While I'm sure this will send (some) people howling... I've not seen documentation to match for PostgreSQL, or SapDB (Firebird's docs seem ok).
2. Easy to manage. I don't have to stop my mysql db's to do maint on them. (yes, you can do a sorta vaccum on pg with it running, but IIRC, it only actually releases the space if you stop the db and do it, maybe I'm wrong here, but hey, until we can find docs that explain it better...)
3. Full cross platform support. Doesn't matter if it's windows or solaris, or linux. Mysql runs fine. Last I checked PG only ran on windows with Cygwin. Not an option for production enviroments.
4. Plenty of easy to use gui's. DBA's love'm.
5. Support by pretty much every multi-database COTS application we mess with, be it Demarc or the odd php webook.
That being said, I'd love to get views, full sub selects and joins in mysql, or someone to put a page together that gives the info in an easy googlable site like mysql.com.
Bugs Bunny was right.
We may not want them to, but data requirements sometimes change, and views make it really easy not to break everything in your code when making changes to an existing schema. Sure this is still a "convenience," but a significant one at that.
I prayed about it, and God said, "Don't do it!" But I thought, "I know better."
That's why I and most others start using MySQL in the first place. You can keep using it for a long time with no reason to HAVE to switch.
Of course, then later you decide to learn a new database just to expand your knowledge base. That's when you start whacking your head on the table when you realize how much easier a real relational database could have made your life for the preceding several years.
It's funny to watch the process. It always seems to follow the same course.
I left MySQL behind. Once you use a real relational database, you'll never go back to the kiddie toys.
3 = make the JDBC drivers GPLed to make developpers so confused about the differences between LGPL and GPL applied to Java code (there is no difference between static and dynamic linking in Java) that they have to buy a non-GPL version of the driver just to make sure they don't violate the GPL
After all, PostgreSQL has triggers, stored-procedures, functions, referential integrity, and tons of other features to make your life easier. You may not need all of these features now, but can you honestly say your app won't expand and require advanced features?
Gimmie a break dude. I'm sick of hearing all this stuff about triggers, sub selects, and stored procedures. I can honestly say that no database really needs these things.
In my 6 months of professional development at a 3 man shop I think I'm perfectly well qualified to say that no RDBMS will ever need these futures. I can't possibly imagine a design so fubar that it would EVER have to rely on the RDBMS to enforce such rules. That's what application level code is for! Sheesh!
Well, maybe such things would be useful if you had more than one application pointing at the same database... or if you planned to maintain the DB's integrity over any length of time. But that kind of shit never happens in the real world. It's a made up story of Slashdot posts and database classes.
Given that text doesn't relay voice inflection very well: The above is sarcasim.
to possibly replace some Oracle databases.
Any gurus (or detractors) want to list the downsides?
- no subqueries yet. Ok. Not the end of the world
- are multi-column primary keys still a performance dog?
- how is stability? That's probably what you hear most about w/regards to MySQL
- triggers and stored procs; back-end-logic==bad IMHO
I just ordered Mastering MySQL 4 to speed the jump between Oracle and MySQL. Anyone used that book?
I'd be really interested in hearing some frank and honest appraisals.
"equal mix of selects and updates with a few inserts thrown in here and there. For example, 82 seconds for postgresql, 35 for MyISAM and 49 for InnoDB (not MySQL 4 however)"
Selects, updates and a few inserts are 89/35/49?
What are you running this on? A 486?
Are constraints enabled? Indexes? How big are the tables (rows AND columns). Why not test all selects, then all inserts, then all updates?
Spurious benchmarks like these aren't of much value unless some background is included.
Given that text doesn't relay voice inflection very well: The above is sarcasim.
:-)
*phew*, I had almost submitted a lengthy piece of text before I saw that last line.
Please use the <sarcasm> tag in the future.
Luckily, in this case, MySQL 3 is not good, so they'd just have to get past the engrained(sic) part.
Can you explain, in layman's terms, what a "real relational database" actually is? And why MySQL isn't one, and what it would have to do to be one? And NOT by saying "well, it's got to have wvcsde and werdfskfk!" I mean, I don't know too much, but people have got to be able to explain these operations, and the theories behind the data structure, in better ways than most people here are doing, reffering to various features. Not all of us here are geniuses, or work with databases regularly. :)
Funny, I use some of those "primetime" databases, and the extra features never 'get in my way'. It's real easy to just not use them when you don't need them. Sometimes I don't use any of the 'fancy' features on some databases, but they are always there, and I end up using them in a lot of cases on things I never would have thought about back when I was MySQL only. When you don't really know what the extra features are/do, it's really easy to believe you don't need them and wouldn't use them. Once you understand them, you can't believe how much easier they make the coding for tons of projects you do.
Many MySQL users prefer it, just because they don't really *know* what it is they are missing.
(This abbicus works fine, It calculates all my numbers for me and I don't need any battery packs, AC power supplies, wires. Hmm, maybe I will try that computer thing just to see what it's like..... OHHHHH! I get it!)
Ideally I would design the system in such a fashion that views are not needed. Real World, however, I am stuck maintaining existing systems. I could port those systems to MySQL cheaper (time/dollars) than I could rebuild them correctly.
The preceding comment has been reviewed and declared to be compliant with HIPPA Phase II regulations.
It's also easy to say that I should use my (bosses) wallet. To whom do I write the check? How much value will I get for $150.00? What is the ROI? My PHB's are hot on my case. Will I see views in MySQL 5.1 if I pay MySQL AB the equivalent amount of the MSSQL7 license and CAL's? Is it worth it to my PHB's? Nope. Not even at half. There is a value to MySQL but that value is far below the "real" value of MSSQL7 when MySQL remains functionally below MSSQL7.
The preceding comment has been reviewed and declared to be compliant with HIPPA Phase II regulations.
Distributed partitioned updatable views. It's nice when you have 20 servers that each serve up a single view which has data from each of those servers in one place that permit the ability to update the values back to the originating server. I guess that's a useless feature then. Better to write a half-a-ton of code to do it manually.
I had the pleasure of arguing what a view was with an Business/Systems Analyst of a company I worked for previously. He kept swearing up and down that Views were basicly stored indexs of query results.
Our boss had to straighten him out on it.
But hey, I was just the 'programmer' on the project.
I have used FreeBSD since the linux 2.0 days. FreeBSD was lightyears ahead at the time. I switched back and forth between the operating systems because Linux was more cool and web documentation all touted linux. The Linux distro's were easier to use and more people used them then FreeBSD so I used Linux for awhile as well.
FreeBSD back then had a better VM( still does), better tcp/ip stack( still does), better package management( still does except gentoo), better scsi support, raid card support, volume management, threading, etc.
Its not just the proprietary world where this happens. The most popular opensource apps also reign over technically superior ones.
As mysql gained popularity postgreSQL gained as well. Just not as much. Same is true for FreeBSD. There are a ton of kernel developers for FreeBSD who came from linux and prefered freebsd over linux for a variety of reasons.
Keep in mind Mysql is faster for simple benchmarks and doing things like inserts. Many hackers simply wrote simple perl scripts to see how many inserts a second both could do and found mysql faster. They then falsely assumed it would also be a superior RDBMS.
I heard in Japan the situation is the opposite. If you walked into a bookstore you would only see postgreSQL books and few mysql. Hype is a major factor.
http://saveie6.com/
"a company I worked for previously"
:)
I wonder if getting your boss to correct people higher up then you on the pecking order had anything to do with that
*phew*, I had almost submitted a lengthy piece of text before I saw that last line. :-)
:)
Me too...
I guess you an me are easily trollable...
"Communism is like having one [local] phone company " - Lenny Bruce
Your reasons especially helped give me a little insight as to why people are choosing MySQL over PostgreSQL and Firebird.
"Communism is like having one [local] phone company " - Lenny Bruce
Views make it possible to sort out complicated data relationships ONCE (preferably by the most experienced programmer in the house) and then access the results over and over. As long as the view stays valid, any query against the view can be assumed to be valid. The shop where I work (Oracle 8.1.7, I think) has very complicated OLTP data structures--great for keeping everything sorted out during transaction processing, but abysmal for reporting. We have some views that use 20 or more tables with complicated sub-selects, computations, unions, and validations. If we had to rely on the coders to get that stuff right for every report or query request that came into the department nothing would get done. With a view, the report writers just query the views for their data. It's not always blisteringly fast, but at least we don't need Einstein to code every simple data or report request that comes down the pike.
Your point about views-on-views-on-views bogging things down is well taken. Using just a few well designed views and enforcing their use will at least allow the DBA/Data Architect/Programmer to find the right target for optimizing.
As far as their necessity in MySQL, views are a huge help for inexperienced people to get complex data into simple and usable form. If the data structures are simple to begin with, and if there's no access to the data outside of the application it's created and stored in, or if the programmer has already supplied all the outputs that are required for the application, then views are superfluous. Otherwise they can be a real time-saver and save a lot of programmer time/aggravation/skill.
Everything I've ever learned the hard way was based on a statistically invalid sample.
As a postgresql user, one thing I did notice is that postgresql uses the old one-process-per-connection style of daemon whereas mysql uses threads. Postgresql tends to fall apart under high connection concurrency whereas mysql might not due to its use of threads.
maru
No. :)
Wanting to work for people I didn't have to correct had everything to do with it.
You allegedly an Oracle DBA and don't understand the usefulness of views? Ok, I will now assume you are some junior level flunky who happens to report to somebody who manages the real Oracle DBAs. Have you ever heard of a materialized view or in your "fantasty" dba world do you just not really understand the database you purport to administer. I'm sorry, but I can't really take you seriously when you make such an ass-backward, uniformed statement. Either you have now clue about how Oracle really works, or you are a liar. Either way, I don't care. You are a clueless nitwit who should go back to administering Microsoft Access and MS SQL Server. And "Java APE", what kind of dba would use that as their username? No Oracle DBAs I know. Please find a job outside of IT you clueless moron. In case you are wondering, this post is brought to you from somebody who has actually administered Oracle versions 7 - 9. Please go to hell, you go to hell and you die...
Mother bastard, I'm too drunk to spell correctly. Please excuse my spelling in the parent post, but if you had consumed two liters of 11% beer you would understand...
You are a FUCKING moron.
Why ?
Because one can use and MODIFY any GPL software
till one goes mad. GPL allows modifications
WITHOUT requiring REDISTRIBUTION.
It is only IF you modify GPL code AND you
redistribute your modified code, THEN you
have to publish the source for your changes.
DO YOU UNDERSTAND THE DISTINCTION ?
So, yes, I can use and modify and emasculate
the GPL'ed JDBC driver to my hearts content
as long as I use it within my company. If
I redistribute the driver, THEN I have to
make my changes public. But I and most other
companies are not in the business of selling
JDBC drivers so why would this be an issue ?
No recoding? You had constraints and triggers and you hadn't even used them? Good thing employers can't identify you from that admission.
They're mostly about consistency--there are certain changes nobody can make (no matter who wrote the client code) because the resulting database state doesn't make sense. Some canonical examples:
'Cause Windows sux0r. :D
/. masses*
*tries to hide bulky XP and 98 packaging from unforgiving
why don't you pay them, ya bastard? :-)
I'll tell you why I prefer MySQL. First and foremost, it has a reputation for being very fast, very easy, and very reliable. Not "very fast as long as you're don't get a lot of traffic" but "very fast, even on big-ass sites with tons of traffic, like Slashdot." Eweek did a study that showed MySQL kept pace with Oracle. That's pretty fucking convincing.
But there is another reason: I'm tired of "real DBAs" hijacking every MySQL story with rants about how MySQL isn't for "real work" and isn't a "real database." We got it. We heard it 100 times during all the previous MySQL stories. You guys sound jealous that all these Web sites are successful without your "real database" and your "real DBA" salary. I don't want to deal with a bunch of whiners. That's too much baggage for a "real" database.
1. Docs here. Everything you need is there. Install is straightforward in most distros, and very simple to do from source if you have the inclination to do it.
2. Wrong assumption. You can do whatever maintenance tasks you want without stopping the db. It's been like that since at least 7.0.
3. Nice point, if it affects you. Postgresql isn't native windows yet (it's in beta stage). It runs on all other unices, however...
4. Plenty of those for pg. It's not a problem.
5. This is a crying shame, because if apps used SQL'92 you'd be free to choose database. If an app requires MySQL, then you *need* MySQL, and the whole RDBMS choice problem can't be placed.
If at first you don't succeed, skydiving is not for you
they are doing such a good job and being such good citizens to the OS community, I want to donate some bucks. Since I am only using MySQL for personal use and I don't need support, I don't can't affort that much, but I don't mind a $50 - $100 donation. I just sent them an email to add a donation link using PayPal or something, like Blender or some other projects. .v
I don't believe you really know what triggers might be useful for. They lie beneath the application layer and handle the data. Thus I, as a DB designer, don't have to trust the application programmers to make sure that the data they enter always conforms to the specification. That I can to using triggers.
For example, I can create a trigger that makes a backup of all rows that someone deletes from a table. The application programmer just issues standard DELETE statements and don't have to worry about this.
I believe that triggers are a great way to keep data consistent whenever there are complex dependencies in data. But then again, most DB-users don't know how to design a database, normalize tables or even what to expect of a RDBMS. They might as well use DBM...
Holy cr*p, you really pressed all kinds of buttons there. I was going up in flames right up until the last line of your post.
Jolly good show, sir..! :o)
Remember, there are no stupid questions. But there are a lot of inquisitive idiots.
You only have to code triggers once and they get executed every time when needed. If you do it "by hand", you have to insert this code in every place where the DB would execute the trigger. What if you forget one such place? What if the trigger logic changes? It's much easier to maintain the trigger, than all the code.
What about selling software that requires a JDBC driver?
You wanna know how I chose between the two?
The name, that's how.
MySQL just looks so much simpler to pronounce.
And it sounds 'mine'
Yeah,
:) If more web-hosting companies would supply PostgreSQL, Firebird or SAP DB maby you'll se the switch...
but all those web-hotell providers usually give you MySQL for "free". So we have it and we use it
We are using for a POS-like application made in java using jaybird (firebird's pure java driver). We are not using it for a server.
"I think this line is mostly filler"
Vacuuming is just a side effect of MVCC -- the expired rows have to be kept around so that other open transactions can see them. You pay on the backend for better concurrency on the front end. Even if you were continuously vacuuming your overall query latency and CPU usage would probably be lower than an equivalent MySQL database. There are also 3rd party projects that auto-vacuum... this is something that really should just be built in though. If automatic vacuuming were a configurable part of the base distribution, like the statistics collector, I'm sure you wouldn't be complaining. The sad thing is that it would be such an easy thing to add.
As far as reindexing, I would call that a bug with they way B-Tree indexes are designed. Fortunately, the database is able to reuse index pages if the rows contain similar values. But that doesn't help if you're indexing data that's never similar you're going to be screwed. For example, if your indexed column is a sequence and you delete only the oldest values the db won't be able to reuse that space in the b-tree. A solution would be to use random numbers for your keys since you would get an even distribution over time. It might be worth trying one of the other index types though (R-tree, GiST, or Hash) to see if you get the same results.
Any plans for XML support (compare PostgreSQL, DB2, Oracle, MS-SQL)? XPath queries inside SQL statements are a big win for us.
We run postgres and we're doing our damndest to get rid of it. We have some databases that get 50-100% data turnover rate daily, making hourly vacuums essential to not having the Ever Expanding Database problem. I have a few tables I vacuum every 15 minutes, but I found this really great 3rd party package called "cron". It allows me to create scripts and automagically run them at desired intervals. you should see if it's available for your platform. Not to mention that vacuum doesn't clean up indexes, so you'll also have to re-index periodically if you don't want those to grow to thousands of times their optimal size. I should probably say that such reindexes require full table locks, so you could get contention issues under heavy load when reindexing your database. Mysql gets by this by making indexes in a temporary space, and switching when the index is done. This means I can select from a table, with full benefit of an existing index, even while I change an index, or even redo the index. Not that I have to... mysql doesn't require vacuum or reindex to avoid continuous linear bloat. uh... you can do this in postgresql as well. simply begin a transaction to drop the old index and create the new one. while it's building all of your other queries will use the old index thanks to mvcc. So... we don't like having to babysit our database to get good performance out of it. We're willing to work around lack of foreign keys to avoid having to do full database import/exports on a weekly basis, and multiple hourly cron jobs to make sure we don't randomly fill our disks. Faster? Slower? Who cares. Postgres is just too annoying to use in production. your willing to sacrific data integrity for the sake of not having to do routine maintanance? that's a little scary.
I think you guys presented a good case as for trade-offs.
MySQL - Fast, Well Supported, Good for Simplier Problems
PostgreSQL - Limited Support, Needs more Attention, Suited for Complex Problems
Why "real DBAs" whine
I think the problem is that many DBAs and developers have really come to rely on JOINS, stored-procedures, triggers, etc. I've been using these features very actively for the past 4 years and wondered what I did without them all these years.
In the past year alone, I've written almost 300 stored-procedures, about 1/4 of which are 4 or more pages of code that would have run like a dog has it been written on the client side.
Having done a lot of 2-tiered, 3-tiered, n-tiered design, I've come to realize that the middle tier (business rules) doesn't have to outside the database in Perl code. If you can implement your middle tier inside the database, you'll almost always see a significant performance advantage and not have to worry about writing engine code to handle issues like concurrancy and multiple users.
While MySQL is capable of handling a number of problems, it's very ill-suited for most enterprise business problems.
You should notice that these "Real DBAs" mostly have a fit when people start making claims that MySQL can compete with Oracle. They're afraid some pointy haired boss is going to believe these claims, and is going to ask them to convert thier Oracle databases to MySQL.
As for myself, I see MySQL as a nice step forward as far as performance is concerned, but it's a HUGE step backwards as far as functionality.
In other words, It's a great engine for storing/retrieving lots of data, but it doesn't have the tools for manipulating/querying the data.
For a lot of people, that means not cutting the muster.
Thanks for the comment
"Communism is like having one [local] phone company " - Lenny Bruce
I've been using pghoster.com for a while now. They're pretty damn good and cheap too. Acorn Hosting and Zill.net provide PostgreSQL as well (mainly because they primarily provide OpenACS hosting, which requires PostgreSQL)
Gabriel Ricard
However, having coded in C both for MySQL and PostgreSQL, I have to say that the MySQL docs are clearly better, and that their client library is more feature-rich than PostgrSQL. The MySQL database may lack features, but on the client side it is much easier to get simple things running.
In my 6 months of professional development at a 3 man shop
As soon as I read teh above, I knew he was making a jab at the typical Slashdotting mySQL weenie. ;)
But instead, there's stupid recurring garbage with idiots on both sides trying to explain that one database is better than another. Here's what I think the objective truth is - the fact of the matter is whatever works for you is fine.
If you like using stored procedures, triggers and constraints and think SQL compliance is important, then use Postgresql, and it will work fine for you. If you don't, and you like fast access to your data, use MySQL.
There are use scenarios that one can construct which will make either database look completely ridiculous and terrible (look at some of the comments for some examples). But it doesn't matter, if you can code for MySQL and think in MySQL, it will work fine. If you code for Postgresql and think in Postgresql, it will work fine. I've used both, in heavy and light production environments, and they both have their uses. I've also found scenarios where I can't use either, and have to go to something else.
To all those who say, "But...but...MySQL is just a fake SQL interface to the filesystem!" Well, fine. Where do you store your files, then? I presume, since a filesystem is such a terrible place to put your files, that it's not in a filesystem, eh?
And to those who say, "but, I can SELECT out of MySQL eight hundred bajillion times faster than Postgresql!" Well, fine, but what happens if you try to concurrently insert something? How's your data integrity hold up if some errant SQL inserts data that doesn't refer properly to other tables?
What I'm trying to say is that it's all relative, and trying to phrase things as, "This is the right thing to do, in all cases, for all scenarios" is narrow-minded and simplistic. Use what works for you - and note that a lot of this depends on how you think when you are writing your code. So two different programmers working on the same problem might solve the problem using different databases - and both be right.
A 'real' or more accurately a 'truely' relational database management system does not exist (yet? ever?). Every DBMS out there (Oracle, MS SQL Server, Sybase ASE, MySQL, PostgreSQL, etc.) are *flawed*, SQL-based DBMS.
Check out www.dbdebunk.com to be enlightened.
Thanks,
--
Matt
EXCELLENT post. Sums up the armchair-DBA crowd here at /. quite nicely.
:)
If I had a gold star you'd get one
Thanks,
--
Matt
Codd's 12 rules explain what makes an ideal RDBMS. He invented the model, so it probably makes some sense.
MySQL, in particular, violates rules #5 & 6 & 10 (and maybe more) -- it lacks a comprehensive data sublanguage (it's a subset of SQL, which already is limited in how much it can do), and views (particularly updatable views, which many RDBMS still don't support). Lack of foreign keys in MyISAM violates rule #10.
Things like views are "derived relations", and are key ways of simplifying queries. It's almost the equivalent of saying "no function names allowed" in C - everything must be in main().
Subqueries are crucial for key algebraic operations (there are 8 in total, I won't get into all of them here). One such operator is division.
Division can be simulated in MySQL using temporary tables, but this is woefully complex to specify and quite inefficient.
An scenario of a question that requires division is (excerpt from Joe Celko's article above):
A data model of Pilots, Planes, and a Hanger with planes inside of it. There's a table PilotSkills that relates which Pilots have the ability to fly a particular Plane.
CREATE TABLE PilotSkills
(pilot CHAR(15) NOT NULL,
plane CHAR(15) NOT NULL,
PRIMARY KEY (pilot, plane));
CREATE TABLE Hangar
(plane CHAR(15) NOT NULL PRIMARY KEY);
The question: which pilots can fly EVERY plane in a particular hanger?
In SQL, the answer is ugly, but requires subqueries:
SELECT DISTINCT pilot
FROM PilotSkills AS PS1
WHERE NOT EXISTS
(SELECT *
FROM Hangar
WHERE NOT EXISTS
(SELECT *
FROM PilotSkills AS PS2
WHERE (PS1.pilot = PS2.pilot)
AND (PS2.plane = Hangar.plane)));
The quickest way to explain what is happening in this query is to imagine an old World War II movie where a cocky pilot has just walked into the hangar, looked over the fleet, and announced, "There ain't no plane in this hangar that I can't fly!", which is good logic, but horrible English. (and is also why some dislike SQL.)
-Stu
>>Point 3 (Much) better support for mysql than postgreSQL in PHP. You can argue all you want that php isn't something you would like do develop with, but a whole lot of websites use it.
:)
:)
Actually, the support is pretty much the same, except the function names start with pg_
It used to be a pain to compile php with postgresql support but not anymore. Actually, even RH and Mandrake have it in rpms
You could say the same thing about objects, in OOP. Most developers don't know how to use them well, and poorly defined objects either embedding or inheriting from other such objects can lead to poor performance and very strange bugs. However, most shops still use objects and classes.
However, I will agree that most programmers don't have enought relational DB experience (I wish college CS curriculum would make relational algebra a required class, as RDBMS's are fairly ubiquitous these days).
Make sure everyone's vote counts: Verified Voting
You're not dumb, but you do need to RTFM.
Postgres is an SQL server, not a desktop interface. It's there to do a job - if you plan to use it, shouldn't you find out how it DOES the job?
As far as I've found out there is no pg_ equivilent for "while ($row = mysql_fetch_array($res)) you have to use indexes and a for loop. Makes it hard to convert a php/mysql script to use posrgreSQL.
- Ost
---- Sig. gone.