Para divertirte aún más, prueba este:
DECLARE @i INT
SET @i = 100
SELECT CAST(@i AS VARCHAR(2)) -- result: '*'
go
DECLARE @i INT
SET @i = 100
SELECT CAST(@i AS NVARCHAR(2)) -- result: Arithmetic overflow error
:)
La respuesta a su consulta es:"Razones históricas"
Los tipos de datos INT y VARCHAR son más antiguos que BIGINT y NVARCHAR. Mucho más viejo. De hecho, están en el original especificaciones SQL. También es más antiguo el enfoque de supresión de excepciones de reemplazar la salida con asteriscos.
Más tarde, la gente de SQL decidió que arrojar un error era mejor/más consistente, etc. que sustituir cadenas de salida falsas (y generalmente confusas). Sin embargo, en aras de la coherencia, conservaron el comportamiento anterior para las combinaciones preexistentes de tipos de datos (para no romper el código existente).
Así que (mucho) más tarde, cuando se agregaron los tipos de datos BIGINT y NVARCHAR, obtuvieron el comportamiento más nuevo porque no estaban cubiertos por la protección mencionada anteriormente.
