Should I split timestamp parts into separate columns?Should we add extra 5 columns or build a separate table?Should I separate frequently updated columns?Is it worth to separate columns into multiple tables for one-to-one relational tableAre triggers bad for created/timestamp columns?Split two rows into two columnsShould I split this large table into three smaller tables?Should I move repeating foreign keys into separate table?Extracting 'hot columns' into a separate tableTransfer microsecond timestamp into table using COPYDatabase performance improvements for current setup. (mysql - marriaDB)

Second map without labels

Burned out due to current job, Can I take a week of vacation between jobs?

Can a UK national work as a paid shop assistant in the USA?

Does "was machen sie" have the greeting meaning of "what do you do"?

Best shape for a necromancer's undead minions for battle?

Why did Jon Snow admit his fault in S08E06?

Can “du tout” be used positively?

Using too much dialogue?

How to make parshape work inside a tikz node?

Who knighted this character?

Are cells guaranteed to get at least one mitochondrion when they divide?

Why did it take so long for Germany to allow electric scooters / e-rollers on the roads?

Can you still travel to America on the ESTA waiver program if you have been to Iran in transit?

Why do the i8080 I/O instructions take a byte-sized operand to determine the port?

Why isn't 'chemically-strengthened glass' made with potassium carbonate? To begin with?

A burglar's sunglasses, a lady's odyssey

Why is the Eisenstein ideal paper so great?

How would a developer who mostly fixed bugs for years at a company call out their contributions in their CV?

Is it legal to have an abortion in another state or abroad?

Why is this integration method not valid?

Do copyright notices need to be placed at the beginning of a file?

Expected maximum number of unpaired socks

3 prong range outlet

How did the Unsullied find out that Jon did this?



Should I split timestamp parts into separate columns?


Should we add extra 5 columns or build a separate table?Should I separate frequently updated columns?Is it worth to separate columns into multiple tables for one-to-one relational tableAre triggers bad for created/timestamp columns?Split two rows into two columnsShould I split this large table into three smaller tables?Should I move repeating foreign keys into separate table?Extracting 'hot columns' into a separate tableTransfer microsecond timestamp into table using COPYDatabase performance improvements for current setup. (mysql - marriaDB)






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








2















I am building a PostgreSQL database and I have created a timestamp table, where the primary key is the timestamp itself (e.g. id: Fri Apr 13 2018 15:00:19). The database is supposed to be later migrated to a data warehouse, from which analytics will be extracted.



At this point, I am wondering whether it is beneficial to add extra columns to the timestamp table, containing the parsed metrics such as the example below, or have a single table with the ID's.



id | year | month | day | hour | minutes | seconds
-------------------------------------------------------------------------
Fri Apr 13 2018 15:00:19 | 2018 | 4 | 13 | 15 | 0 | 19


vs


id
-------------------------
Fri Apr 13 2018 15:00:19


My goal is to achieve the best performance possible when querying the data warehouse, so I'm assuming having the timestamp split accordingly will result in faster queries rather than unzipping time metrics in real-time:



SELECT * FROM timestamp_table WHERE year = 2018 /* Querying values already parsed */

vs

SELECT * FROM timestamp_table WHERE YEAR(timestamp_id) = 2018 /* Parsing in real-time*/


I would appreciate some best practices input on this.










share|improve this question









New contributor



Khabz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.



















  • Add fields you need and update them in triggers.

    – Akina
    12 hours ago











  • Is the timestamp updated when the record is updated? If not, the warehouse will need to use other methods to identify changed records, like checksums, and the timestamp may not be useful at all.

    – Jon of All Trades
    7 hours ago

















2















I am building a PostgreSQL database and I have created a timestamp table, where the primary key is the timestamp itself (e.g. id: Fri Apr 13 2018 15:00:19). The database is supposed to be later migrated to a data warehouse, from which analytics will be extracted.



