Length of varchar column - is there an advantage to using 255? [duplicate]












5
















This question already has an answer here:




  • MySQL - varchar length and performance

    1 answer




I often come across columns that are varchar(255), so presumably this is a convention of sorts. 255 is 2^8 - 1. So is there something 'magical' about lengths that are 2^n - 1? Or just specifically 255? Is there a performance or storage optimisation advantage to certain specific varchar lengths? Or is this just old wisdom which is no longer applicable to current versions of MariaDB and MySQL?










share|improve this question















marked as duplicate by Evan Carroll, Colin 't Hart, Michael Green, mustaccio, Vérace Jan 15 at 21:10


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • 1





    Do you need 255 characters?

    – McNets
    Jan 14 at 14:04











  • Historical reasons, at least according to stackoverflow.com/questions/1217466/…

    – Jonathan Fite
    Jan 14 at 14:05











  • @McNets I actually need more than 255, but since that number is used so often, I thought I should use that as an example.

    – dbdemon
    Jan 14 at 15:01











  • Simply use the length you need.

    – McNets
    Jan 14 at 15:23











  • @EvanCarroll thanks for pointing out this question. It's useful and similar, though not exactly the same because I'm asking about 'magical' lengths (2^n -1).

    – dbdemon
    Jan 14 at 19:08
















5
















This question already has an answer here:




  • MySQL - varchar length and performance

    1 answer




I often come across columns that are varchar(255), so presumably this is a convention of sorts. 255 is 2^8 - 1. So is there something 'magical' about lengths that are 2^n - 1? Or just specifically 255? Is there a performance or storage optimisation advantage to certain specific varchar lengths? Or is this just old wisdom which is no longer applicable to current versions of MariaDB and MySQL?










share|improve this question















marked as duplicate by Evan Carroll, Colin 't Hart, Michael Green, mustaccio, Vérace Jan 15 at 21:10


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • 1





    Do you need 255 characters?

    – McNets
    Jan 14 at 14:04











  • Historical reasons, at least according to stackoverflow.com/questions/1217466/…

    – Jonathan Fite
    Jan 14 at 14:05











  • @McNets I actually need more than 255, but since that number is used so often, I thought I should use that as an example.

    – dbdemon
    Jan 14 at 15:01











  • Simply use the length you need.

    – McNets
    Jan 14 at 15:23











  • @EvanCarroll thanks for pointing out this question. It's useful and similar, though not exactly the same because I'm asking about 'magical' lengths (2^n -1).

    – dbdemon
    Jan 14 at 19:08














5












5








5









This question already has an answer here:




  • MySQL - varchar length and performance

    1 answer




I often come across columns that are varchar(255), so presumably this is a convention of sorts. 255 is 2^8 - 1. So is there something 'magical' about lengths that are 2^n - 1? Or just specifically 255? Is there a performance or storage optimisation advantage to certain specific varchar lengths? Or is this just old wisdom which is no longer applicable to current versions of MariaDB and MySQL?










share|improve this question

















This question already has an answer here:




  • MySQL - varchar length and performance

    1 answer




I often come across columns that are varchar(255), so presumably this is a convention of sorts. 255 is 2^8 - 1. So is there something 'magical' about lengths that are 2^n - 1? Or just specifically 255? Is there a performance or storage optimisation advantage to certain specific varchar lengths? Or is this just old wisdom which is no longer applicable to current versions of MariaDB and MySQL?





This question already has an answer here:




  • MySQL - varchar length and performance

    1 answer








mysql mariadb






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 15 at 8:22







dbdemon

















asked Jan 14 at 13:47









dbdemondbdemon

2,9972524




2,9972524




marked as duplicate by Evan Carroll, Colin 't Hart, Michael Green, mustaccio, Vérace Jan 15 at 21:10


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.









