CAMBIAR DISEÑO TABLA : CAMPOS NVARCHAR(MAX) ---> VARCHAR(MAX)

Correcto, el campo nvarchar sirve para guardar datos unicode, como puede ser
los caracteres chinos.

El nvarchar ocupa el doble que un varchar...SQL Server usa 2 bytes por
caracter para almacenar caracteres unicode.

Si ya tienes una base de datos en producción, antes de hacer ningún cambio
me plantearía si realmente es necesario. ¿ Tienes algún problema de
espacio?¿ Tienes algún problema de rendimiento en las querys?¿ Seguro que no
vas a querer nunca soportar caracteres unicode?¿Puedes tener algún problema
de compatibilidad con aplicaciones que usen esa base de datos?

Si algo ya lo tienes en producción hay que ser más precavido con los
cambios

No debería haber problemas en cambiarlo, aunque como yo siempre soy
precabido y haría los cambios en preproducción o en una máquina de pruebas,
con el objetivo de asegurar que todo se ha hecho ok.

"Elena" <""elena.pocket.\"@"> escribió en el mensaje de
noticias:

Hola a todos!!

Tengo una base donde al diseñarle definí todos los campos de caracteres
como NVARCHAR(MAX).

Ahora me he enterado que ese tipo de datos es para idiomas que necesitan
mas caracteres de los normales (hebreo, japones, arabe, etc...) y como mis
datos son completamente "castellanos" he decidido cambiar el tipo de datos
de NVARCHAR a VARHCAR.
i

MI gran duda es -> puedo perder datos siendo todos los caracteres
castellanos? o no hay ningún problema?

He hecho pruebas a pequeña escala y parece que funciona bien, pero mi base
de datos es bastante grande, como 200.000 registros y me da miedo
arriesgarme a perder datos...


Muchas gracias y un saludo.

Elena

Completamente de acuerdo con todo lo que has dicho

pero tengo los siguientes problemas con la base de datos, debido a que mis clientes actualizan datos cada media hora, la tabla de transacciones se satura.

Ya hemoms alcanzado el límite máximo que nos proporciona nuestro proveedor de servicios de internet (vamos el propietario del SQL Server) y necesito
reducir el tamaño de los datos que se van almacenando en la tabla de transacciones, asi como el tamaño de los datos (aunque este es un problema menor)

Mi proveedor hace un truncamiento del registro de transaciones cada 6 horas, pero no ha sido siempre suficiente, por lo que ha quedado la base de
datos inoperativo durante un par de horas, no me gustaría que se repitiera.