At this point, I am wondering whether it is beneficial to add extra columns to the timestamp table, containing the parsed metrics such as the example below, or have a single table with the ID's.



id | year | month | day | hour | minutes | seconds
-------------------------------------------------------------------------
Fri Apr 13 2018 15:00:19 | 2018 | 4 | 13 | 15 | 0 | 19


vs


id
-------------------------
Fri Apr 13 2018 15:00:19


My goal is to achieve the best performance possible when querying the data warehouse, so I'm assuming having the timestamp split accordingly will result in faster queries rather than unzipping time metrics in real-time:



SELECT * FROM timestamp_table WHERE year = 2018 /* Querying values already parsed */

vs

SELECT * FROM timestamp_table WHERE YEAR(timestamp_id) = 2018 /* Parsing in real-time*/


I would appreciate some best practices input on this.










share|improve this question









New contributor



Khabz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.



















  • Add fields you need and update them in triggers.

    – Akina
    12 hours ago











  • Is the timestamp updated when the record is updated? If not, the warehouse will need to use other methods to identify changed records, like checksums, and the timestamp may not be useful at all.

    – Jon of All Trades
    7 hours ago













2












2








2








I am building a PostgreSQL database and I have created a timestamp table, where the primary key is the timestamp itself (e.g. id: Fri Apr 13 2018 15:00:19). The database is supposed to be later migrated to a data warehouse, from which analytics will be extracted.



At this point, I am wondering whether it is beneficial to add extra columns to the timestamp table, containing the parsed metrics such as the example below, or have a single table with the ID's.



id | year | month | day | hour | minutes | seconds
-------------------------------------------------------------------------
Fri Apr 13 2018 15:00:19 | 2018 | 4 | 13 | 15 | 0 | 19


vs


id
-------------------------
Fri Apr 13 2018 15:00:19


My goal is to achieve the best performance possible when querying the data warehouse, so I'm assuming having the timestamp split accordingly will result in faster queries rather than unzipping time metrics in real-time:



SELECT * FROM timestamp_table WHERE year = 2018 /* Querying values already parsed */

vs

SELECT * FROM timestamp_table WHERE YEAR(timestamp_id) = 2018 /* Parsing in real-time*/


I would appreciate some best practices input on this.










share|improve this question









New contributor



Khabz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I am building a PostgreSQL database and I have created a timestamp table, where the primary key is the timestamp itself (e.g. id: Fri Apr 13 2018 15:00:19). The database is supposed to be later migrated to a data warehouse, from which analytics will be extracted.



At this point, I am wondering whether it is beneficial to add extra columns to the timestamp table, containing the parsed metrics such as the example below, or have a single table with the ID's.



id | year | month | day | hour | minutes | seconds
-------------------------------------------------------------------------
Fri Apr 13 2018 15:00:19 | 2018 | 4 | 13 | 15 | 0 | 19


vs


id
-------------------------
Fri Apr 13 2018 15:00:19


My goal is to achieve the best performance possible when querying the data warehouse, so I'm assuming having the timestamp split accordingly will result in faster queries rather than unzipping time metrics in real-time:



SELECT * FROM timestamp_table WHERE year = 2018 /* Querying values already parsed */

vs

SELECT * FROM timestamp_table WHERE YEAR(timestamp_id) = 2018 /* Parsing in real-time*/


I would appreciate some best practices input on this.







postgresql database-design query-performance optimization timestamp






share|improve this question









New contributor



Khabz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










share|improve this question









New contributor



Khabz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








share|improve this question




share|improve this question








edited 2 hours ago









MDCCL

6,90331846




6,90331846






New contributor



Khabz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








asked 13 hours ago









KhabzKhabz

1113




1113




New contributor



Khabz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




New contributor




