Re: Data modeling for a multi-company product

On Jan 25, 12:30 am, "dawn" <dawnwolth..._at_gmail.com> wrote:
> On Jan 24, 4:17 pm, "Pickie" <keith.john..._at_datacom.co.nz> wrote:
>
>
>
>
>
> > On Jan 24, 10:38 am, "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. --dawnIn the case of generic software designed to operate with a number of
> > DBMS (SQL) products; in order to allow some customisation of each
> > implementation, nullable attributes are pretty well a certainty.
> > Further, because the SQL standard defines nulls, there is a tendency to
> > use nullable attributes even when an extra table would have been the
> > better option.
>
> > Regards, KeithOK, good, a straight answer. Thanks Keith. So, when many cdt folks
> are saying that the correct behavior for someone modeling data for a
> SQL-DBMS is design with no nullable attributes, they would typically
> not also suggest that a software development company that writes
> software for multiple companies should model data this same way, right?
> Not only is it not feasible, but it would not be a "best practice" in
> that case, right?
>
> Does it follow that a company licensing 3rd party software should
> expect that they will have a logical data model that has many nullable
> attributes?
>
> If so, does it then make sense that both a software vendor and their
> prospective clients might be well-served, at least in this one area, by
> using a DBMS that employs 2VL instead of 3VL if they wish to avoid the
> problems associated with nullable attributes with SQL? --dawn- Hide quoted text -- Show quoted text -

I wonder if anyone - maybe a lurker - here has made the transition from

SQL using nullable attributes to XPath schemas with minOccurs set to zero?

Mike. Received on Fri Jan 26 2007 - 12:43:01 CET