The biggest issue for me is that you want your development environment to be as identical as possible to the production environment (to avoid mistakes when you move your application over). You don't want your production environment to accidentally access your development data; but at the same time you want to make sure that your development isn't accidentally playing with the "live" data.
Since I'm running a *AMP application, I can just use "localhost" and not worry about forgetting to change the database name references. Regards, Jerry Schwartz Global Information Incorporated 195 Farmington Ave. Farmington, CT 06032 860.674.8796 / FAX: 860.674.8341 E-mail: je...@gii.co.jp Web site: www.the-infoshop.com >-----Original Message----- >From: Johan De Meersman [mailto:vegiv...@tuxera.be] >Sent: Friday, March 04, 2011 6:21 AM >To: Sid Lane >Cc: MySql >Subject: Re: best practice: mysql_multi, VMs w/single instance per or doesn't >matter? > > >Other people have answered with pros and cons of virtualisation, but I would >rather ask another question: why do you feel it necessary to split up the >database? > >If it's only used for QC, it's probably not in intensive use. Why would you >go >through the bother of splitting it up? You're staying on the same server, >apparently, so you'll have to decide which instance gets what part of cpu, >memory and other resources, you'll have to provide separate backup for all >instances, et cetera; while leaving things as they are is zero effort. > >What is the problem with the current setup that will be resolved by >splitting? > > >-- >Bier met grenadyn >Is als mosterd by den wyn >Sy die't drinkt, is eene kwezel >Hy die't drinkt, is ras een ezel > >-- >MySQL General Mailing List >For list archives: http://lists.mysql.com/mysql >To unsubscribe: http://lists.mysql.com/mysql?unsub=je...@gii.co.jp -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