Khabz is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • Add fields you need and update them in triggers.

    – Akina
    12 hours ago











  • Is the timestamp updated when the record is updated? If not, the warehouse will need to use other methods to identify changed records, like checksums, and the timestamp may not be useful at all.

    – Jon of All Trades
    7 hours ago

















  • Add fields you need and update them in triggers.

    – Akina
    12 hours ago











  • Is the timestamp updated when the record is updated? If not, the warehouse will need to use other methods to identify changed records, like checksums, and the timestamp may not be useful at all.

    – Jon of All Trades
    7 hours ago
















Add fields you need and update them in triggers.

– Akina
12 hours ago





Add fields you need and update them in triggers.

– Akina
12 hours ago













Is the timestamp updated when the record is updated? If not, the warehouse will need to use other methods to identify changed records, like checksums, and the timestamp may not be useful at all.

– Jon of All Trades
7 hours ago





Is the timestamp updated when the record is updated? If not, the warehouse will need to use other methods to identify changed records, like checksums, and the timestamp may not be useful at all.

– Jon of All Trades
7 hours ago










2 Answers
2






active

oldest

votes


















6














Keep the timestamp and don't add columns for the parts.



If you need to search for part of a timestamp, you can always create indexes on extract expressions.



Having individual columns wastes space and adds undesirable redundancy for no benefit I can envision.






share|improve this answer























  • In that case should I have a separate table or have the timestamp object inside each table?

    – Khabz
    10 hours ago












  • Also, is it not ok to have some redundancy if that's gonna (positively) impact performance when querying the data?

    – Khabz
    10 hours ago






  • 2





    Normally you shouldn't store the same information redundantly. If you get a notable performance benefit, exceptions are ok. If that is the case for storing the same timestamps in several tables depends on your data model and your queries. But I am quite sure that you won't get a performance benefit from storing the several parts of a timestamp separately.

    – Laurenz Albe
    9 hours ago


















4














You seem to be engaging in premature optimization -- you should not assume performance characteristics of any particular design, but test them.



When you store components of a timestamp value in separate columns you may not gain noticeable performance benefits, but you will increase the risk of inconsistent data or the maintenance overhead (or both).



Having said that, there may be valid reasons to store some components of the timestamp as separate columns, for example:



  • Components, such as year, quarter, month constitute valid dimensions in your data warehouse model.

  • Your database physical design calls for data partitioning by time intervals to facilitate maintenance or improve performance of some operations.





