There is another approach for situations like this where the same code base is used with the same database schema. Your explanation of company_id included with every query makes me think that company_id does not belong in the database table but rather as a database user.
The approach would be to do a CREATE USER in the database for each company_id. Extract the SQL DDL for the affected tables. Remove the company_id column. Change the owner name to the table to the CREATE USER name and create the new table with the new owner.
CF has a pretty easy way to use the same database for different users by creating a different data source name for each user. In all your cfquerys change the datasource attribute value to a variable. Assign the value to the datasource depending on the company_id. Don't forget to add a data source name for the dbo.
In the cfquery, you have a couple of choices about changing the SQL owner. Remove the owner name is the easiest. Or make the owner name a variable. Since the DSN is logging in as a user, SQL queries are limited to that user.
Using this approach means a little more DBA work but the CF is cut way back. Queries will run faster because the where clause for company_id can be dropped.
Adding the dsn for the dbo allows cross join queries between company_ids.
At 07:05 AM 10/5/2004, you wrote:
>> Anything where the implementation may change, or have complex effects, get a getter/setter.
I haven't a problem modifying the existing get and set data methods to be bog-standard property getters and setters - each init() would wind up the properties with data and any property "set" would also pass the data back to the persist layer. nothing unusual there.
it's the implementation of multiple versions of properties for each CFC - one for each company - that I've not settled on yet. each version would have exactly the same structure but differ only in data, based on the company_id.
a typical site install would have between 1 and (say) 6 companies all using exactly the same codebase and db - that's why *company_id* is (currently) in every method call and query. Taken a step further, each company would use the same instance of each type of CFC, but would need to use company_id as it's "key" when refering to any properties of the CFC. it just strikes me that I won't have descrete properties per se, but one large struct with keys based on the company_id (which, I suppose, sums up a CFC's "variables" scope anyway - it just feels like a "wierd" idea, that's all...)
At least a third of the total db data could be held as CFC properties in server scope if I can change it over. Presently, none of it is - they're all disparate method calls and no properties as such. It could reduce database hits by up to 50% (it's a very chatty system ATM)
as an alternative, I've been thinking about multiple instances of each CFC (one for each company) but the idea of gettting a reference to the correct instance based on a users session.company_id doesn't "feel" right:
eg:
<cfset bOK = server.setup#session.company_id#.setparms(argumentCollection="#args#") />
so, any thoughts on the nested struct properties that each CFC would have?
thanx barry.b
-- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
----------------------------------------------------------------------- http://www.switch-box.org/CFSQLTool/Download/
Switch_box MediaFirm, Inc. www.Switch-box.org Loveland, CO USA
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
