Designing a schema for an entity with 40 attributes












0















I am having a doubt on designing a schema for my current project in MySQL.



It is mainly because there is an entity that I made and has 40 attributes.



The table/entity X contain of fields like: collection of personal information, physical attributes (such as hair color, eye color, height, etc) mostly a varchar with less than 10 chars.



The question is:
Should I break the attributes into another table or let it stays in one table X with all those 40 attributes with it?










share|improve this question
















bumped to the homepage by Community 3 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.




















    0















    I am having a doubt on designing a schema for my current project in MySQL.



    It is mainly because there is an entity that I made and has 40 attributes.



    The table/entity X contain of fields like: collection of personal information, physical attributes (such as hair color, eye color, height, etc) mostly a varchar with less than 10 chars.



    The question is:
    Should I break the attributes into another table or let it stays in one table X with all those 40 attributes with it?










    share|improve this question
















    bumped to the homepage by Community 3 mins ago


    This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.


















      0












      0








      0








      I am having a doubt on designing a schema for my current project in MySQL.



      It is mainly because there is an entity that I made and has 40 attributes.



      The table/entity X contain of fields like: collection of personal information, physical attributes (such as hair color, eye color, height, etc) mostly a varchar with less than 10 chars.



      The question is:
      Should I break the attributes into another table or let it stays in one table X with all those 40 attributes with it?










      share|improve this question
















      I am having a doubt on designing a schema for my current project in MySQL.



      It is mainly because there is an entity that I made and has 40 attributes.



      The table/entity X contain of fields like: collection of personal information, physical attributes (such as hair color, eye color, height, etc) mostly a varchar with less than 10 chars.



      The question is:
      Should I break the attributes into another table or let it stays in one table X with all those 40 attributes with it?







      mysql database-design eav






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 24 '17 at 22:17









      a_horse_with_no_name

      40.3k777112




      40.3k777112










      asked Jan 24 '17 at 12:57









      PragmaticoderPragmaticoder

      11




      11





      bumped to the homepage by Community 3 mins ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







      bumped to the homepage by Community 3 mins ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
























          2 Answers
          2






          active

          oldest

          votes


















          0














          Having a table with 40 columns is not an issue. Issue raises only how these attributes are getting updated provided there is no concurrent updates of the Attributes. Otherwise there will be an issue with locking.






          share|improve this answer































            0














            Designing : functional dependency should be a guide to be sure that all 40 attributes are i the same entity :




            • your entity must have an identifier

            • (all attributes must be atomics)

            • all other attributes must be functionally dependent of the identifier


            in other terms : for a unique value (occurrence) of the identifier, you must get one unique value of each of the other attributes.



            If not, you should break your entity.



            20 years ago, I had the same probleme with products and their caractéristics (100 or more). Below is the solution I used :




            • Product (idp, ...important/frequent attributes) (idp) PK

            • Caracteristic (idc, title, type of data) : (idc) PK

            • ProductCaracteristics (idp, idc, numeric value, string value), (idp, idc) PK, (idp) FK to Product, (idc) FK to Caracteristics


            It is evolutive but needs more data space.






            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
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f162063%2fdesigning-a-schema-for-an-entity-with-40-attributes%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









              0














              Having a table with 40 columns is not an issue. Issue raises only how these attributes are getting updated provided there is no concurrent updates of the Attributes. Otherwise there will be an issue with locking.






              share|improve this answer




























                0














                Having a table with 40 columns is not an issue. Issue raises only how these attributes are getting updated provided there is no concurrent updates of the Attributes. Otherwise there will be an issue with locking.






                share|improve this answer


























                  0












                  0








                  0







                  Having a table with 40 columns is not an issue. Issue raises only how these attributes are getting updated provided there is no concurrent updates of the Attributes. Otherwise there will be an issue with locking.






                  share|improve this answer













                  Having a table with 40 columns is not an issue. Issue raises only how these attributes are getting updated provided there is no concurrent updates of the Attributes. Otherwise there will be an issue with locking.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 24 '17 at 13:59









                  SQL.RKSQL.RK

                  1313




                  1313

























                      0














                      Designing : functional dependency should be a guide to be sure that all 40 attributes are i the same entity :




                      • your entity must have an identifier

                      • (all attributes must be atomics)

                      • all other attributes must be functionally dependent of the identifier


                      in other terms : for a unique value (occurrence) of the identifier, you must get one unique value of each of the other attributes.



                      If not, you should break your entity.



                      20 years ago, I had the same probleme with products and their caractéristics (100 or more). Below is the solution I used :




                      • Product (idp, ...important/frequent attributes) (idp) PK

                      • Caracteristic (idc, title, type of data) : (idc) PK

                      • ProductCaracteristics (idp, idc, numeric value, string value), (idp, idc) PK, (idp) FK to Product, (idc) FK to Caracteristics


                      It is evolutive but needs more data space.






                      share|improve this answer






























                        0














                        Designing : functional dependency should be a guide to be sure that all 40 attributes are i the same entity :




                        • your entity must have an identifier

                        • (all attributes must be atomics)

                        • all other attributes must be functionally dependent of the identifier


                        in other terms : for a unique value (occurrence) of the identifier, you must get one unique value of each of the other attributes.



                        If not, you should break your entity.



                        20 years ago, I had the same probleme with products and their caractéristics (100 or more). Below is the solution I used :




                        • Product (idp, ...important/frequent attributes) (idp) PK

                        • Caracteristic (idc, title, type of data) : (idc) PK

                        • ProductCaracteristics (idp, idc, numeric value, string value), (idp, idc) PK, (idp) FK to Product, (idc) FK to Caracteristics


                        It is evolutive but needs more data space.






                        share|improve this answer




























                          0












                          0








                          0







                          Designing : functional dependency should be a guide to be sure that all 40 attributes are i the same entity :




                          • your entity must have an identifier

                          • (all attributes must be atomics)

                          • all other attributes must be functionally dependent of the identifier


                          in other terms : for a unique value (occurrence) of the identifier, you must get one unique value of each of the other attributes.



                          If not, you should break your entity.



                          20 years ago, I had the same probleme with products and their caractéristics (100 or more). Below is the solution I used :




                          • Product (idp, ...important/frequent attributes) (idp) PK

                          • Caracteristic (idc, title, type of data) : (idc) PK

                          • ProductCaracteristics (idp, idc, numeric value, string value), (idp, idc) PK, (idp) FK to Product, (idc) FK to Caracteristics


                          It is evolutive but needs more data space.






                          share|improve this answer















                          Designing : functional dependency should be a guide to be sure that all 40 attributes are i the same entity :




                          • your entity must have an identifier

                          • (all attributes must be atomics)

                          • all other attributes must be functionally dependent of the identifier


                          in other terms : for a unique value (occurrence) of the identifier, you must get one unique value of each of the other attributes.



                          If not, you should break your entity.



                          20 years ago, I had the same probleme with products and their caractéristics (100 or more). Below is the solution I used :




                          • Product (idp, ...important/frequent attributes) (idp) PK

                          • Caracteristic (idc, title, type of data) : (idc) PK

                          • ProductCaracteristics (idp, idc, numeric value, string value), (idp, idc) PK, (idp) FK to Product, (idc) FK to Caracteristics


                          It is evolutive but needs more data space.







                          share|improve this answer














                          share|improve this answer



                          share|improve this answer








                          edited Jan 24 '17 at 22:03

























                          answered Jan 24 '17 at 17:17









                          Patrick DezecachePatrick Dezecache

                          11316




                          11316






























                              draft saved

                              draft discarded




















































                              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%2f162063%2fdesigning-a-schema-for-an-entity-with-40-attributes%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

                              SQL Server 17 - Attemping to backup to remote NAS but Access is denied

                              Always On Availability groups resolving state after failover - Remote harden of transaction...

                              Restoring from pg_dump with foreign key constraints