Re: Why all the max length constraints?
Date: 28 May 2006 13:17:28 -0700
Message-ID: <1148847448.001944.71530_at_j55g2000cwa.googlegroups.com>
mAsterdam wrote:
> dawn wrote:
> > mAsterdam wrote:
> >>dawn wrote:
> >>>mAsterdam wrote:
> >>>>dawn wrote:
> >>>>>Marshall wrote:
> >>>>>>dawn wrote:
> >>>>>>
> >>>>>>>[why all the length constraints?]
>> > The application software designers in line with their users (not those
> >>>... even in cases where there is no conceptual max on
> >>>a value (last name, for example), a max length is chosen for the
> >>>attribute definition to the dbms.
> >>
> >>"is chosen" by whom? Who made the choice?
> >
> > who wrote the dbms toolset, if that is the question)
>
> Yep, that was the question.
>
> I only don't like the "in line with their users" part
> - how can they be in line with their users and introduce
> constraints which are not in the conceptual model?
Yes, that is a problem. However, I like to keep the conceptual model as pure from implementation (e.g. choice of database product) as feasible, so you would not want to introduce unnecessary (from a business perspective) constraints there. It was when examining the "mapping" (perhaps too strong a word, possibly lacking the suggestion that there is creativity in the design when there is) from conceptual to implementation (aka logical data model) with a fine tooth comb that I noticed this introduction.
But I do think that design and not just conceptual model need to be "in line with their users" too. You simply have to go back to them beyond the conceptual model and include them in the design-as-the-computer-needs-it while doing design for a specific implementation of the model. In theory (although rarely in practice) the choice of target DBMS need not be made prior to the conceptual model being complete, right?
> It sounds as if they made it up themselves.
> Maybe for bad reasons, maybe for good reasons,
> but, in the context of this question (max length
> in the database, but not in the conceptual model)
> /not/ "in line with their users".
>
> [snip]
>> > I understand, and do not write-off, your point.
> >>>>>I do want the software product (as a whole) to limit
> >>>>>anything which has a conceptual limit.
> >>>>
> >>>>This is a reason to put the conceptual limits as
> >>>>close to the data as possible. If they are enforced in
> >>>>the database the rest of the software product
> >>>>has to follow suit. Any other way isn't
> >>>>garantueed, is it?
> >>>
> >>>Nothin' is guaranteed, mAsterdam, I undertsand your point.
> >>
> >>Your "there should be no data entry widget that permits entry of
> >>more than 2 characters for a state code" tells me you have not
> >>digested that understanding.
> >
> > No, it tells you that I have not adopted it as my own opinion.
> > It still isn't mine, however.
>
> I am not convinced you do.
> However we may reserve this topic for another thread :-)
Fair enough.
> >>>I'll just say that if there is such a constraint,
> >>>then the overall solution must enforce that one way or
> >>>another, over time, optimizing integrity, maintainability, etc.
> >>>I'll otherwise sidestep your question as it
> >>>might relate to my latest blog entry on constraints, and I understand
> >>>I've only addressed a tiny piece of the puzzle and there is much more
> >>>that could be said regarding cases where there are business rules to be
> >>>enforced.
> >>>
> >>>For this question, I'm interested in cases where there is no such
> >>>conceptual constraint.
> >>>
> >>>
> >>>>>>There is nothing specific to RM here.
> >>>
> >>>It sounds unanimous so far.
> >>
> >>We can't have that, can we - should I introduce NOT NULL?
> >>Nah :-)
> >>
> >>
> >>>I'm still left to guess precisely why what
> >>>are sometimes called RDBMS's are implemented this way, while others
> >>>might not be.
> >>
> >>Which ones?
> >
> >
> > I seems like all the big ones are such that those using them seem to
> > always select max lengths, so I asked if it was the case and if so, why
> > those who wrote the DBMS did not make that optional without penalty (or
> > did some of them?)
> >
> >
> >>I am really not nitpicking that DB2, SQLserver, Oracle and
> >>PostgreSQL aren't true R DBMS's.
> >>
> >>
> >>>Possible answers have been: 1) it has to do with the
> >>>representation of the data, helping developers not have to truncate or
> >>>decide how to abbreviate if they don't have enough space in some input
> >>>or output document. 2) it helps for optimization.
> >>>
> >>>I was aware of the benefits and problems of 1). I was guessing 2) was
> >>>the case, but would like to better understand why the implementations
> >>>are such that these individual numbers help enough to require them
> >>>(except with clogs, and it would be practical to implement an Oracle
> >>>solution with all strings declared as clogs) while in other
> >>>implementations they are not deemed important enough to require. It
> >>>might just be tradition, but in any case, I'd like to understand
> >>>better.
> >>
> >>It would help if you acknowledged that the designers
> >>of the database have this reponsability, and not the
> >>designers of the dbms.
> >
> > Yes, the database designers select max lengths, and
> > the dbms designers choose whether and how big a
> > penalty would be if size were not declared.
>
> How so?
> >>They (the designers of the dbms) have the responsability to
> >>provide facilities for the db designers to specify them,
> >>and the facilities to enforce the specified constraints.
> >
> > And the option to provide a feature permitting app or db designers not
> > to specify a size., the option to default to variable length unless
> > otherwise specified, for example.
>
> And suddenly it's about providing clever defaults!
I somehow don't think that is what a Pick DBMS does. So, I don't think that is what it is about. As always, I could be missing something. Thanks. --dawn Received on Sun May 28 2006 - 22:17:28 CEST