Re: how good is PHP-PostgreSQL???

From: Date: Tue, 31 Oct 2000 08:40:32 +0000
Subject: Re: how good is PHP-PostgreSQL???
References: 1 2 3  Groups: php.general 
Request: Send a blank email to php-general+get-22880@lists.php.net to get a copy of this message
Take the example of a Inventory transaction for a T-shirt... subtract T-shirt from Inventory add T-shirt for to delivery note. add T-shirt cost to income subtract from customer's bank account PostgreSQL for every this transaction create temporary tables while the transaction is being performed. The main tables don't change until all four step are performed. If you have say 1000 of them being performed at the same time you have thousands of temporary tables being created and destroyed. PostgreSQL is very secure but is also somewhat slow... Mysql will lock the table until all four steps are completed. However you can get around this by having two servers, Server1 for reading and Server2 for writing records. You then use one way replication to update the records on the server1... The mysql documentation is quite good at explaining this in more detail... Hope that explains it.. I may have gotten something front to back :).... I'm not a developer of either PostgreSQL or Mysql but an active interest in both... I have used both in smaller projects... George Patterson Arnold Gamboa wrote: > > Hi George, > > Thanks for your suggestion. > > Let me ask, though, why did you say you do not recommend PostgreSQL for this > huge amount of data.? > > Thanks alot. > > Arnold Gamboa > > > Arnold Gamboa wrote: > > > > > > Hi, > > > > > > For users of large PostgreSQL and PostgreSQL builders, this is for you. > > > > > > I'm having a terrible time deciding now. :( > > > > > > We're about to build a "huge" website now. I got tied up in signing > > > the > > > contract without really getting enough information about PgSQL since > this > > > what we plan to implement with PHP (normally we use mySQL but i guess it > > > does not fit for huge databases like that). > > > > > > Here's my problem.. We're about to build a site like hitbox.com where > there > > > is a large amount of database required.. If say there is 100,000 users > with > > > 1000 page hits per day for each, and everything will be logged, you > could > > > imagine how huge this will be. I'm just so "nervous" (really, > > > that's > the > > > term) if we implement this and later on experience a slow down or worse > than > > > that, crash in the server. > > > > > > My questions are: > > > 1. What is the limit for number of records in a table WITHOUT SUFFERING > SLOW > > > DOWN. > > > 2. ....limit in number of tables per database > > > 3. ... limit in number of database. > > > > > > Thanks for you comments. I would really appreciate every comment that > I'll > > > receive regarding this. > > > > > > Arnold > > > > > Arnold, I wouldn't recommend postgres for this. Mysql is a much better > > databse for reading but experiences problems when thatre are a lot of > > write transaction to be done to be done. Having said that mysql doesn't > > come with the rollback. It is where if part of a transaction fails, all > > of the transaction is reveresed to the point where you stared the > > transaction. I havn't used a commercial databse such as Oracle or IBM > > DB2 or some others... > > -- > > george@laopdr.com > > Network Administrator > > Planet Online > > Vientiane, Lao PDR > > > > -- george@laopdr.com Network Administrator Planet Online Vientiane, Lao PDR

« previous php.general (#22880) next »