On Tue, 26 Nov 2002, bpalmer wrote: > > > D'Arcy, > > > > > > In production the database servers are seperate multi-processor machines > > > with mirrored disks linked via Gigabit ethernet to the app server. > > > > > > In development I have people extremely familiar with MS, but not very hot > > > with Unix in any flavour, who are developing Java and PHP code which is then > > > passed into the QA phase where it's run on a replica of the production > > > environment. > > > > > > My goal is to allow my developers to work on the platform they know (MS), > > > using as many of the aspects of the production environment as possible (JVM > > > version, PHP version, and hopefully database version), without needing to > > > buy each new developer two machines, and incur the overhead of them > > > familiarising themselves with a flavour of Unix. > > (from experience in a large .com web site) > > Can you have a central DB server? Do all the dev DB servers need to be > independent? You could even have a machine w/ ip*(# developers) and bind > a postgresql to each ip for each developer (assuming you had enough > memory, etc). > > We used oracle once upon a time at my .com and used seperate schemas for > the seperate developers. This may be tricky for your environment > because the developers would need to know what schema they would connect > to if all schemas were under the same pgsql instance.
>From what the original post was saying, it looks more like they're working on a smaller semi-embedded type thing, like a home database of cds or something like that. OR at least something small like one or two people would use like maybe a small inventory system or something. High speed under heavy parallel access wasn't as important as good speed for one or two users for this application. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
