Exactly where do I go to get this?

As versus what we have now? How many trillions in bailouts (leading to nice fat bonuses for the Wall Street oligarchy) will it take to convince you otherwise?

More powerful government == more opportunities for corruption. Yes, NATURALLY.

Seems to me DART is meant to replace the ubiquitous PHP/Javascript combination. Think about it: quick prototypes with untyped code, moving to static typechecking wherever wanted, Server-side and client-side execution, built-in HTML5 DOM library. Its features may be unexciting, but they could provide an easy escape from PHP/Javascript hell without too much learning curve.

If that is Google's primary target with DART, it may prove to be a very strategic move.

This has always worked out well for me at some level or other. If you make it clear that your reason for leaving is not a negative one (IE. hating your boss/job/whatever) and that you are willing to do whatever you can to help them make the transition, usually employers are quite reasonable about such things. One of my former employers (a branch of a very large company) still contacts me occasionally even 4 years after my departure.

Never burn bridges, but never limit yourself due to feeling sorry for your employer.

That has long been one of my thoughts. For example, PG'OCaml looks very promising.

Having migrated a few applications from MySQL to Postgres, the truth is, it will be painful, but the result is you will be a LOT more confident in the quality and manageability of your data. Start here

PostgreSQL has all the datatypes that MySQL has, and more (see especially the ), and usually with far less limitations. Any character type can be up to 1GB in size if needed, for example.

The biggest sources of pain will likely come from character set handling (some MySQL oddities there) and MySQL's ready acceptance of NULL where it really shouldn't occur. Learn to love grep, sed and the 'iconv' utility.

There are conversion utilities that will get you part of the way there with a DB structure dump, but they will hardly do justice to a complex database. You will have to reengineer your system--in fact you will want to, since PostgreSQL has many capabilities that you cannot take advantage of in MySQL.

Triggers and stored functions are a little less 'wieldy' in Postgres, but far more capable once you get the concepts. For one thing, MySQL re-compiles all stored procedures for every instance of a connection (making SPs in PHP web-based apps almost pointless). One caveat: Postgres does not have 'true' stored procedures in the sense that they cannot span multiple transactions. Thus they are called functions, but aside from the transaction limitation, they are far more capable than MySQL stored procedures. For example, result sets from functions can be treated exactly like result sets from tables, and nested inside other queries and views, even in the FROM clause in ways that MySQL still does not allow. Full referential transparency.

Postgres has many more indexing options than MySQL, which you will want to explore for performance tweaking.

Postgres has the RULE system which allows for query rewriting in much the way that Apache's mod_rewrite allows for URL rewriting. It is a powerful tool, allowing you to potentially get rid of tons of stored procedure code. In some ways it works like an alternate triggering mechanism, but it is very lightweight.

BTW, one way you might consider handling your migration is using PostgreSQL's new foreign data wrapper or SQL/MED functionality, which can allow you to query a MySQL table from within a PostgreSQL DB (read-only for now, but excellent for importing tables interactively)

Bingo. Exactly what I have been saying for years, but... we both know that this sort of idea is far too sensible and boring for the 'concept du jour' programming community.

Why is this modded down? +1 informative, please.

Nowhere in your rambling, incoherent response did you come close to anything that could be considered a rational thought. We are all dumber for having listened to it. I award you no points and may God have mercy on your soul.

Very interesting to note. I had been wondering about that part of the story.

Absolutely!. I am at the last 100 pages right now and it surely does not lose steam. Nor punk. (OK, I'll stop now)

Big emphasis on the "roughly". The features may look the same as tick points on a list, but when you actually try to use them, vast differences show up. Roughly bundled-together features without a comprehensive plan is what it looks like to me. For example, no referential transparency or transitive closure. You can't just nest expressions, views, function calls and procedure calls transparently. You can't alias temp tables in procedures, etc... Lots of odd restrictions and "can't get there from here" scenarios.

Yeah, we shouldn't expect that old bugaboo "conceptual integrity" to intrude on modern software design, right? Can't use full-text indexing and foreign key constraints on the same table? What kind of compulsive freak would want that, anyway...?

Well of course replication on a complex database is going to be hard. Fact is, most MySQL databases are very simple (the only appropriate use of MySQL, IMHO). Once a MySQL database gets complicated, it is all but impossible to coax robust replication out of it. In the case of one I had to deal with, I had to finally retreat to the simplest master->slave approach, AND I had to upgrade to 5.1 for row-base replication (statement-based replication is just impossible if you have complex stored procedures). Even so, I have to set slave_exec_mode to IDEMPOTENT in order to actually keep replication running, which of course makes the actual replication far less robust. (I know, if they moved to full transactional INNODB tables it probably wouldn't be necessary, but unfortunately they need MyISAM tables for some things).

Point is, replication is HARD to get right on any moderately complex system. I doubt there will ever be a magic bullet in that regard.

MySQL replication barely deserves the name. It plain and simple DOES NOT guarantee data consistency. Maybe it's nice and easy to work with, but I would never trust mission-critical data to it.

I know that replication has been the sore point of PostgreSQL, mainly because there were several different approaches being developed--all provided as external solutions, and it could be confusing to try and wade through all the data to find the best option. Fortunately, version 9.0 (moving from alpha to beta soon) will come with built-in hot standby and streaming replication.

That really depends on the kind of company and the kinds of applications involved.

MySQL can probably still handle a higher # of raw queries per second *using MyISAM tables* than PostgreSQL, however once you test with a table type like InnoDB, which has to support such things as constraints and transactions, the MySQL speed advantage is lost.

Many large web companies don't really need transactions, MVCC, constraints and other such niceties because the type of data they work with doesn't demand such precision. That's a perfect answer as to why many of the are investigating non-relational alternatives. However, a company doing business applications involving money, or other critical, non-trivial data can't afford to take such chances with data consistency.

Developers need to understand the real nature of the trade-offs involved in all these things. NoSQL type systems can be fine as long as you don't need complicated ad-hoc queries, provable consistency or mission-critical business rules. Once you start needing those things, though, you ignore relational databases at your peril.

Of course, there's always another way to skin a cat. It is possible to work with a hybrid set-up, such as relational database at the core for business rules and consistency, but high volume demand-driven data cached out to NoSQL systems. For example, in 2008 Yahoo created a custom PostgreSQL hybrid with cloud storage backend to handle clickstream data, weighing in at 2 petabytes. I can only imagine how big it is now.