ademas, el tema de hacer un backup no me lo puedo plantear al no tener otra base de datos de ese tamaño disponible. Intente configurar VS2005 para
trabajar con SQLServer Expres en el equipo local y nunca lo consegui!! :(

He realizado pruebas en una pequeña base de datos que tenemos para probar cosas nuevas y no ha dado ningún problema, por lo demás no tengo problemas
de rendimiento de querys, aunque si la base de datos sigue creciendo al ritmo actual puede que los tenga, y seguró que nunca tendré que utilizar
caracteres unicode, todos los clientes se limitan al territorio español, las compatibilidades con otros programas tampoco son ningún problema, ya que
soy yo quien diseña los programas que interactuan con la base de datos.

Me gustaría conseguir controlar el tamaño de la tabla de referencias a traves de VB.NET pero de momento tampoco he conseguido obtener el tamaño o
percentaje de uso, a través de código para controlar la actualización de mis clientes.

Estoy abierta a sugerencias!!

Un saludo.



Ibon Landa escribió:

Correcto, el campo nvarchar sirve para guardar datos unicode, como puede
ser los caracteres chinos.

El nvarchar ocupa el doble que un varchar...SQL Server usa 2 bytes por
caracter para almacenar caracteres unicode.

Si ya tienes una base de datos en producción, antes de hacer ningún
cambio me plantearía si realmente es necesario. ¿ Tienes algún problema
de espacio?¿ Tienes algún problema de rendimiento en las querys?¿ Seguro
que no vas a querer nunca soportar caracteres unicode?¿Puedes tener
algún problema de compatibilidad con aplicaciones que usen esa base de
datos?

Si algo ya lo tienes en producción hay que ser más precavido con los
cambios

No debería haber problemas en cambiarlo, aunque como yo siempre soy
precabido y haría los cambios en preproducción o en una máquina de
pruebas, con el objetivo de asegurar que todo se ha hecho ok.

"Elena" <""elena.pocket.\"@"> escribió en el mensaje de
noticias:

Hola a todos!!

Tengo una base donde al diseñarle definí todos los campos de
caracteres como NVARCHAR(MAX).

Ahora me he enterado que ese tipo de datos es para idiomas que
necesitan mas caracteres de los normales (hebreo, japones, arabe,
etc...) y como mis datos son completamente "castellanos" he decidido
cambiar el tipo de datos de NVARCHAR a VARHCAR.
i

MI gran duda es -> puedo perder datos siendo todos los caracteres
castellanos? o no hay ningún problema?

He hecho pruebas a pequeña escala y parece que funciona bien, pero mi
base de datos es bastante grande, como 200.000 registros y me da miedo
arriesgarme a perder datos...


Muchas gracias y un saludo.

Elena

Pero no puedes hacer un backup de la base de datos que tienes en producción,
en el proveedor de servicios? Yo me refería a coger una copia, ponértela en
un servidor de pruebas tuyo y comprobar que el cambio de nvarchar a varchar
se hace correctamente. Ese cambio no tendría que dar problemas, pero yo me
aseguraría de que si hay un problema puedes recuperar la información

A ver si te puede ayudar alguno de estos enlaces..
http://technet.microsoft.com/es-es/...75495.aspx
http://www.helpdna.net/sqlserver_fa...ciones.htm

Lo que veo es que cambiar ese valor puede reducir algo pero igual solo
pospone un poco el problema de espacio...Al final hay muchos factores que
pueden provocar problemas de espacio.

"Elena" <""elena.pocket.\"@"> escribió en el mensaje de
noticias:

Completamente de acuerdo con todo lo que has dicho

pero tengo los siguientes problemas con la base de datos, debido a que mis
clientes actualizan datos cada media hora, la tabla de transacciones se
satura.

Ya hemoms alcanzado el límite máximo que nos proporciona nuestro proveedor
de servicios de internet (vamos el propietario del SQL Server) y necesito
reducir el tamaño de los datos que se van almacenando en la tabla de
transacciones, asi como el tamaño de los datos (aunque este es un problema
menor)

Mi proveedor hace un truncamiento del registro de transaciones cada 6
horas, pero no ha sido siempre suficiente, por lo que ha quedado la base
de datos inoperativo durante un par de horas, no me gustaría que se
repitiera.

ademas, el tema de hacer un backup no me lo puedo plantear al no tener
otra base de datos de ese tamaño disponible. Intente configurar VS2005
para trabajar con SQLServer Expres en el equipo local y nunca lo
consegui!! :(

He realizado pruebas en una pequeña base de datos que tenemos para probar
cosas nuevas y no ha dado ningún problema, por lo demás no tengo problemas
de rendimiento de querys, aunque si la base de datos sigue creciendo al
ritmo actual puede que los tenga, y seguró que nunca tendré que utilizar
caracteres unicode, todos los clientes se limitan al territorio español,
las compatibilidades con otros programas tampoco son ningún problema, ya
que soy yo quien diseña los programas que interactuan con la base de
datos.

Me gustaría conseguir controlar el tamaño de la tabla de referencias a
traves de VB.NET pero de momento tampoco he conseguido obtener el tamaño o
percentaje de uso, a través de código para controlar la actualización de
mis clientes.

Estoy abierta a sugerencias!!

Un saludo.



Ibon Landa escribió:

Correcto, el campo nvarchar sirve para guardar datos unicode, como puede
ser los caracteres chinos.

El nvarchar ocupa el doble que un varchar...SQL Server usa 2 bytes por
caracter para almacenar caracteres unicode.

Si ya tienes una base de datos en producción, antes de hacer ningún
cambio me plantearía si realmente es necesario. ¿ Tienes algún problema
de espacio?¿ Tienes algún problema de rendimiento en las querys?¿ Seguro
que no vas a querer nunca soportar caracteres unicode?¿Puedes tener algún
problema de compatibilidad con aplicaciones que usen esa base de datos?

Si algo ya lo tienes en producción hay que ser más precavido con los
cambios

No debería haber problemas en cambiarlo, aunque como yo siempre soy
precabido y haría los cambios en preproducción o en una máquina de
pruebas, con el objetivo de asegurar que todo se ha hecho ok.

"Elena" <""elena.pocket.\"@"> escribió en el mensaje de
noticias:

Hola a todos!!

Tengo una base donde al diseñarle definí todos los campos de caracteres
como NVARCHAR(MAX).

Ahora me he enterado que ese tipo de datos es para idiomas que necesitan
mas caracteres de los normales (hebreo, japones, arabe, etc...) y como
mis datos son completamente "castellanos" he decidido cambiar el tipo de
datos de NVARCHAR a VARHCAR.
i

MI gran duda es -> puedo perder datos siendo todos los caracteres
castellanos? o no hay ningún problema?

He hecho pruebas a pequeña escala y parece que funciona bien, pero mi
base de datos es bastante grande, como 200.000 registros y me da miedo
arriesgarme a perder datos...


Muchas gracias y un saludo.

Elena

Muchas gracias por la información, hablaré con mi proveedor del servicio ahora que se mas o menos lo que le tengo que preguntar.

Muchas gracias de nuevo por la ayuda.

Saludos...

Ibon Landa escribió:

Pero no puedes hacer un backup de la base de datos que tienes en
producción, en el proveedor de servicios? Yo me refería a coger una
copia, ponértela en un servidor de pruebas tuyo y comprobar que el
cambio de nvarchar a varchar se hace correctamente. Ese cambio no
tendría que dar problemas, pero yo me aseguraría de que si hay un
problema puedes recuperar la información

A ver si te puede ayudar alguno de estos enlaces..
http://technet.microsoft.com/es-es/...75495.aspx
http://www.helpdna.net/sqlserver_fa...ciones.htm

Lo que veo es que cambiar ese valor puede reducir algo pero igual solo
pospone un poco el problema de espacio...Al final hay muchos factores
que pueden provocar problemas de espacio.

"Elena" <""elena.pocket.\"@"> escribió en el mensaje de
noticias:

Completamente de acuerdo con todo lo que has dicho

pero tengo los siguientes problemas con la base de datos, debido a que
mis clientes actualizan datos cada media hora, la tabla de
transacciones se satura.

Ya hemoms alcanzado el límite máximo que nos proporciona nuestro
proveedor de servicios de internet (vamos el propietario del SQL
Server) y necesito reducir el tamaño de los datos que se van
almacenando en la tabla de transacciones, asi como el tamaño de los
datos (aunque este es un problema menor)

Mi proveedor hace un truncamiento del registro de transaciones cada 6
horas, pero no ha sido siempre suficiente, por lo que ha quedado la
base de datos inoperativo durante un par de horas, no me gustaría que
se repitiera.

ademas, el tema de hacer un backup no me lo puedo plantear al no tener
otra base de datos de ese tamaño disponible. Intente configurar VS2005
para trabajar con SQLServer Expres en el equipo local y nunca lo
consegui!! :(

He realizado pruebas en una pequeña base de datos que tenemos para
probar cosas nuevas y no ha dado ningún problema, por lo demás no
tengo problemas de rendimiento de querys, aunque si la base de datos
sigue creciendo al ritmo actual puede que los tenga, y seguró que
nunca tendré que utilizar caracteres unicode, todos los clientes se
limitan al territorio español, las compatibilidades con otros
programas tampoco son ningún problema, ya que soy yo quien diseña los
programas que interactuan con la base de datos.

Me gustaría conseguir controlar el tamaño de la tabla de referencias a
traves de VB.NET pero de momento tampoco he conseguido obtener el
tamaño o percentaje de uso, a través de código para controlar la
actualización de mis clientes.

Estoy abierta a sugerencias!!

Un saludo.



Ibon Landa escribió:

Correcto, el campo nvarchar sirve para guardar datos unicode, como
puede ser los caracteres chinos.

El nvarchar ocupa el doble que un varchar...SQL Server usa 2 bytes
por caracter para almacenar caracteres unicode.

Si ya tienes una base de datos en producción, antes de hacer ningún
cambio me plantearía si realmente es necesario. ¿ Tienes algún
problema de espacio?¿ Tienes algún problema de rendimiento en las
querys?¿ Seguro que no vas a querer nunca soportar caracteres
unicode?¿Puedes tener algún problema de compatibilidad con
aplicaciones que usen esa base de datos?

Si algo ya lo tienes en producción hay que ser más precavido con
los cambios

No debería haber problemas en cambiarlo, aunque como yo siempre soy
precabido y haría los cambios en preproducción o en una máquina de
pruebas, con el objetivo de asegurar que todo se ha hecho ok.

"Elena" <""elena.pocket.\"@"> escribió en el mensaje
de noticias:

Hola a todos!!

Tengo una base donde al diseñarle definí todos los campos de
caracteres como NVARCHAR(MAX).

Ahora me he enterado que ese tipo de datos es para idiomas que
necesitan mas caracteres de los normales (hebreo, japones, arabe,
etc...) y como mis datos son completamente "castellanos" he decidido
cambiar el tipo de datos de NVARCHAR a VARHCAR.
i

MI gran duda es -> puedo perder datos siendo todos los caracteres
castellanos? o no hay ningún problema?

He hecho pruebas a pequeña escala y parece que funciona bien, pero
mi base de datos es bastante grande, como 200.000 registros y me da
miedo arriesgarme a perder datos...


Muchas gracias y un saludo.

Elena