Database suggestions?

Sat May 14 04:45:57 EDT 2005

 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: use-revolution-bounces at lists.runrev.com 
> [mailto:use-revolution-bounces at lists.runrev.com] 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" <chipp at chipp.com> 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: kray at sonsothunder.com
> >
> >
> > _______________________________________________
> > use-revolution mailing list
> > use-revolution at lists.runrev.com
> > 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
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 