Loading ...
Sorry, an error occurred while loading the content.

Re: On enforcing data type standards

Expand Messages
  • askhadkikar
    Hi Andrew, I agree with you totally. One usually resorts to precise definitions for two reasons: 1. Data validation - If I retain the data type as NUMBER for a
    Message 1 of 35 , Feb 20, 2008
    • 0 Attachment
      Hi Andrew,

      I agree with you totally. One usually resorts to precise definitions
      for two reasons:

      1. Data validation - If I retain the data type as NUMBER for a column
      that hosts percentages, then I can even end up entering values such as
      10000.543 because the column data type allows it. Ditto for the
      VARCHAR2 columns.

      2. The use of Hibernate is also to provision database independence.
      Different RDBMS's have different implementations...though in future I
      believe they will converge on common sense, a strategy of precise
      definitions gives more confidence in the schema.

      The second point can go wrong if the RDBMS uses a padded character
      data type implementation :) Hence the stress on performance too in my
      arguments.

      --- In agileDatabases@yahoogroups.com, Andrew Gregovich
      <andrew_gregovich@...> wrote:
      >
      > By the way, in Oracle a VARCHAR is a VARCHAR is a VARCHAR, and
      NUMBER is a NUMBER is a NUMBER too. Both datatypes are variable length
      and for NUMBER you don't even need to specify the max length - it's
      more for rule enforcement and documentation purposes.
      >
      > Regards
      >
      > Andrew
      >
      > ----- Original Message ----
      > From: askhadkikar <askhadkikar@...>
      > To: agileDatabases@yahoogroups.com
      > Sent: Wednesday, February 20, 2008 4:25:04 PM
      > Subject: [agileDatabases] Re: On enforcing data type standards
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      > Hi!
      >
      > Thanks for the responses. I think the usage of Hungarian notation for
      >
      > coding has met with wide criticisms. My original question basically
      >
      > revolved around defining and implementing domains at the database
      >
      > tier. Correct sizing of data types is very important from a
      >
      > performance perspective. Imagine having a number column that serves as
      >
      > a boolean condition holder being defined as a NUMBER(22) while it's
      >
      > actual requirement is NUMBER(1). The problems arise when mapping Java
      >
      > types to column data types. Perhaps (I am not a programmer), for the
      >
      > compiler a String is a String is a String...but at the database end it
      >
      > matters a lot from both a storage and an I/O perspective. Hence the
      >
      > need to define and implement domains and correctly size the data
      lengths.
      >
      >
      >
      > Without having access to a data modeling tool, the method that was
      >
      > outlined in the original post, I felt tackled the issue. I was looking
      >
      > for alternative strategies on implementing and ensuring that domains
      >
      > (data types) are correctly implemented in the schema. The Hungarian
      >
      > notation method looked useful as it allowed me to write test cases by
      >
      > searching for a qualifier substring in the column name itself.
      >
      > Without using Hungarian notation how could I have enforced schema data
      >
      > type standardization and it's implementation was my actual question.
      >
      >
      >
      > David - thanks for the response. In Oracle I cannot update the
      >
      > definition of the user defined type if there are dependent objects.
      >
      >
      >
      > - Aniruddha
      >
      >
      >
      > --- In agileDatabases@ yahoogroups. com, "David Lawrence"
      >
      > <david_s_lawrence@ ...> wrote:
      >
      > >
      >
      > > -
      >
      > > > Exactly. It's an obsolete approach, best used with languages
      >
      > > > that are (or should be) obsolete.
      >
      > > >
      >
      > > > John Roth
      >
      > > >
      >
      > > > >
      >
      > >
      >
      > > Actually, the use of domains is a best practices approach to database
      >
      > > design. In the first place, all texts recommend that you begin models
      >
      > > by determining the domains of your variables (this is actually
      >
      > > equivalent to classes in Object Oriented languages). Variables can be
      >
      > > defined only in the context of their domains, NOT their data types.
      >
      > >
      >
      > > Besides being the textbook solution, the real advantage of domains
      >
      > > comes when you are trying to name attributes. For example, a numeric
      >
      > > value could belong to a -NBR, - QTY, or -RT domain. I have repeatedly
      >
      > > found that, by classifying the domain first, it greatly eases the
      >
      > > naming and classification of an attribute.
      >
      > >
      >
      > > For reference, any book by C.J. Date will stress the importance of
      >
      > > domains. Microsoft has a standard class naming document that can serve
      >
      > > as a basis for internal standards. However, you may very much want to
      >
      > > add your own domains as needed, for example, using -COORD to indicate
      >
      > > geographic coordinates.
      >
      > >
      >
      > > Another huge advantage of domains is that, at the model level, it
      >
      > > allows global updates for any change you may have to make. For
      >
      > > example, if it is decided that a -CD field (Codes) should increase its
      >
      > > length from VARCHAR(10) to VARCHAR(20), you would only have to make
      >
      > > the change in the model once, rather than for every code attribute in
      >
      > > the model.
      >
      > >
      >
      > > Additionally, in many databases (though not Oracle), domains can be
      >
      > > created at the database level as user-defined types. This allows
      >
      > > global changes in the database by merely updating the user-defined
      >
      > types.
      >
      > >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      > <!--
      >
      > #ygrp-mkp{
      > border:1px solid #d8d8d8;font-family:Arial;margin:14px
      0px;padding:0px 14px;}
      > #ygrp-mkp hr{
      > border:1px solid #d8d8d8;}
      > #ygrp-mkp #hd{
      >
      color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;margin:10px
      0px;}
      > #ygrp-mkp #ads{
      > margin-bottom:10px;}
      > #ygrp-mkp .ad{
      > padding:0 0;}
      > #ygrp-mkp .ad a{
      > color:#0000ff;text-decoration:none;}
      > -->
      >
      >
      >
      > <!--
      >
      > #ygrp-sponsor #ygrp-lc{
      > font-family:Arial;}
      > #ygrp-sponsor #ygrp-lc #hd{
      > margin:10px 0px;font-weight:bold;font-size:78%;line-height:122%;}
      > #ygrp-sponsor #ygrp-lc .ad{
      > margin-bottom:10px;padding:0 0;}
      > -->
      >
      >
      >
      > <!--
      >
      > #ygrp-mlmsg {font-size:13px;font-family:arial, helvetica, clean,
      sans-serif;}
      > #ygrp-mlmsg table {font-size:inherit;font:100%;}
      > #ygrp-mlmsg select, input, textarea {font:99% arial, helvetica,
      clean, sans-serif;}
      > #ygrp-mlmsg pre, code {font:115% monospace;}
      > #ygrp-mlmsg * {line-height:1.22em;}
      > #ygrp-text{
      > font-family:Georgia;
      > }
      > #ygrp-text p{
      > margin:0 0 1em 0;}
      > #ygrp-tpmsgs{
      > font-family:Arial;
      > clear:both;}
      > #ygrp-vitnav{
      > padding-top:10px;font-family:Verdana;font-size:77%;margin:0;}
      > #ygrp-vitnav a{
      > padding:0 1px;}
      > #ygrp-actbar{
      > clear:both;margin:25px
      0;white-space:nowrap;color:#666;text-align:right;}
      > #ygrp-actbar .left{
      > float:left;white-space:nowrap;}
      > .bld{font-weight:bold;}
      > #ygrp-grft{
      > font-family:Verdana;font-size:77%;padding:15px 0;}
      > #ygrp-ft{
      > font-family:verdana;font-size:77%;border-top:1px solid #666;
      > padding:5px 0;
      > }
      > #ygrp-mlmsg #logo{
      > padding-bottom:10px;}
      >
      > #ygrp-vital{
      > background-color:#e0ecee;margin-bottom:20px;padding:2px 0 8px 8px;}
      > #ygrp-vital #vithd{
      >
      font-size:77%;font-family:Verdana;font-weight:bold;color:#333;text-transform:uppercase;}
      > #ygrp-vital ul{
      > padding:0;margin:2px 0;}
      > #ygrp-vital ul li{
      > list-style-type:none;clear:both;border:1px solid #e0ecee;
      > }
      > #ygrp-vital ul li .ct{
      >
      font-weight:bold;color:#ff7900;float:right;width:2em;text-align:right;padding-right:.5em;}
      > #ygrp-vital ul li .cat{
      > font-weight:bold;}
      > #ygrp-vital a{
      > text-decoration:none;}
      >
      > #ygrp-vital a:hover{
      > text-decoration:underline;}
      >
      > #ygrp-sponsor #hd{
      > color:#999;font-size:77%;}
      > #ygrp-sponsor #ov{
      > padding:6px 13px;background-color:#e0ecee;margin-bottom:20px;}
      > #ygrp-sponsor #ov ul{
      > padding:0 0 0 8px;margin:0;}
      > #ygrp-sponsor #ov li{
      > list-style-type:square;padding:6px 0;font-size:77%;}
      > #ygrp-sponsor #ov li a{
      > text-decoration:none;font-size:130%;}
      > #ygrp-sponsor #nc{
      > background-color:#eee;margin-bottom:20px;padding:0 8px;}
      > #ygrp-sponsor .ad{
      > padding:8px 0;}
      > #ygrp-sponsor .ad #hd1{
      >
      font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%;}
      > #ygrp-sponsor .ad a{
      > text-decoration:none;}
      > #ygrp-sponsor .ad a:hover{
      > text-decoration:underline;}
      > #ygrp-sponsor .ad p{
      > margin:0;}
      > o{font-size:0;}
      > .MsoNormal{
      > margin:0 0 0 0;}
      > #ygrp-text tt{
      > font-size:120%;}
      > blockquote{margin:0 0 0 4px;}
      > .replbq{margin:4;}
      > -->
      >
      >
      >
      >
      >
      >
      >
      >
      >
      ____________________________________________________________________________________
      > Never miss a thing. Make Yahoo your home page.
      > http://www.yahoo.com/r/hs
      >
      > [Non-text portions of this message have been removed]
      >
    • David Portas
      ... What distinction? The term data type is surely an obvious tautology. ... You mean users can create new types. Of course. ... But that s exactly what a
      Message 35 of 35 , Feb 21, 2008
      • 0 Attachment
        On 21/02/2008, David Lawrence <david_s_lawrence@...> wrote:
        >
        > I think that the disagreement over the Domain/Type syllogism was
        > because of a failure, at lest on my part, to distinguish between
        > "type" and "data type."

        What distinction? The term "data type" is surely an obvious tautology.

        > The original problem had been expressed in
        > terms of data types such as CHAR(20), etc. What David Portas had been
        > referring to what the pure concept of a type. I had previously
        > mentioned that, at the database level, domains can be enforced through
        > user defined types.

        You mean users can create new types. Of course.

        > It is the use of these user defined types is what
        > plays a crucial role in the ability to create robust object/relational
        > applications. However, the user defined data type is far more rich
        > than simply the declaration of a data type, say VARCHAR(25). The used
        > of the domains/user defined data types allows for universality: any
        > attribute with a PART domain, for example, will share the character
        > tics and constraints of the underlying domain.

        But that's exactly what a type IS. Any number of attributes can have
        the same type. I don't see what you are driving at.

        > I am not quite clear why David Portas does not believe that
        > constraints at the attribute level are a part of a user defined type.

        At the very least I have some doubts about which kinds of constraint
        could qualify as part of a type. What if a constraint references other
        attributes in the same table? Or values from another table? These
        would presumably be non-deterministic types because the permitted
        values could change at any moment. That is certainly not TTM's model.
        In Tutorial D types are orthogonal to relvar constraints. Type
        definitions are a separate syntax altogether.

        --
        David Portas
      Your message has been successfully submitted and would be delivered to recipients shortly.