Re: Data modeling for a multi-company product

Connecting the dots in advance: by working towards designs which do not rely on NULLs, database modelers can design schemas which more precisely and with greater robustness model their real world counterparts. Any technique which increases the precision with which database's model real world counterparts cannot be used to design databases to be less precise, more generic, and less robust.

If the ability to design products that will not precisely align with your clients' business models is seen as a perk, then certainly using NULLs should be left in your repetoire. The more the merrier, I'd say.

On Jan 25, 9:58 am, kvnkrkpt..._at_gmail.com wrote:
> On Jan 24, 11:19 am, "dawn" <dawnwolth..._at_gmail.com> wrote:
>
>
>
>
>
> > On Jan 24, 10:51 am, "Marshall" <marshall.spi..._at_gmail.com> wrote:
>
> > > On Jan 24, 8:05 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
> > > > 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.To expand on Bob's point, this is not limited to ERP software.
> > > I've seen a variety of different kinds of applications do this.
> > > I think it's mostly a combination of ignorance of the abilities
> > > of the dbms or failure to recognize the value of centrally
> > > managed integrity enforcement, coupled with a general
> > > prejudice in favor of using one's most familiar tools, which
> > > for an application programmer is typically his application
> > > programming language.
>
> > > MarshallApplication software companies often do not want to be dependent on a
> > single database provider. Any features that they use from one DBMS
> > that is not in other DBMS tools should not be used. Additionally,
> > application software companies typically need to provide business rules
> > processing for their end-users, as well as various reporting features,
> > requiring extensive metadata within their products. Most such
> > companies will consider the metadata they must collect as the source
> > metadata, with any DBMS being used being one of the various places
> > where they might push such metadata, as needed.
>
> > My question is about modeling data and related to nullable attributes.
> > I understand the arguments of those who are stuck using 3VL and are
> > modeling data with a goal of having no nullable attributes. However,
> > when writing software that is not just for one company, but for many,
> > is it feasible or even a best practice to model without nullable
> > attributes? How would the no-nulls advocates model such data if
> > writing software for a software company providing application software
> > to many companies (with a requirement to permit each customer to
> > determine which attributes on each screen are required and which are
> > not, for example)?
>
> > Is the answer to this obvious and I'm just missing it? Thanks. --dawnI know that incorporating regular exercise into fitness programs can
> help people using the programs live longer and healthier lives. My
> company is trying to build a fitness program which will deliver
> shorter-than-average lifespans filled with medical complications. Can
> someone tell me how to incorporate routine exercise into such a
> program?
>
> Is the answer to this obvious and I'm just missing it? Thanks.
> --kevin- Hide quoted text -- Show quoted text -
Received on Thu Jan 25 2007 - 17:46:17 CET