share|improve this answer























    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "182"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );






    Khabz is a new contributor. Be nice, and check out our Code of Conduct.









    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f238669%2fshould-i-split-timestamp-parts-into-separate-columns%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    6














    Keep the timestamp and don't add columns for the parts.



    If you need to search for part of a timestamp, you can always create indexes on extract expressions.



    Having individual columns wastes space and adds undesirable redundancy for no benefit I can envision.






    share|improve this answer























    • In that case should I have a separate table or have the timestamp object inside each table?

      – Khabz
      10 hours ago












    • Also, is it not ok to have some redundancy if that's gonna (positively) impact performance when querying the data?

      – Khabz
      10 hours ago






    • 2





      Normally you shouldn't store the same information redundantly. If you get a notable performance benefit, exceptions are ok. If that is the case for storing the same timestamps in several tables depends on your data model and your queries. But I am quite sure that you won't get a performance benefit from storing the several parts of a timestamp separately.

      – Laurenz Albe
      9 hours ago















    6














    Keep the timestamp and don't add columns for the parts.



    If you need to search for part of a timestamp, you can always create indexes on extract expressions.



    Having individual columns wastes space and adds undesirable redundancy for no benefit I can envision.






    share|improve this answer























    • In that case should I have a separate table or have the timestamp object inside each table?

      – Khabz
      10 hours ago












    • Also, is it not ok to have some redundancy if that's gonna (positively) impact performance when querying the data?

      – Khabz
      10 hours ago






    • 2





      Normally you shouldn't store the same information redundantly. If you get a notable performance benefit, exceptions are ok. If that is the case for storing the same timestamps in several tables depends on your data model and your queries. But I am quite sure that you won't get a performance benefit from storing the several parts of a timestamp separately.

      – Laurenz Albe
      9 hours ago













    6












    6








    6







    Keep the timestamp and don't add columns for the parts.



    If you need to search for part of a timestamp, you can always create indexes on extract expressions.



    Having individual columns wastes space and adds undesirable redundancy for no benefit I can envision.






    share|improve this answer













    Keep the timestamp and don't add columns for the parts.



    If you need to search for part of a timestamp, you can always create indexes on extract expressions.



    Having individual columns wastes space and adds undesirable redundancy for no benefit I can envision.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 11 hours ago









    Laurenz AlbeLaurenz Albe

    42711




    42711












    • In that case should I have a separate table or have the timestamp object inside each table?

      – Khabz
      10 hours ago












    • Also, is it not ok to have some redundancy if that's gonna (positively) impact performance when querying the data?

      – Khabz
      10 hours ago






    • 2





      Normally you shouldn't store the same information redundantly. If you get a notable performance benefit, exceptions are ok. If that is the case for storing the same timestamps in several tables depends on your data model and your queries. But I am quite sure that you won't get a performance benefit from storing the several parts of a timestamp separately.

      – Laurenz Albe
      9 hours ago

















    • In that case should I have a separate table or have the timestamp object inside each table?

      – Khabz
      10 hours ago












    • Also, is it not ok to have some redundancy if that's gonna (positively) impact performance when querying the data?

      – Khabz
      10 hours ago






    • 2





      Normally you shouldn't store the same information redundantly. If you get a notable performance benefit, exceptions are ok. If that is the case for storing the same timestamps in several tables depends on your data model and your queries. But I am quite sure that you won't get a performance benefit from storing the several parts of a timestamp separately.

      – Laurenz Albe
      9 hours ago
















    In that case should I have a separate table or have the timestamp object inside each table?

    – Khabz
    10 hours ago






    In that case should I have a separate table or have the timestamp object inside each table?

    – Khabz
    10 hours ago














    Also, is it not ok to have some redundancy if that's gonna (positively) impact performance when querying the data?

    – Khabz
    10 hours ago





    Also, is it not ok to have some redundancy if that's gonna (positively) impact performance when querying the data?

    – Khabz
    10 hours ago




    2




    2





    Normally you shouldn't store the same information redundantly. If you get a notable performance benefit, exceptions are ok. If that is the case for storing the same timestamps in several tables depends on your data model and your queries. But I am quite sure that you won't get a performance benefit from storing the several parts of a timestamp separately.

    – Laurenz Albe
    9 hours ago





    Normally you shouldn't store the same information redundantly. If you get a notable performance benefit, exceptions are ok. If that is the case for storing the same timestamps in several tables depends on your data model and your queries. But I am quite sure that you won't get a performance benefit from storing the several parts of a timestamp separately.

    – Laurenz Albe
    9 hours ago













    4














    You seem to be engaging in premature optimization -- you should not assume performance characteristics of any particular design, but test them.



    When you store components of a timestamp value in separate columns you may not gain noticeable performance benefits, but you will increase the risk of inconsistent data or the maintenance overhead (or both).



    Having said that, there may be valid reasons to store some components of the timestamp as separate columns, for example:



    • Components, such as year, quarter, month constitute valid dimensions in your data warehouse model.

    • Your database physical design calls for data partitioning by time intervals to facilitate maintenance or improve performance of some operations.





    share|improve this answer



























      4














      You seem to be engaging in premature optimization -- you should not assume performance characteristics of any particular design, but test them.



      When you store components of a timestamp value in separate columns you may not gain noticeable performance benefits, but you will increase the risk of inconsistent data or the maintenance overhead (or both).



      Having said that, there may be valid reasons to store some components of the timestamp as separate columns, for example:



      • Components, such as year, quarter, month constitute valid dimensions in your data warehouse model.

      • Your database physical design calls for data partitioning by time intervals to facilitate maintenance or improve performance of some operations.





      share|improve this answer

























        4












        4








        4







        You seem to be engaging in premature optimization -- you should not assume performance characteristics of any particular design, but test them.



        When you store components of a timestamp value in separate columns you may not gain noticeable performance benefits, but you will increase the risk of inconsistent data or the maintenance overhead (or both).



        Having said that, there may be valid reasons to store some components of the timestamp as separate columns, for example:



        • Components, such as year, quarter, month constitute valid dimensions in your data warehouse model.

        • Your database physical design calls for data partitioning by time intervals to facilitate maintenance or improve performance of some operations.





        share|improve this answer













        You seem to be engaging in premature optimization -- you should not assume performance characteristics of any particular design, but test them.



        When you store components of a timestamp value in separate columns you may not gain noticeable performance benefits, but you will increase the risk of inconsistent data or the maintenance overhead (or both).



        Having said that, there may be valid reasons to store some components of the timestamp as separate columns, for example:



        • Components, such as year, quarter, month constitute valid dimensions in your data warehouse model.

        • Your database physical design calls for data partitioning by time intervals to facilitate maintenance or improve performance of some operations.






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 7 hours ago









        mustacciomustaccio

        10.6k72343




        10.6k72343




















            Khabz is a new contributor. Be nice, and check out our Code of Conduct.









            draft saved

            draft discarded


















            Khabz is a new contributor. Be nice, and check out our Code of Conduct.












            Khabz is a new contributor. Be nice, and check out our Code of Conduct.











            Khabz is a new contributor. Be nice, and check out our Code of Conduct.














            Thanks for contributing an answer to Database Administrators Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f238669%2fshould-i-split-timestamp-parts-into-separate-columns%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Canceling a color specificationRandomly assigning color to Graphics3D objects?Default color for Filling in Mathematica 9Coloring specific elements of sets with a prime modified order in an array plotHow to pick a color differing significantly from the colors already in a given color list?Detection of the text colorColor numbers based on their valueCan color schemes for use with ColorData include opacity specification?My dynamic color schemes

            Invision Community Contents History See also References External links Navigation menuProprietaryinvisioncommunity.comIPS Community ForumsIPS Community Forumsthis blog entry"License Changes, IP.Board 3.4, and the Future""Interview -- Matt Mecham of Ibforums""CEO Invision Power Board, Matt Mecham Is a Liar, Thief!"IPB License Explanation 1.3, 1.3.1, 2.0, and 2.1ArchivedSecurity Fixes, Updates And Enhancements For IPB 1.3.1Archived"New Demo Accounts - Invision Power Services"the original"New Default Skin"the original"Invision Power Board 3.0.0 and Applications Released"the original"Archived copy"the original"Perpetual licenses being done away with""Release Notes - Invision Power Services""Introducing: IPS Community Suite 4!"Invision Community Release Notes

            François Viète Contents Biography Work and thought Bibliography See also Notes Further reading External links Navigation menup. 21Google Bookspp. 75–77Google BooksDe thou (from University of Saint Andrews)ArchivedGoogle BooksGoogle BooksGoogle BooksGoogle booksGoogle Bookscc-parthenay.frL'histoire universelle (fr)Universal History (en)ArchivedAdsabs.harvard.eduPagesperso-orange.frArchive.orgChikara Sasaki. Descartes' mathematical thought p.259Google BooksGoogle BooksGoogle Bookspp. 152 and onwardGoogle BooksGoogle BooksScribd.comGoogle Books1257-7979Google BooksGoogle BooksGoogle BooksGoogle BooksGoogle BooksGoogle BooksGallica.bnf.frGoogle BooksGoogle Books"François Viète"Francois Viète: Father of Modern Algebraic NotationThe Lawyer and the GamblerAbout TarporleySite de Jean-Paul GuichardL'algèbre nouvelle"About the Harmonicon"cb120511976(data)1188044800000 0001 0913 5903n82164680ola2013766880073431702w6vt1sb70287374827140948071409480