Re: Data modeling for a multi-company product

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, Keith

OK, 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 Received on Thu Jan 25 2007 - 01:30:17 CET