SQL Server, по-видимому, неправильно вычисляет длину ключа

При попытке создать базу данных, запускающую скрипт, сгенерированный Visual Studio (Entity Framework, «Generate Database From Model ...»), я столкнулся с ошибкой с Primary Ключ.SQL Server, по-видимому, неправильно вычисляет длину ключа

Команда дает мне вопрос является

ALTER TABLE tablename 
ADD CONSTRAINT constraintname 
    PRIMARY KEY NONCLUSTERED (col1, col2 ASC);

Ошибка я получаю

Index constraintname не был создан. Индекс имеет длину ключа 1024 байта. Максимальная допустимая длина ключа - 900 байт.

Таблица создается с

CREATE TABLE tablename (
    col1 nchar(256) NOT NULL, 
    col2 nchar(256) NOT NULL 
);

, который смотрит на меня, чтобы быть 512 байт, а не 1024.

Что вызывает SQL Server, чтобы считать это 1024, и как я могу это исправить проблема?

источник

2013-07-10 yoozer8

Ваши столбцы содержат до 512 ** символов ** - не байт. В зависимости от набора символов, который может дать 1500 байт (например, с UTF-8). –

'nchar (256)' довольно необычно в любом случае. Все ли значения фиксированной ширины 256 символов или максимальная длина? –

@MartinSmith Это фиксированная длина. Каждый из них служит идентификатором других таблиц. Я не тот, кто принял решение о нчаре (256); он, по-видимому, уже используется (хотя я не вижу, как это будет работать). – yoozer8

nchar - unicode, который занимает два байта на символ.

Если вам не нужен юникод, переключитесь на char. Или сократите свои столбцы или добавьте отдельные столбцы для использования в качестве ключа. Две 512 символьные строки - довольно большой первичный ключ!

источник

2013-07-10 20:15:50 Blorgbeard

Отсутствует самый важный совет: Перейдите на n * var * char! Таким образом, вы не тратите 90% пространства и не устраняете ошибку. – usr

Switch to nvarchar. nchar - тип данных фиксированного пространства. Вероятно, вы потратите 90% своего пространства на хранение. Если вы хотите сохранить строку из 10 символов, вам понадобится место для 256, что является ненужной тратой.

Рассмотрите возможность перехода к varchar в космос еще на 50%. Но вы потеряете Unicode именно так.

Далее для вас: прочитайте документацию, чтобы ознакомиться с типами данных. Есть сложные ошибки.

источник

2013-07-10 20:38:40 usr

Следует отметить, что если в своих PK-файлах на каких-либо строках действительно содержится более 1024 байтов данных, это все равно не удастся. – Blorgbeard

Вы прочитали комментарии? Говорят, что это фиксированная ширина (хотя я не могу представить, какую схему сумасбродства они должны использовать для создания идентификаторов). –

Я думаю, он говорит, что они уже (ошибочно) используют типы фиксированной ширины в другом месте. Это не значит, что он должен это делать и здесь. Возможно, ОП может уточнить. – usr

CREATE TABLE tablename (
    col1 nvarchar(256) NOT NULL, 
    col2 nvarchar(256) NOT NULL 
);

EDIT (запрос Sasha.Sochka в):

NCHAR использует фиксированный размер п символов, даже если значение может поместиться в меньшем пространстве. nvarchar использует пространство для как можно большего количества символов, в то время как его верхняя граница - это пространство для 256 символов в нашем случае. Итак, если у вас есть это «foo», тогда он выделит место для 256 символов, если это nchar, и он выделит пространство для 3 символов, если это nvarchar.

источник

2013-07-10 21:50:20

SQL Server, по-видимому, неправильно вычисляет длину ключа

ответ

Смежные вопросы