Как БОЛЬШОЙ ты делаешь свой Nvarchar ()

Question

При проектировании базы данных, какие решения вы принимаете во внимание при определении размера вашего nvarchar.

Если бы я должен был создать таблицу адресов, моя быстрая реакция была бы для адресной строки 1 быть nvarchar (255), как старая база данных доступа.

Я обнаружил, что использование этого заставило меня заморачиваться со старым «Строка будет обрезана». Я знаю, что этого можно избежать, ограничив поле ввода, но если у пользователя действительно есть строка адреса, длина которой превышает 255. Это должно быть разрешено.

Насколько большой я должен сделать мой nvarchar (????)

Answer 1

Моя рекомендация: сделайте их такими же большими, какими они действительно вам нужны.

например. для столбца почтового индекса вполне достаточно 10-20 символов. То же самое для номера телефона. Электронная почта может быть длиннее, 50-100 символов. Имена - ну, обычно я получаю 50 символов, то же самое для имен. Вы всегда можете легко и просто расширить поля, если вам это действительно нужно - это совсем не большое дело.

Нет смысла делать все поля varchar / nvarchar настолько большими, насколько они могут быть. В конце концов, страница SQL Server является фиксированной и ограничена 8060 байтами на строку. Наличие 10 полей NVARCHAR (4000) просто вызывает проблемы .... (так как если вы на самом деле попытаетесь заполнить их слишком большим количеством данных, SQL Server будет против вас).

Если вам ДЕЙСТВИТЕЛЬНО нужно действительно большое поле, используйте NVARCHAR / VARCHAR (MAX) - они хранятся на вашей странице, пока они подходят, и будут отправлены в «переполненное» хранилище, если они станут слишком большими.

NVARCHAR против VARCHAR: это действительно сводится к тому, что вам действительно нужны «экзотические» символы, такие как японские, китайские или другие символы не в стиле ASCII? В Европе даже некоторые восточноевропейские символы больше не могут быть представлены полями VARCHAR (они будут лишены своего хачека («правописание»). Западноевропейские языки (английский, немецкий, французский и т. Д.) Все очень хорошо обслуживаются VARCHAR.

НО: NVARCHAR использует вдвое больше места - на диске и в памяти вашего SQL Server - всегда. Если вам это действительно нужно, вам это нужно - но действительно ли вы ДЕЙСТВИТЕЛЬНО ? :-) Это зависит от вас.

Марк

Answer 2

Я не использую nvarchar лично :-) Я всегда использую varchar.

Однако я склонен использовать 100 для имени и 1000 для комментариев. Перехват и обработка длинных строк - это то, что клиент может сделать, скажем, с помощью регулярных выражений, поэтому SQL получает только те данные, которые он ожидает.

Вы можете избежать ошибок усечения при параметризации вызовов, например, с помощью сохраненных процедур. Если параметр определен как varchar (200), скажем, тогда усечение происходит без вывода сообщений, если вы отправляете> 200. Ошибка усечения генерируется только для оператора INSERT или UPDATE: с параметрами это не произойдет.

255 «предел» для SQL Server восходит к 6,5, потому что vachar был ограничен до 255. SQL Server 7.0 + изменен на 8000 и добавлена ​​поддержка юникода

Edit:

Почему я не использую nvarchar: двойной объем памяти, двойной размер индекса, двойной размер диска, просто не нужен. Я работаю в крупной швейцарской компании с офисами по всему миру, поэтому я не прихожанин.

Также обсуждается здесь: производительность varchar против nvarchar

Что касается дальнейшего размышления, я бы предложил юникод-апелляции для клиентов-разработчиков, но, как администратор БД, я сосредоточен на производительности и эффективности ...

Answer 3

Для столбцов, для которых вам необходимо иметь определенные ограничения - например, имена, электронные письма, адреса и т. Д. - вы должны установить достаточно высокую максимальную длину. Например, имя из более чем 50 символов кажется немного подозрительным, и ввод выше этого размера, вероятно, будет содержать больше, чем просто имя. Но для первоначального проектирования базы данных возьмите этот разумный размер и удвойте его . Так что для имен, установите его на 100 (или 200, если 100 - ваш «разумный размер»). Затем запустите приложение в производство, дайте пользователям поиграть достаточно долго для сбора данных, а затем проверьте фактический max(len(FirstName)). Есть ли там какие-то подозрительные ценности? Что-нибудь выше 50 символов? Узнайте, что там, и посмотрите, действительно ли это имя или нет. Если это не так, форма ввода, вероятно, нуждается в лучших объяснениях / проверках.

Сделайте то же самое для комментариев; Установите их на nvharchar(max) изначально. Затем вернитесь , когда ваша база данных вырастет настолько, что вы начнете оптимизировать производительность . Возьмите максимальную длину комментариев, удвойте ее, и у вас будет хорошая максимальная длина для вашего столбца.

Answer 4

Это зависит от того, что представляет поле. Если я делаю быстрый прототип, я оставляю значения по умолчанию 255. Для чего-то вроде комментариев и т. Д. Я бы, вероятно, поставил его на 1000.

Единственный способ сделать его на самом деле меньше - это вещи, о которых я точно знаю, почтовые индексы или номера NI и т. Д.