QuoteOriginally posted by: HansiHmm okay never seen this, is it part of the enterprise install then? Not the community or cluster version?i have no clue where is it from. i highly doubt that it's not free, because otherwise they wouldn't put it on my laptop.

Try the MySQL GUI Tools:http://dev.mysql.com/downloads/gui-tools/5.0.html

QuoteOriginally posted by: quantstartTry the MySQL GUI Tools:http://dev.mysql.com/downloads/gui-tools/5.0.htmlThanks for the suggestion, the MySQL GUI Tools are pretty crappy and people didn't like that. But I just migrated their MySQL stuff to postgreSQL and gave them pgAdmin3. They seem content with that.Shouldn't be spending time on this non-paid stuff... grr... got to stop being so nice and helpful.

I haven't used postgreSQL yet - is it worth switching from MySQL?

Well pSQL is a bit faster and offers some additional features but ultimately the question is whether you need the marginal speed increase and additional features.http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

I've been working with these scenarios since 2001 including Access, MSSQL, MySQL, Postgres and most recently flat file DBs like MongoDB and can summarize as follows:1) Access should only be used for small, one of projects or for the occasional rapid prototyping. Most of the time you can simply use a csv or excel file instead with these, but every once in a while Access brings something to the table (ie. basic querying, etc).2) MSSQL is a pretty good choice if you have Visual Studio or other MS products. It isn't the best DB, but overall it has some nice management tools that help ease the transition from Access to a real DB3) MySQL is easy to setup and use. It has come a long way since it was first introduced and can relied upon to get the job done. It compares well when doing a large number of simple queries, but starts to lag as queries become more sizable and complex. My biggest concern is the Oracle ownership issue. 4) Postgres is a little bit hard to setup and administer if you are new to the DB world. It comes out of the box in a more secure form which can provide a challenge when working on a network or across varying OS's. Once installed, I have found it to be fast and reliable. No real complaints with performance and it has some decent admin tools, maybe not as good as the DB's above, but good enough to get the job done. 5) The latest venture (and one that I would welcome some other feedback on) is MongoDB. We currently run a mixed DB system in our office that uses Postgres to handle the basic security info (ticker, name....etc) while using flat files (txt) or MongoDB to store the pricing and other historical information. So far the results have been pretty promising, especially as the datasets grow (20+years of history for all MFs, ETFs, Stocks, Indices....). This setup seems pretty flexible even though it might require a little more work to initially verify the data quality. We do most of our work with Python and C++ with this setup. This is my personal experience and I will admit that my head-to-head testing could be formalized, but I don't have much time for that at the moment. I just know that our current setup is fast and scalable

Kblocker and Hansi,Thanks for the suggestions. I think speed is less of a concern for me right now, but if it starts to become an issue I'll doing some testing with pSQL. MongoDB also looks interesting. What are the major selling points?

Quote5) The latest venture (and one that I would welcome some other feedback on) is MongoDB. We currently run a mixed DB system in our office that uses Postgres to handle the basic security info (ticker, name....etc) while using flat files (txt) or MongoDB to store the pricing and other historical information. So far the results have been pretty promising, especially as the datasets grow (20+years of history for all MFs, ETFs, Stocks, Indices....). This setup seems pretty flexible even though it might require a little more work to initially verify the data quality. We do most of our work with Python and C++ with this setup. This is my personal experience and I will admit that my head-to-head testing could be formalized, but I don't have much time for that at the moment. I just know that our current setup is fast and scalableCame here to say just this. RDBMS's seem very awkward for this sort of thing. Just having multiple clients connect to the same datasource does not scale well. Since historical data "never" changes it makes sense to store it locally with the application. How are live feeds dealt with. Would something like ZeroMQ with pub/sub model work? A seperate node can take over the task of updating the datastores (MongoDB or RDBMS or Cassandra). The updates would have to weakly consistent. Cannot imagine a strongly consistent system working in this scenario.

QuoteActually MS Access is better than mySQL from a portablity POV i.e. you can just copy it to a disk or email it to someone and they can make use of it straight away. MySQL can live on a web server. You can write a script to automatically email your user or your user can just point to a web page.