marked as duplicate by Evan Carroll, Colin 't Hart, Michael Green, mustaccio, Vérace Jan 15 at 21:10


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.










  • 1





    Do you need 255 characters?

    – McNets
    Jan 14 at 14:04











  • Historical reasons, at least according to stackoverflow.com/questions/1217466/…

    – Jonathan Fite
    Jan 14 at 14:05











  • @McNets I actually need more than 255, but since that number is used so often, I thought I should use that as an example.

    – dbdemon
    Jan 14 at 15:01











  • Simply use the length you need.

    – McNets
    Jan 14 at 15:23











  • @EvanCarroll thanks for pointing out this question. It's useful and similar, though not exactly the same because I'm asking about 'magical' lengths (2^n -1).

    – dbdemon
    Jan 14 at 19:08














  • 1





    Do you need 255 characters?

    – McNets
    Jan 14 at 14:04











  • Historical reasons, at least according to stackoverflow.com/questions/1217466/…

    – Jonathan Fite
    Jan 14 at 14:05











  • @McNets I actually need more than 255, but since that number is used so often, I thought I should use that as an example.

    – dbdemon
    Jan 14 at 15:01











  • Simply use the length you need.

    – McNets
    Jan 14 at 15:23











  • @EvanCarroll thanks for pointing out this question. It's useful and similar, though not exactly the same because I'm asking about 'magical' lengths (2^n -1).

    – dbdemon
    Jan 14 at 19:08








1




1





Do you need 255 characters?

– McNets
Jan 14 at 14:04





Do you need 255 characters?

– McNets
Jan 14 at 14:04













Historical reasons, at least according to stackoverflow.com/questions/1217466/…

– Jonathan Fite
Jan 14 at 14:05





Historical reasons, at least according to stackoverflow.com/questions/1217466/…

– Jonathan Fite
Jan 14 at 14:05













@McNets I actually need more than 255, but since that number is used so often, I thought I should use that as an example.

– dbdemon
Jan 14 at 15:01





@McNets I actually need more than 255, but since that number is used so often, I thought I should use that as an example.

– dbdemon
Jan 14 at 15:01













Simply use the length you need.

– McNets
Jan 14 at 15:23





Simply use the length you need.

– McNets
Jan 14 at 15:23













@EvanCarroll thanks for pointing out this question. It's useful and similar, though not exactly the same because I'm asking about 'magical' lengths (2^n -1).

– dbdemon
Jan 14 at 19:08





@EvanCarroll thanks for pointing out this question. It's useful and similar, though not exactly the same because I'm asking about 'magical' lengths (2^n -1).

– dbdemon
Jan 14 at 19:08










4 Answers
4






active

oldest

votes


















6














I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.



In MySQL, there are reasons to stop at 191, 255, 767, 64K, and probably other values. Some depend on Engine, some on CHARACTER SET, etc.



A VARCHAR is stored as a 1- or 2-byte length plus enough bytes for the current text in whatever charset you have specified. However, the choice of 1 or 2 is not driven only by the individual column; it is driven by the total row size. That is, this is not a valid excuse for using 255.



Use a length that is




  • Big enough to conservatively never be exceeded, yet

  • As small as seems reasonable.


While I am ranting... CHAR (fixed length) is rarely advised. And almost always it should be CHARACTER SET ascii -- country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc. (MD5 and UUID should be taken a step further, but that is another rant.)



Potential negative impacts of blindly using '255':




  • If you have a lot of columns, you could hit a max row size limit and CREATE TABLE will fail.

  • You could overflow a limit on index size.

  • Complex SELECTs may need a temp table, and may use MEMORY for it. In this case, VARCHAR(255) becomes CHAR(255) for the temp table. And, if using utf8, that is 755 bytes for every row! (8.0 fixes this design flaw?)


Related: Don't blindly use BIGINT for all numbers. It takes 8 bytes. Even INT is overkill, at 4 bytes. See MEDIUMINT, SMALLINT, and TINYINT. Be aware that the (2) on INT(2) means nothing; it still takes 4 bytes.






share|improve this answer


























  • MySQL-8.0.13+ uses TempTable by default for temp tables which has efficient storage for varchars.

    – danblack
    Jan 14 at 22:16



















3














At one point in time, that was the max length of a column in Sybase, and the derived SQL Server. I'm sure others copied it to maintain compatibility so that migrating applications / SQL to a new platform wasn't difficult, as everyone was fighting for market share back in the day.



There's no real good reason to perpetuate it, other than compatibility. I've noticed that it seems to have been replaced by varchar(max) these days.






