С точки зрения сервера:
- Я бы ожидал, что поле
Guid будет храниться более эффективно - ему нужно всего 8 байтов вместо 32 или, возможно, 64+, в зависимости от того, как именно хранится nvarchar
- Он может быть обработан сервером как непрозрачные двоичные данные - например, no требуется для проведения сравнений. Нет культурной или чувствительности к регистру. Это в основном , а не текстовые данные, поэтому не имеет всех проблем и сложностей, связанных с текстом.
- Сервер может принять решение использовать известную структуру Guid для более эффективного индексирования. Например, если некоторые биты распределены случайным образом чаще, чем другие, их можно использовать для индексации.
С точки зрения программиста:
- Более четкое утверждение об ожидаемых данных.
- Вам не нужна проверка, и у вас никогда не возникнет проблем с неверными данными - это просто GUID.
Я большой поклонник хранения данных в любой форме, наиболее близкой к логическому значению данных. Например, если вы собираетесь хранить данные даты и времени, это сделает жизнь намного проще для сравнений и т. Д., Если у вас есть значение даты / времени, а не строка. Преобразование в строку и из строки (или любое другое представление, но обычно это строка) должно выполняться только там, где обязательно .