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

terminology for table

Expand Messages
  • Dermot
    Hi, I have a table, called users, that contains 52 fields. It holds all kinds of stuff: last_login, how_heard, other_how_heard, business_type...etc Much of
    Message 1 of 6 , Feb 3, 2010
      Hi,

      I have a table, called users, that contains 52 fields. It holds all
      kinds of stuff: last_login, how_heard, other_how_heard,
      business_type...etc Much of this data is....well slightly meta, for
      want of a better word. I want to keep this table as narrow (field
      wise) as possible because it gets hit a lot and most these fields are
      not what is being queried. There is an existing user_preferences table
      as well. If I were to hive off some of these fields, what would I call
      the new table; 'users_metadata' does really convey the meaning well.
      Any suggestions for a name? Do you think I'm being overly fussy about
      this tables contents?

      Thanks,
      Dp.
    • John Warner
      I don t see where any real gain could be had by doing this assuming you have indexes on the most popular WHERE/JOIN fields. Are your users doing things like:
      Message 2 of 6 , Feb 3, 2010
        I don't see where any real gain could be had by doing this assuming you
        have indexes on the most popular WHERE/JOIN fields. Are your users doing
        things like:
        SELECT *
        FROM table
        WHERE 1=1

        John Warner

        > -----Original Message-----
        > From: SQLQueriesNoCode@yahoogroups.com
        > [mailto:SQLQueriesNoCode@yahoogroups.com] On Behalf Of Dermot
        > Sent: Wednesday, February 03, 2010 1:16 PM
        > To: SQLQueriesNoCode@yahoogroups.com
        > Subject: [SQLQueriesNoCode] terminology for table
        >
        > Hi,
        >
        > I have a table, called users, that contains 52 fields. It holds all
        > kinds of stuff: last_login, how_heard, other_how_heard,
        > business_type...etc Much of this data is....well slightly meta, for
        > want of a better word. I want to keep this table as narrow (field
        > wise) as possible because it gets hit a lot and most these fields are
        > not what is being queried. There is an existing user_preferences table
        > as well. If I were to hive off some of these fields, what would I call
        > the new table; 'users_metadata' does really convey the meaning well.
        > Any suggestions for a name? Do you think I'm being overly fussy about
        > this tables contents?
        >
        > Thanks,
        > Dp.
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
      • Dermot
        I m not sure how SELECTs will be done. I will be using a ORM style DBI. There are methods that allow you to specify what columns to select, but the default
        Message 3 of 6 , Feb 3, 2010
          I'm not sure how SELECTs will be done. I will be using a ORM style
          DBI. There are methods that allow you to specify what columns to
          select, but the default returns a row object. I'm guessing that is *.

          Dp.


          On 3 February 2010 18:30, John Warner <john@...> wrote:
          > I don't see where any real gain could be had by doing this assuming you
          > have indexes on the most popular WHERE/JOIN fields. Are your users doing
          > things like:
          > SELECT *
          > FROM table
          > WHERE 1=1
          >
          > John Warner
          >
          > > -----Original Message-----
          > >
          > > Hi,
          > >
          > > I have a table, called users, that contains 52 fields. It holds all
          > > kinds of stuff: last_login, how_heard, other_how_heard,
          > > business_type...etc Much of this data is....well slightly meta, for
          > > want of a better word. I want to keep this table as narrow (field
          > > wise) as possible because it gets hit a lot and most these fields are
          > > not what is being queried. There is an existing user_preferences table
          > > as well. If I were to hive off some of these fields, what would I call
          > > the new table; 'users_metadata' does really convey the meaning well.
          > > Any suggestions for a name? Do you think I'm being overly fussy about
          > > this tables contents?
          > >
          > > Thanks,
          > > Dp.
          > >
        • Paul Livengood
          The table name does not matter so if you are ok with users_metadata then use that.  I am partial to UsersExtension, but that is only because i spend so much
          Message 4 of 6 , Feb 3, 2010
            The table name does not matter so if you are ok with "users_metadata" then use that.  I am partial to UsersExtension, but that is only because i spend so much time in CRM.
            Personally I would be against splitting the table.  This seems a case of modifying the database to accommodate bad user interface design.  This is not a good path to go down.  I would just make sure that your control only requests specific columns and not ‘*’.  Then make sure you have an index with those columns and the Read Request will never even go to the table for its information.
             
            HTH
            Paul




            ________________________________
            From: Dermot <paikkos@...>
            To: SQLQueriesNoCode@yahoogroups.com
            Sent: Wed, February 3, 2010 11:53:25 AM
            Subject: Re: [SQLQueriesNoCode] terminology for table

             
            I'm not sure how SELECTs will be done. I will be using a ORM style
            DBI. There are methods that allow you to specify what columns to
            select, but the default returns a row object. I'm guessing that is *.

            Dp.

            On 3 February 2010 18:30, John Warner <john@jwarner. com> wrote:
            > I don't see where any real gain could be had by doing this assuming you
            > have indexes on the most popular WHERE/JOIN fields. Are your users doing
            > things like:
            > SELECT *
            > FROM table
            > WHERE 1=1
            >
            > John Warner
            >
            > > -----Original Message-----
            > >
            > > Hi,
            > >
            > > I have a table, called users, that contains 52 fields. It holds all
            > > kinds of stuff: last_login, how_heard, other_how_heard,
            > > business_type. ..etc Much of this data is....well slightly meta, for
            > > want of a better word. I want to keep this table as narrow (field
            > > wise) as possible because it gets hit a lot and most these fields are
            > > not what is being queried. There is an existing user_preferences table
            > > as well. If I were to hive off some of these fields, what would I call
            > > the new table; 'users_metadata' does really convey the meaning well.
            > > Any suggestions for a name? Do you think I'm being overly fussy about
            > > this tables contents?
            > >
            > > Thanks,
            > > Dp.
            > >



            [Non-text portions of this message have been removed]
          • Dermot
            ... Thank you both. As the consensus seems be to leave the data where it is, I will. I am fortunate enough to be able to re-design the database schema. There
            Message 5 of 6 , Feb 3, 2010
              On 3 February 2010 19:15, Paul Livengood <p_livengood@...> wrote:

              > The table name does not matter so if you are ok with "users_metadata" then use that.  I am partial to UsersExtension, but that is only because i spend so much time in CRM.
              > Personally I would be against splitting the table.  This seems a case of modifying the database to accommodate bad user interface design.  This is not a good path to go down.  I would just make sure that your control only requests specific columns and not ‘*’.  Then make sure you have an index with those columns and the Read Request will never even go to the table for its information.

              Thank you both. As the consensus seems be to leave the data where it
              is, I will. I am fortunate enough to be able to re-design the database
              schema. There is lots of old, redundant data, such as ISDN number, and
              I thought I should, where possible, improve the structure. I have a
              enabled a trace on the DBI and it names the column in it's SELECT
              statement. I think it names all of them in a PREPARE statement.

              Thanks for the feedback.
              Dp.
            • Rob Richardson
              Greetings! My table has fields containing UTC times, although their types are timestamp without time zone. I would like to be able to convert a time from that
              Message 6 of 6 , Feb 11, 2010
                Greetings!

                My table has fields containing UTC times, although their types are
                timestamp without time zone. I would like to be able to convert a time
                from that field into my local time without specifying what time zone I'm
                in. Presumably, this would rely on my database (PostgreSQL) checking to
                see what the timezone setting of my computer is. Is there a way to do
                this?

                Thank you very much!

                RobR
              Your message has been successfully submitted and would be delivered to recipients shortly.