Re: Data modeling for a multi-company product

On Jan 25, 10:46 am, kvnkrkpt..._at_gmail.com wrote:
> 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.

When working with 3VL, I agree that it is a best practice to avoid NULLs. While I see no need for exceptions in an initial design, there could be exceptions when refactoring the database schema as changes are needed. I have not been in such a position, but understand from others that it is difficult to manage a SQL-DBMS schema over time without introducing nullable attributes.

But when you suggest that database design not rely on NULLs, I don't know if you are considering the cases of 2VL-languages accessing DBMS's that do not speak SQL as their first language. There are folks in our industry today who have only used SQL-DBMS's, so my apology if you are well-versed in others and intended to avoid NULLS also when using 2VL DBMS's (shorthand for DBMS's accessed directly with 2VL languages), but I have never seen a 2VL-DBMS schema that did not have nullable attributes.

So, would you agree that when you say that you should work toward designs that do not rely on NULLS that you are referring to the NULL related to SQL-DBMS's and not NULL (interpreted as an empty set) employed with 2VL DBMS's?

> 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.

In the case of a software company writing software for multiple clients to use, there are obvious requirements for the DBMS schema to be flexible enough to be implemented for each. So, we are not making less robust applications, but rather we are making more flexible software that can be used by multiple sites. So, the question is not whether to make the software less robust, but more full-featured, aligning with requirements.

> If the ability to design products that will not precisely align with
> your clients' business models is seen as a perk,

Since my clients are often software application companies, the requirements to be database-independent and configurable for a variety of their customers are well-known and often well-documented. So, yes, you are correct that we want the software to align with the clients' business model and requirements, including the flexibility they require.

> then certainly using
> NULLs should be left in your repetoire. The more the merrier, I'd say.

Not I. I dislike the SQL NULL as much as anyone. I avoid it, but usually I avoid it by avoiding SQL-DBMS's. So, my question relates to those who, like me, want to avoid SQL NULLs. Not everyone will choose to do so as I do (ditching the SQL DBMS when I can), so I'm wondering what those with whom I agree on the issue of SQL NULLS think should be done with software written for a software application company.

Did that help clarify? Thanks. --dawn

> 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 - 19:28:19 CET