share|improve this answer



















  • 1





    This in interesting precise historical example, which could add some value to this Q&A. Some cited source would make it stronger, though.

    – Pac0
    Jan 14 at 21:07











  • (Oh, and welcome to Database Administrators !)

    – Pac0
    Jan 14 at 21:08











  • @Pac0 Ha, unfortunately much of the reference is found in paper manuals from back then ;)

    – Mike
    Jan 15 at 16:27



















2














"Standard" column lengths are used all over the place, and invariably indicate there was no effort performed to understand the actual required length of the column.



If you have a column where there will never be more than 24 characters used, why specify the length of the column as 255?



Analyzing and using the correct length for variable-length columns takes a small amount of effort, and ensures side effects of using too large a column length never become a problem. I know your question is about MySQL, however this answer shows how SQL Server uses column lengths in various ways that may not be apparent at first.






share|improve this answer































    -1














    We've taken a completely different rule now. We use one of two things:



    `NVARCHAR(max)`


    if it won't be indexed.



    `NVARCHAR(400)`


    if it will be indexed.



    Generally speaking we believe that limits are obsolete and we really shouldn't care anymore. Disk space is cheap. The 400 ensures the index can always be created on the most restrictive target platform. It is my understanding that the 255 index limit on MySQL is gone else I would have written 255. The thing about VARCHAR is you will not be penalized for allowing it to be bigger than it needs to be so there isn't much downside to being too big, so we just set it big and don't think about it anymore.






    share|improve this answer






























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      6














      I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.



      In MySQL, there are reasons to stop at 191, 255, 767, 64K, and probably other values. Some depend on Engine, some on CHARACTER SET, etc.



      A VARCHAR is stored as a 1- or 2-byte length plus enough bytes for the current text in whatever charset you have specified. However, the choice of 1 or 2 is not driven only by the individual column; it is driven by the total row size. That is, this is not a valid excuse for using 255.



      Use a length that is




      • Big enough to conservatively never be exceeded, yet

      • As small as seems reasonable.


      While I am ranting... CHAR (fixed length) is rarely advised. And almost always it should be CHARACTER SET ascii -- country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc. (MD5 and UUID should be taken a step further, but that is another rant.)



      Potential negative impacts of blindly using '255':




      • If you have a lot of columns, you could hit a max row size limit and CREATE TABLE will fail.

      • You could overflow a limit on index size.

      • Complex SELECTs may need a temp table, and may use MEMORY for it. In this case, VARCHAR(255) becomes CHAR(255) for the temp table. And, if using utf8, that is 755 bytes for every row! (8.0 fixes this design flaw?)


      Related: Don't blindly use BIGINT for all numbers. It takes 8 bytes. Even INT is overkill, at 4 bytes. See MEDIUMINT, SMALLINT, and TINYINT. Be aware that the (2) on INT(2) means nothing; it still takes 4 bytes.






      share|improve this answer


























      • MySQL-8.0.13+ uses TempTable by default for temp tables which has efficient storage for varchars.

        – danblack
        Jan 14 at 22:16
















      6














      I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.



      In MySQL, there are reasons to stop at 191, 255, 767, 64K, and probably other values. Some depend on Engine, some on CHARACTER SET, etc.



      A VARCHAR is stored as a 1- or 2-byte length plus enough bytes for the current text in whatever charset you have specified. However, the choice of 1 or 2 is not driven only by the individual column; it is driven by the total row size. That is, this is not a valid excuse for using 255.



      Use a length that is




      • Big enough to conservatively never be exceeded, yet

      • As small as seems reasonable.


      While I am ranting... CHAR (fixed length) is rarely advised. And almost always it should be CHARACTER SET ascii -- country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc. (MD5 and UUID should be taken a step further, but that is another rant.)



      Potential negative impacts of blindly using '255':




      • If you have a lot of columns, you could hit a max row size limit and CREATE TABLE will fail.

      • You could overflow a limit on index size.

      • Complex SELECTs may need a temp table, and may use MEMORY for it. In this case, VARCHAR(255) becomes CHAR(255) for the temp table. And, if using utf8, that is 755 bytes for every row! (8.0 fixes this design flaw?)


      Related: Don't blindly use BIGINT for all numbers. It takes 8 bytes. Even INT is overkill, at 4 bytes. See MEDIUMINT, SMALLINT, and TINYINT. Be aware that the (2) on INT(2) means nothing; it still takes 4 bytes.






      share|improve this answer


























      • MySQL-8.0.13+ uses TempTable by default for temp tables which has efficient storage for varchars.

        – danblack
        Jan 14 at 22:16














      6












      6








      6







      I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.



      In MySQL, there are reasons to stop at 191, 255, 767, 64K, and probably other values. Some depend on Engine, some on CHARACTER SET, etc.



      A VARCHAR is stored as a 1- or 2-byte length plus enough bytes for the current text in whatever charset you have specified. However, the choice of 1 or 2 is not driven only by the individual column; it is driven by the total row size. That is, this is not a valid excuse for using 255.



      Use a length that is




      • Big enough to conservatively never be exceeded, yet

      • As small as seems reasonable.


      While I am ranting... CHAR (fixed length) is rarely advised. And almost always it should be CHARACTER SET ascii -- country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc. (MD5 and UUID should be taken a step further, but that is another rant.)



      Potential negative impacts of blindly using '255':




      • If you have a lot of columns, you could hit a max row size limit and CREATE TABLE will fail.

      • You could overflow a limit on index size.

      • Complex SELECTs may need a temp table, and may use MEMORY for it. In this case, VARCHAR(255) becomes CHAR(255) for the temp table. And, if using utf8, that is 755 bytes for every row! (8.0 fixes this design flaw?)


      Related: Don't blindly use BIGINT for all numbers. It takes 8 bytes. Even INT is overkill, at 4 bytes. See MEDIUMINT, SMALLINT, and TINYINT. Be aware that the (2) on INT(2) means nothing; it still takes 4 bytes.






      share|improve this answer















      I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.



      In MySQL, there are reasons to stop at 191, 255, 767, 64K, and probably other values. Some depend on Engine, some on CHARACTER SET, etc.



      A VARCHAR is stored as a 1- or 2-byte length plus enough bytes for the current text in whatever charset you have specified. However, the choice of 1 or 2 is not driven only by the individual column; it is driven by the total row size. That is, this is not a valid excuse for using 255.



      Use a length that is




      • Big enough to conservatively never be exceeded, yet

      • As small as seems reasonable.


      While I am ranting... CHAR (fixed length) is rarely advised. And almost always it should be CHARACTER SET ascii -- country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc. (MD5 and UUID should be taken a step further, but that is another rant.)



      Potential negative impacts of blindly using '255':




      • If you have a lot of columns, you could hit a max row size limit and CREATE TABLE will fail.

      • You could overflow a limit on index size.

      • Complex SELECTs may need a temp table, and may use MEMORY for it. In this case, VARCHAR(255) becomes CHAR(255) for the temp table. And, if using utf8, that is 755 bytes for every row! (8.0 fixes this design flaw?)


      Related: Don't blindly use BIGINT for all numbers. It takes 8 bytes. Even INT is overkill, at 4 bytes. See MEDIUMINT, SMALLINT, and TINYINT. Be aware that the (2) on INT(2) means nothing; it still takes 4 bytes.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Jan 14 at 17:17

























      answered Jan 14 at 17:09









      Rick JamesRick James

      42.2k22258




      42.2k22258













      • MySQL-8.0.13+ uses TempTable by default for temp tables which has efficient storage for varchars.

        – danblack
        Jan 14 at 22:16



















      • MySQL-8.0.13+ uses TempTable by default for temp tables which has efficient storage for varchars.

        – danblack
        Jan 14 at 22:16

















      MySQL-8.0.13+ uses TempTable by default for temp tables which has efficient storage for varchars.

      – danblack
      Jan 14 at 22:16





      MySQL-8.0.13+ uses TempTable by default for temp tables which has efficient storage for varchars.

      – danblack
      Jan 14 at 22:16













      3














      At one point in time, that was the max length of a column in Sybase, and the derived SQL Server. I'm sure others copied it to maintain compatibility so that migrating applications / SQL to a new platform wasn't difficult, as everyone was fighting for market share back in the day.



      There's no real good reason to perpetuate it, other than compatibility. I've noticed that it seems to have been replaced by varchar(max) these days.






      share|improve this answer



















      • 1





        This in interesting precise historical example, which could add some value to this Q&A. Some cited source would make it stronger, though.

        – Pac0
        Jan 14 at 21:07











      • (Oh, and welcome to Database Administrators !)

        – Pac0
        Jan 14 at 21:08











      • @Pac0 Ha, unfortunately much of the reference is found in paper manuals from back then ;)

        – Mike
        Jan 15 at 16:27
















      3














      At one point in time, that was the max length of a column in Sybase, and the derived SQL Server. I'm sure others copied it to maintain compatibility so that migrating applications / SQL to a new platform wasn't difficult, as everyone was fighting for market share back in the day.



      There's no real good reason to perpetuate it, other than compatibility. I've noticed that it seems to have been replaced by varchar(max) these days.






      share|improve this answer



















      • 1





        This in interesting precise historical example, which could add some value to this Q&A. Some cited source would make it stronger, though.

        – Pac0
        Jan 14 at 21:07











      • (Oh, and welcome to Database Administrators !)

        – Pac0
        Jan 14 at 21:08











      • @Pac0 Ha, unfortunately much of the reference is found in paper manuals from back then ;)

        – Mike
        Jan 15 at 16:27














      3












      3








      3







      At one point in time, that was the max length of a column in Sybase, and the derived SQL Server. I'm sure others copied it to maintain compatibility so that migrating applications / SQL to a new platform wasn't difficult, as everyone was fighting for market share back in the day.



      There's no real good reason to perpetuate it, other than compatibility. I've noticed that it seems to have been replaced by varchar(max) these days.






      share|improve this answer













      At one point in time, that was the max length of a column in Sybase, and the derived SQL Server. I'm sure others copied it to maintain compatibility so that migrating applications / SQL to a new platform wasn't difficult, as everyone was fighting for market share back in the day.



      There's no real good reason to perpetuate it, other than compatibility. I've noticed that it seems to have been replaced by varchar(max) these days.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Jan 14 at 20:04









      MikeMike

      1311




      1311








      • 1





        This in interesting precise historical example, which could add some value to this Q&A. Some cited source would make it stronger, though.

        – Pac0
        Jan 14 at 21:07











      • (Oh, and welcome to Database Administrators !)

        – Pac0
        Jan 14 at 21:08











      • @Pac0 Ha, unfortunately much of the reference is found in paper manuals from back then ;)

        – Mike
        Jan 15 at 16:27














      • 1





        This in interesting precise historical example, which could add some value to this Q&A. Some cited source would make it stronger, though.

        – Pac0
        Jan 14 at 21:07











      • (Oh, and welcome to Database Administrators !)

        – Pac0
        Jan 14 at 21:08











      • @Pac0 Ha, unfortunately much of the reference is found in paper manuals from back then ;)

        – Mike
        Jan 15 at 16:27








      1




      1





      This in interesting precise historical example, which could add some value to this Q&A. Some cited source would make it stronger, though.

      – Pac0
      Jan 14 at 21:07





      This in interesting precise historical example, which could add some value to this Q&A. Some cited source would make it stronger, though.

      – Pac0
      Jan 14 at 21:07













      (Oh, and welcome to Database Administrators !)

      – Pac0
      Jan 14 at 21:08





      (Oh, and welcome to Database Administrators !)

      – Pac0
      Jan 14 at 21:08













      @Pac0 Ha, unfortunately much of the reference is found in paper manuals from back then ;)

      – Mike
      Jan 15 at 16:27





      @Pac0 Ha, unfortunately much of the reference is found in paper manuals from back then ;)

      – Mike
      Jan 15 at 16:27











      2














      "Standard" column lengths are used all over the place, and invariably indicate there was no effort performed to understand the actual required length of the column.



      If you have a column where there will never be more than 24 characters used, why specify the length of the column as 255?



      Analyzing and using the correct length for variable-length columns takes a small amount of effort, and ensures side effects of using too large a column length never become a problem. I know your question is about MySQL, however this answer shows how SQL Server uses column lengths in various ways that may not be apparent at first.






      share|improve this answer




























        2














        "Standard" column lengths are used all over the place, and invariably indicate there was no effort performed to understand the actual required length of the column.



        If you have a column where there will never be more than 24 characters used, why specify the length of the column as 255?



        Analyzing and using the correct length for variable-length columns takes a small amount of effort, and ensures side effects of using too large a column length never become a problem. I know your question is about MySQL, however this answer shows how SQL Server uses column lengths in various ways that may not be apparent at first.






        share|improve this answer


























          2












          2








          2







          "Standard" column lengths are used all over the place, and invariably indicate there was no effort performed to understand the actual required length of the column.



          If you have a column where there will never be more than 24 characters used, why specify the length of the column as 255?



          Analyzing and using the correct length for variable-length columns takes a small amount of effort, and ensures side effects of using too large a column length never become a problem. I know your question is about MySQL, however this answer shows how SQL Server uses column lengths in various ways that may not be apparent at first.






          share|improve this answer













          "Standard" column lengths are used all over the place, and invariably indicate there was no effort performed to understand the actual required length of the column.



          If you have a column where there will never be more than 24 characters used, why specify the length of the column as 255?



          Analyzing and using the correct length for variable-length columns takes a small amount of effort, and ensures side effects of using too large a column length never become a problem. I know your question is about MySQL, however this answer shows how SQL Server uses column lengths in various ways that may not be apparent at first.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 14 at 17:09









          Max VernonMax Vernon

          50.6k13112223




          50.6k13112223























              -1














              We've taken a completely different rule now. We use one of two things:



              `NVARCHAR(max)`


              if it won't be indexed.



              `NVARCHAR(400)`


              if it will be indexed.



              Generally speaking we believe that limits are obsolete and we really shouldn't care anymore. Disk space is cheap. The 400 ensures the index can always be created on the most restrictive target platform. It is my understanding that the 255 index limit on MySQL is gone else I would have written 255. The thing about VARCHAR is you will not be penalized for allowing it to be bigger than it needs to be so there isn't much downside to being too big, so we just set it big and don't think about it anymore.






              share|improve this answer




























                -1














                We've taken a completely different rule now. We use one of two things:



                `NVARCHAR(max)`


                if it won't be indexed.



                `NVARCHAR(400)`


                if it will be indexed.



                Generally speaking we believe that limits are obsolete and we really shouldn't care anymore. Disk space is cheap. The 400 ensures the index can always be created on the most restrictive target platform. It is my understanding that the 255 index limit on MySQL is gone else I would have written 255. The thing about VARCHAR is you will not be penalized for allowing it to be bigger than it needs to be so there isn't much downside to being too big, so we just set it big and don't think about it anymore.






                share|improve this answer


























                  -1












                  -1








                  -1







                  We've taken a completely different rule now. We use one of two things:



                  `NVARCHAR(max)`


                  if it won't be indexed.



                  `NVARCHAR(400)`


                  if it will be indexed.



                  Generally speaking we believe that limits are obsolete and we really shouldn't care anymore. Disk space is cheap. The 400 ensures the index can always be created on the most restrictive target platform. It is my understanding that the 255 index limit on MySQL is gone else I would have written 255. The thing about VARCHAR is you will not be penalized for allowing it to be bigger than it needs to be so there isn't much downside to being too big, so we just set it big and don't think about it anymore.






                  share|improve this answer













                  We've taken a completely different rule now. We use one of two things:



                  `NVARCHAR(max)`


                  if it won't be indexed.



                  `NVARCHAR(400)`


                  if it will be indexed.



                  Generally speaking we believe that limits are obsolete and we really shouldn't care anymore. Disk space is cheap. The 400 ensures the index can always be created on the most restrictive target platform. It is my understanding that the 255 index limit on MySQL is gone else I would have written 255. The thing about VARCHAR is you will not be penalized for allowing it to be bigger than it needs to be so there isn't much downside to being too big, so we just set it big and don't think about it anymore.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 14 at 22:57









                  JoshuaJoshua

                  1336




                  1336















                      Popular posts from this blog

                      Human spaceflight

                      Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

                      張江高科駅