Re: Data modeling for a multi-company product

kvnkrkptrck_at_gmail.com wrote:

> My $0.02:
>
> Customer A should consider using a database modeled after customer A's
> business, perhaps using a person entity:
> PERSON_A (person_id, fname, lname, bdate);
>
> Customer B should consider using a database modeled after customer B's
> business, which has a person entity:
> PERSON (person_id, fname, lname)
> and a birthday relationship:
> BIRTHDAY (person_id (fk), bdate)
>
> Or maybe they should both buy the same database, with entity:
> PERSON (person_id, fname, lname, bdate NULLABLE)
> and relationship:
> REQUIRED_PERSON_FIELDS (data_entry_form_name, field_name):
> ('XYZ','BDATE').
>
> Then customer A and Customer B could make the appropriate entries in
> the setup screen so the XYZ entry form could decide whether bdate is
> required by querying for rows in REQUIRED_PERSON_FIELDS WHERE
> data_entry_form = 'XYZ' and attribute = 'BDATE'. However, more
> questions come into play: What will you distribute to customer A and B
> if customer A wants the option of storing pet information (i.e. "pet
> name" and "pet type") for people in its database? And customer B wants
> to optionally store "spouse name" for people? Customer A issues all
> employess a cell phone, and this phone number must be recorded for all
> people; not so for customer B, which requires just a primary contact
> phone number of all PERSONs. What does the distributed model look like
> now? And enter customer C, who doesn't want ANY of that, but would
> like a "number of children" recorded.
>
> My guess: eventually you'll get a distributed model that starts to look
> like all "flexible" models, with a entities ala:
> PERSON(person_id, fname, lname, attribute1, attribute2,
> attribute3,...);
> and some attribute descriptors:
> PERSON_ATTRIBUTES (attribute_number, description, type, ...);
> some form "helpers":
> FORM_ATTRIBUTE_DESC (form_name, entity, attribute_number, label,
> required_flag, field_size, position);
> etc.
> Customer B will realize that it's easy to maintain their own custom
> PERSON view and that they can build a much more ergonomic PERSON form
> based on the view; customer A will create their own custom PERSON_PETS
> table and perhaps design their own "pet picture" form... and one day a
> few years down the road, (maybe) the customers will wake up realizing
> that they spent a lot of money for a "flexible" application which is
> really nothing but a crappy database built on top of and markedly
> inferior to an already existing DBMS; a bunch of crappy form generators
> markedly inferior to those distributed with the DBMS; a bunch of crappy
> report generators markedly inferior to those distributed with the DBMS;
> and a bundle of processes which perform poorly and "almost get it
> right", but must be preceded and followed by custom processes to "fix
> things up" (and wind up being more complex than the bundled
> functionality was originally).
>
>
> Or....
>
> Customer A could consider using a database modeled after customer A's
> business and customer B could consider using a database modeled after
> customer B's business.
>
>
> On Jan 23, 3:38 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
>

>>One feature of some ERP and other software application systems is the
>>ability for the customer site to indicate in the setup which attributes
>>are required and which are not related to the various data entry
>>"screens."  So, customer A might consider birthdate to be a required
>>"field" when a user is entering data into the XYZ screen/form while
>>customer B does not.
>>
>>When I was reading about designing for the elimination of NULLs, it
>>struck me that I was not sure how to prepare an elegant logical data
>>design if the exact same software is to be deployed to multiple
>>customer sites with the customer having this option.  This means that
>>other than "primary keys" (those used to create new or lookup existing
>>information) almost all attributes are optional.
>>
>>How do SQL-based ERP solutions and other software to be deployed to
>>multiple companies model the data for this feature?  Do any ERP or
>>other multi-company software solutions come close to doing this
>>"properly" with no nullable attributes?  Do they then have a separate
>>table for each attribute where it is possible for a site to configure
>>it as not being required?  Maybe I'm confusing some issues here, so any
>>clues would be appreciated.
>>
>>Thanks.  --dawn

To amplify Kevin's reply, most ERP software re-implements a majority of the functions of a dbms while ignoring those same functions when already supplied to them by the dbms. This, of course, is entirely independent of the logical data model. Received on Wed Jan 24 2007 - 17:05:30 CET