Professional Web Applications Themes

To normalize or not - Microsoft SQL / MS SQL Server

I have a database that has repeated measures. PatientID, BPat5mins, BPat10mins, BPat15mins,...............BPat30mins. I am telling my co-worker that instead the table design should be PatientID, BP, TimeInterval My co-worker is telling me that the first way allows for easier grouping and aggregates. What do you guys think. Thanks, John...

  1. #1

    Default To normalize or not

    I have a database that has repeated measures. PatientID, BPat5mins,
    BPat10mins, BPat15mins,...............BPat30mins.

    I am telling my co-worker that instead the table design should be
    PatientID, BP, TimeInterval

    My co-worker is telling me that the first way allows for easier grouping and
    aggregates. What do you guys think.

    Thanks,
    John


    topdog Guest

  2. #2

    Default Re: To normalize or not

    I would go with the second approach. I don't want to add a new column to my
    table, when we decide to measure BP at a new interval.
    --
    HTH,
    Vyas, MVP (SQL Server)
    http://vyaskn.tripod.com/
    What hardware is your SQL Server running on?
    http://vyaskn.tripod.com/poll.htm


    "topdog" <com> wrote in message
    news:%phx.gbl...
    I have a database that has repeated measures. PatientID, BPat5mins,
    BPat10mins, BPat15mins,...............BPat30mins.

    I am telling my co-worker that instead the table design should be
    PatientID, BP, TimeInterval

    My co-worker is telling me that the first way allows for easier grouping and
    aggregates. What do you guys think.

    Thanks,
    John



    Narayana Guest

  3. #3

    Default Re: To normalize or not

    Hello TopDog (Wonder if this is your realname and EMailAdress :)) )

    Normalization should be always aimed. The first solution of your colleage is
    NOT really good. Perhaps you save time by not joing another table with
    times, but...

    You will be always stuck with minutes, you can´t change the time column to
    another interval without writing it down in characters, when you sum them,
    you have to chop the minutes and then sum the values. Not recommendable!

    Jens Süßmeyer.



    Jens Guest

  4. #4

    Default Re: To normalize or not

    Mhhhm..

    How deep normalisation goes depends on you. I would use a second table to
    be able to change the name of the time interval as i wanted.

    When is would query the database i would use a dynamic sql or a function to
    calculate the times to a common format.

    That the say dbs goes :))


    HTH, Jens Süßmeyer.


    Jens Guest

  5. #5

    Default Re: To normalize or not

    Anyone else have some strong opinions on this? It doesn't seem that it
    really matters either way from what I"m getting so far.

    Thanks


    "topdog" <com> wrote in message
    news:%phx.gbl... 
    and 


    topdog Guest

  6. #6

    Default Re: To normalize or not

    >> Anyone else have some strong opinions on this? It doesn't seem that it
    really matters either way from what I"m getting so far. <<

    This is not a matter of strong opinions since generic suggestions are not
    always applicable to your specific logical design.

    Ask yourself some basic questions. What is the flaw with your co-worker's
    approach? What will you do when you have an additional time interval, alter
    the table? What is an actual attribute to your patient entity, BPat5mins or
    BP? Can TimeInterval be a valid attribute? Remember, in relational model, a
    table represents a valid entity type, a row represents a valid entity of
    that type and the columns represent valid attributes of that entity.

    The correct way to approach this is to first understand and yze all your
    business rules and relevant data requirements. Get someone (if you are not)
    with fundamental understanding on the normalization rules to yze your
    model. A simple walkthrough can reveal if this violates 1NF or not.

    --
    - Anith
    ( Please reply to newsgroups only )


    Anith Guest

  7. #7

    Default Re: To normalize or not

    To add my .02, the normalized approach is definitely the most flexible.
    Personally, I would go with that unless you have a good reason to do
    otherwise. If you don't have the SQL expertise to group and aggregate
    the normalized data, one can argue that is justification for
    denormalization.

    It's common to deploy specialized reporting databases to simplify
    reporting and improve performance. However, the operational database
    schema is often left normalized.

    --
    Hope this helps.

    Dan Guzman
    SQL Server MVP

    -----------------------
    SQL FAQ links (courtesy Neil Pike):

    http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
    http://www.sqlserverfaq.com
    http://www.mssqlserver.com/faq
    -----------------------

    "topdog" <com> wrote in message
    news:uqdfsu$phx.gbl... 
    it [/ref]
    BPat5mins, [/ref]
    grouping 
    >
    >[/ref]


    Dan Guest

  8. #8

    Default Re: To normalize or not

    On Thu, 21 Aug 2003 11:38:22 -0500, "Dan Guzman"
    <net> wrote:
     

    It's often the simplest, too, when you have anything beyond the most
    trivial integrity constraints.

    --
    Mike Sherrill
    Information Management Systems
    Mike Guest

Similar Threads

  1. Normalize Audio levels on record???
    By rgmoto in forum Macromedia Flash Flashcom
    Replies: 2
    Last Post: March 4th, 09:26 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139