Использование varchar (max)

Возможный дубликат:
Есть ли недостатки постоянного использования nvarchar (MAX)?
varchar (max) везде?

Учитывая тот факт, что varchar всегда будет хранить фактическое количество символов, которые у него есть, а не его размер (например, столбец varchar (10), содержащий «Hello», будет занимать только 5 байтов), почему бы не создать все столбцы VARCHAR как varchar (max )?

Хорошо, есть проблема с индексом, когда могут быть проиндексированы только столбцы с максимальным размером 900 байт, так почему бы не создать все столбцы как varchar (900) или все столбцы, которые не должны быть проиндексированы как varchar (max) и другие как varchar (макс.)


database sql-server sqldatatypes
person Diego    schedule 02.03.2012    source источник
comment
вы имеете в виду, также нестроковые столбцы? так, например, чтобы суммировать целочисленные столбцы, вы должны их преобразовать? Неа.   -  person vulkanino    schedule 02.03.2012
comment
нет нет .. все строковые столбцы, те, которые я обычно создаю как varchar (50) или varchar (100)   -  person Diego    schedule 02.03.2012
comment
varchar для начала имеет накладные расходы char. если у вас есть столбец почтового индекса, который, как вы знаете, всегда будет хранить 5 символов, тогда зачем объявлять его varchar(900)? без разницы. кроме того, размер столбца является источником информации как для читателей, так и для БД.   -  person vulkanino    schedule 02.03.2012
comment
stackoverflow.com/questions/2091284/varcharmax-everywhere   -  person Mikael Eriksson    schedule 02.03.2012
comment
stackoverflow.com/questions/858245 /   -  person Mikael Eriksson    schedule 02.03.2012
comment
stackoverflow .com / questions / 2572649 /.   -  person Mikael Eriksson    schedule 02.03.2012
comment
Я никогда не упоминал ЧАР @vulkanino   -  person Diego    schedule 02.03.2012

Ответы (1)


arrow_upward
0
arrow_downward

Я не знаю всех деталей, но это связано с тем, как распределяется дисковое пространство. Это ссылка с некоторыми подробностями.

http://msdn.microsoft.com/en-us/library/ms190969.aspx

person cadrell0    schedule 02.03.2012