The big caveat I will give about have multiple databases with multi-tenant code is that any change to the shared code has to be reflected in every single database simultaneously. And that's a challenge and a half.
---------------------------------------- From: "Rick Faircloth" <r...@whitestonemedia.com> Sent: Tuesday, February 22, 2011 10:58 PM To: "cf-talk" <cf-talk@houseoffusion.com> Subject: RE: Feedback on this approach to "many sites, one codebase" (MSOC) I can see both sides on this one very clearly. To this point, all I've ever done is develop custom applications and websites. I haven't sold the exact same site in 10 or so years of development! However, I really want to get away from working just one-on-one with clients. They can be a real pain. Some are just downright ignorant and impossible to work with. (You can tell I've had a couple of bad experiences lately... ;o) I'm want to move into developing sites for specific uses, such as for recreation departments or real estate agents and brokers, etc., and have them sign up for the site online, choose their template, put in their content, and, after a free trial period, they pay their money. If they need support, they can email me. If they want functional customization, I'll build a custom function for a client, charge them for it, then make that function available to anyone else using my "SAAS" sites. The customers will never own the sites and never have the opportunity to "take the code" elsewhere. If they want cosmetic or style customization, I can do that and charge them for it. It will still remain my site and not the client's site. I'll still build custom apps along the way, I'm sure, but I'd like to start making my work on an app/site pay more than one time. However, like you Matt, I may end up going back to individual customizations, if things don't work out so well on the SAAS front. I do have some clients who always insist on being absolutely unique and want to have the "best" site. To those who want to be absolutely unique, I can sell the template for a few thousand or whatever amount, and they'll have exclusive rights to use that template, but they still won't own it. Soon as they stop paying, the template goes back into the fold. I just want to test this approach and see if I can make it work. Rick PS - when it comes to the database, I'm leaning towards a different database for each client. I'd hate to have problems with a client's data and have to parse through everyone else's data to see what the problem is. Of course, I do have some "common data" databases that everyone would share...local area info, etc. But I'm currently still using distinct databases for client-specific data. -----Original Message----- From: Matt Robertson [mailto:websitema...@gmail.com] Sent: Tuesday, February 22, 2011 1:02 PM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) Even though my own CMS can handle multiple sites running off of a single installation, I don't run it that way. The points brought up about clients wanting individual customizations and portability fit my situation. I understand if you are offering software-as-a-service things change, but for me this turned out to be enough of a headache that I reverted to separate installs and have never regretted it. If a customer wants an upgrade, they pay me an hour or two individually to make that happen. If they want a specific feature that I don't want to fold into the overall codebase, I can do it - and earn the money for doing it - without worrying about consequences on 40 other web sites on the server. But thats a business decision and not coding. Mentioned just as food for thought. For sites for my own company, where presently we have about 36 up and running and will be at around 60 when we are done, we *do* share a single codebase. There are no special mappings. Each site has an Application.cfm that looks like this: request.appName="AR_060110_1033"; request.rootFolder="ARDotCom/"; request.FQDN="www.mysiteAR.com"; <cfinclude template="../common/Application_common.cfm"> The common file has some server vars too: server.BaseRoot="C:/foo/bar/sites/"; server.dsn= etc. etc. blah blah And thats enough - along with more code in the common "Application.cfm" - to set up absolute and relative paths to the files I have located in the common-use folder. Every site has its own independent application scope. I've opted to set the app name manually so I can reset session and app vars if need be... a rare occurrence but its nice to have the option available. The root of this web site is a root folder in a discrete IIS web site and, since CF has no trouble recursing back up beyond a web root insofar as physical paths go, the /common/ folder is not accessible from the web, but it is from CF. Very simple to set up. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342509 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
