I think, perhaps, folks are misunderstanding my use of the term "atomic." Atomic, from a database design perspective, means "cannot be broken down any further."
For example, if you have a customer record and put one field on it to capture the customer's entire address, that field is NOT atomic. That is, suppose you put the value... 123 Main Street Miami, FL 33010 You're cramming four individual data elements into one field (street, city, state, zip). This is poor design. The better design is to capture those elements in separate fields: Street: 123 Main Street City: Miami State: FL Zip: 33010 Designing this way pays off huge dividends in the long-run. If the boss comes to me six months from now and says, "Norm, give me a list of all customers in Florida," voila! I have the number in seconds. Concatenating values into one field, like this: Acme-Widgets-Development destroys the "atomic-ness" of the Company field. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of David Sanders Sent: Monday, July 02, 2007 2:26 AM To: arslist@ARSLIST.ORG Subject: Re: Multitenancy in a Large Enterprise Hi Norm I don't understand your objection. A company is only 'atomic' if it is a singular unit for all attributes, including permissions. If it is not, then you need to consider the organizational sub-units that ARE atomic as your 'company' records. In all likelihood, if you are dealing with external customers, each external company will be a single permissions entity, but if you are dealing with your own organization, you will need finer granularity when setting up the organization. In real life, companies have multiple sites, divisions, departments and relationships with other entities. They are not 'atomic'. If you have a requirement that row level access be determined at a department level (like HR), then this is your atomic level and you need to set up companies and permissions at the department level and relate them accordingly. If you set up the row level access groups as computed groups, then you also have the ability to 'inherit' access permissions from this level up to higher levels in the organization. I'm not sure exactly how this would work in ITSM7, but in our own ESS application it is possible to use these techniques to easily map complex organizational and permissions structures. Additionally, ticket CTIs, SLAs and business rules etc. can all be varied by which 'company' the customer belongs to. Could it be that your problem is with the word 'company'? Think of it as an organizational unit that can be set at any level in the real company structure, as appropriate. The point that comes out here is that if you do have complex permissions and access requirements, it is important to plan your organizational structure carefully before proceeding too far into your implementation. HTH David Sanders Remedy Solution Architect Enterprise Service Suite @ Work ========================== ARS List Award Winner 2005 Best 3rd party Remedy Application See the ESS Concepts Guide tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk On 6/29/07, Kaiser Norm E CIV USAF 96 CS/SCCE <[EMAIL PROTECTED]> wrote: > ** > > Right, but this makes the COMPANY value no longer atomic. ________________________________________________________________________ ____ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
