campo vacío varchar consume byte?
Hola a Todos tengo una consulta a ver si me evacuan la duda con conocimiento en Firebird 2.5 en adelante:
Tengo mi tabla con campos ya establecido pero apareció un usuario que requiere utilizar hasta 1000 caracteres en un nuevo campo (una descripción super más ampliada) el punto es que buscando no he encontrado algo que me saque el 100% de la duda ya que unos dicen que aunque no mandes valor al campo los 1000 se convierte siempre en byte o sea 1000*1 byte +2 bytes=1002 bytes. y si en mi base de datos tengo 25,000 (veinte cinco mil registro) y ese campo me consume 1002 byte = 1 kilobyte seria por registro aumentando un ejemplo 25 megabyte lleve o no lleve caracteres. y hay otra la cual dice que no ocupa nada. Favor alguien me puede ayudar para salir de dudas a partir de experiencia? Saludos; novato_erick |
Un campo VARCHAR/NVARCHAR (puesto a escoger mejor el segundo), almacena datos de longitud variable. La longitud que se almacena es la longitud del dato+1. El "+1" es porque ese byte guarda la longitud real utilizada.
Piensa que existe la posibilidad de definir VARCHAR(MAX), por lo tanto no tiene sentido que siempre se guarde ese MAX en la Nase de Datos. Cita:
Como te he dicho, cada registro no ocupará los 1000+1, sino el DATO_REAL_ALMACENADO+1. |
Un varchar vacío no ocupa nada, bueno, sí, lo que dice Neftali, lo mínimo para indicar que existe y su longitud.
En firebird no existe nvarchar, equivale a varchar(4000). https://firebirdsql.org/manual/migra...ata-types.html |
En otras Base de Datos NVARCHAR se usa para Unicode y VARCHAR se mantiene por compatibilidad.
Por lo que veo en FB, VARCHAR ya soporta unicode utilizando el CharacterSet. |
Gracias por su pronta respuesta a dos eminencias. v:-)v
Cita:
La duda fue evacuada. Cita:
Muchisimas Gracias Chicos nuevamente soy previlegiado por su intervención. ^\||/ Saludos desde Panamá. novato_erick Doy por solucionado esta duda... |
La franja horaria es GMT +2. Ahora son las 11:04:34. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi