FWIW, one of the best and fairly objective comparisons I've > seen is at: > > http://www-css.fnal.gov/dsg/external/freeware/pgsql-vs-mysql.html
Cool link Dan! I've used mysql both at work and on my website for years. Although i didn't script it at work, the php running behind both servers is the same. The web runs over apache, php and mysql all on nix. At work, it's w2k or win2003 and mysql (although for real prod they use oracle and solaris servers (up to 64 cpus!). We usually have 4 top of the line cpus, dual or 3 powersupplies for reliability and raid 5 storage (or EMC SAN mirrored raid5 storage) and over 2 GBs of ram most of the time but the results are the same. MySQL is quick, simple, easy to manage, free... NEVER had a problem with it!!! Unix or windows as servers does not matter much as long as you know how to manage it well. Know your car and you'll win more races than those who dont... But all systems require tuning and this is part of the homework. Then comes the design of the database. The more you atomize it, the better. PHPNuke is a huge network of tables but im really happy with its modularity and php/html output and ease of editing and overall performance - but in the end, for any client server system, the real bottleneck is the network... Remember that!!! Now, in RunRev, there seems to be a lot of support for cgis and sql. Databases as well but as externals. One thing im not too happy about Rev is processor usage. It literally sucks sometimes. I mean it drains the CPU down and you can't have that in a server situation. So dual cpus is nearly a requirement. RAM at 1 GB or more is recommended too dependent on how much data and network connections you're going to have to handle. But if you use swaps diligently this should never be a problem. Monitoring tools are a requirement depending on the load of network and database connections required at peak hours... In runrev, the db design and IO in SQL or client connections or any loops you might have to run are going to affect directly the through- put you can deliver but im sure this shouldn't be a big problem for someone used to Valentina. Server side, use all the speed tricks (avoid fields updating for example). Using compiled applications to do different bits will help thread the "system" you have to implement. For example 1 stack server that does it all is definitely not recommended - no threading doesn't help... Multiple RR apps can listen to ports, prepare output, feed output and processing queries in the queue (important to have a queue besides logging purposes) but what is important is that they can do so without blocking other processes - network, shell or disk access here can be your black sheep here since there's no operation timeouts in Transcript. So one app should always monitor if any key task running doesn't lock up plus it can dispay current statistics or bugs as they creep up like the NT event viewer (shell tools can help you insert events in it from runrev for example. And the number of event tools to display alarms is quite a necessary tool in our production - MS MOM for one... But InsightManager, Patrol, sysload and others are definitely key tools in our server's arsenal of tools for their smooth running. Just examples but you can see the need for concurent/threaded tasks in a server model. Client side, well, that's the easiest part if you carefully planned how the transaction event/data model should work beforehand. Here again, like the sql tables, good design planning = much easier maintenance, performance and reliability - all of which are pillars quality application design and customer satisfaction! just my 20 cents. Also try your best to keep it as simple and modular as possible. As you can imagine, im going to make a tsunami with TAOO in this respect... And i personally prefer to use stack storage with fields. Why? Because it's native, easy to modularize and distribute and even easier to maintain or enhance or clone. And making or servicing or editing stacks is natural in rev - no intermediate connections... So why mess with stacks? Well, get into TAOO and you'll soon know why i think the stack model is the fastest model - after the text file ;) My venerable 64MB ram 1GB scsi drive PPC8500 could access on a 4X cdrom from a 80MB database of 760000 "text" records and in a double-linked list style relation hierarchy of combinations of 87000 different ingredients. Remote file access times were less than 2 seconds. Today, that translates in milliseconds... Design is key! Reliability too! Performance depends on the needs... But the bottlenecks are not necessarily in RunRev if you design it considering the flexibility of the stack or custom properties. I admit i haven't done as much networking in Rev as others but i've worked with RevChat and it's quite nice to see it's not that slow! I use the mc cgi on windows 2000 advanced servers at work and it's a charm... But scripting html output is not my favorite ;) cheers Xavier http://monsieurx.com/taoo > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Dan Shafer > Sent: Saturday, May 14, 2005 08:20 > To: How to use Revolution > Subject: Re: Database suggestions? > > Ken.... > > Pardon me for jumping in here. > > WHile I think it has been generally true that PostgreSQL is > actually a bit faster than MySQL in apples-to-apples > comparisons, the fact is that so much of the speed of a > relational database is a function of how well designed the > tables are, how many complex joins are involved in the > application built on them, and other stuff that isn't really > native to the DB engines, I'm not sure a fair comparison that > is universally true can be made. > > FWIW, one of the best and fairly objective comparisons I've > seen is at: > > http://www-css.fnal.gov/dsg/external/freeware/pgsql-vs-mysql.html > > > On May 13, 2005, at 10:51 PM, Ken Ray wrote: > > > On 5/14/05 12:28 AM, "Chipp Walters" <[EMAIL PROTECTED]> wrote: > > > > > >> Hi Ken, > >> > >> Here's a couple of things you may want to consider. > >> > > > > Thanks, Chipp... yes, we'll have multiple concurrent users > so I guess > > it's MySQL or PostgreSQL. My understanding is that in > general, MySQL > > has better performance than PostgreSQL, does that jibe with > your take > > on the two DBs? > > > > > > Ken Ray > > Sons of Thunder Software > > Web site: http://www.sonsothunder.com/ > > Email: [EMAIL PROTECTED] > > > > > > _______________________________________________ > > use-revolution mailing list > > [email protected] > > http://lists.runrev.com/mailman/listinfo/use-revolution > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Shafer, Co-Chair > RevConWest '05 > June 17-18, 2005, Monterey, California > http://www.altuit.com/webs/altuit/RevConWest > > _______________________________________________ > use-revolution mailing list > [email protected] > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
