?Quieres mejorar esta duda? Actualiza la duda con el fin de que se pudiese contestar con datos y no ha transpirado citas al editar esta publicacion.
Cerrada realiza 3 anos .
Estoy aprendiendo referente a SQL asi como me ha surgido la dilema, en busqueda sobre tener creados de forma adecuada los tipos sobre antecedente.
Me gustaria saber que arquetipo sobre dato recomiendan Con El Fin De almacenar:
- Nombres
- Direcciones
- Telefonos
- Correos Electronicos
- Fechas
- Imagenes
- Numeros enteros
- Numeros con decimal
Si poseen un cronica que hable sobre lo cual, igualmente estaria agradecido.
5 respuestas cinco
Segun mi experiencia y no ha transpirado limitandome al relacion que diste serian de la sub siguiente forma:
- Nombres -> Varchar(largura)
- Direcciones -> Varchar(longitud)
- Correos -> Varchar(largura)
- Fechas -> Date o Datetime, dependiendo lo que requieras y no ha transpirado la version sobre SQL que estes utilizando.
- Imagenes -> Varchar(longitud)
- Numeros enteros -> Int o BigInt en funcii?n el limite del cantidad a ingresar.
- Numeros con decimal -> Decimal
Podria acontecer util Asimismo el arquetipo BIT que funciona como un true/false , no obstante en la base se almacena igual que Cero desplazandolo hacia el pelo 1 .
Las tipos de datos que especifique estan pensados Con El Fin De SQL 2008, creo que anadieron mas modelo sobre datos para versiones posteriores aunque ignoro cuales son.
Te dejo el producto clases de datos (Transact-SQL) (en espanol) con el fin de que te interiorices mas
Creo que tu pregunta seria por el lado de la BD mas nunca por el estilo, por ende seria lo recomendado asi:
Nombres nvarchar (cant)
Direcciones nvarchar (cant)
Telefonos nvarchar (cant)
Correos Electronicos nvarchar (cant)
Imagenes nvarchar (En Caso De Que le pasas la URL)
Imagenes binary(Si le pasas la URL)
Numeros enteros int(cant)
Numeros con decimal decimal()
Espero que te usar !, me cunetas.
En SQL en general, para los nombres, direcciones, telefonos, correos electronicos yo usaria String o VARCHAR. Omitiendo lo evidente igual que en nombres asi como direcciones, el caso sobre las telefonos invariablemente existe personas que disenan sus bases sobre datos con NUMERIC o INT No obstante todo el tiempo hay el inconveniente con las telefonos con ceros al inicio e inclusive con numeros sobre identificacion (DNI o cedula). De el caso sobre las emails o correos electronicos te recomiendo VARCHAR de igual manera que con los nombres o direcciones, controlando el registro de que sean solo emails, desde tu aplicacion o proyecto, desplazandolo hacia el pelo no desde tu BD, es una actividad menor de la BD desplazandolo hacia el pelo la aplicacion o plan la puede controlar desde que se registra en el formulario.
Para el caso de estas fechas a no ser que necesites enteramente la fecha con hora usa DATETIME No obstante En Caso De Que unicamente es obligatorio Con El Fin De tu registro en BD la fecha se sirve prototipo DATE. Manejar luego consultas en SQL con datos prototipo DATETIME es complicado y necesitas siempre convertidores o parsear la data en tu programa.
Lo cual en base a la experiencia. Saludos
Si el motor de base sobre datos que se vaya an emplear tiene un tipo sobre referencia nativo de recolectar fechas, usarlo de acumular las fechas.
Existe que establecer si para ese motor sobre base de datos las fechas son separado el ano-mes-dia o si se incluye el componente sobre hora-minuto-segundo.
Es importante anotar que una cosa es como la base sobre datos almacena un tasacii?n sobre modelo DATA desplazandolo hacia el pelo otra muy diferente igual que se visualiza en monitor o se imprime esa fecha.
En el caso de Oracle , ( SQL y el lenguage PL/SQL ) existe el arquetipo de referencia DATE (tanto de columnas igual que Con El Fin De variables) con el que se almacena la fecha con la hora-minuto-segundo.
El usar un clase sobre dato ” STRING ” Con El Fin De almacenar desplazandolo hacia el pelo manejar fechas es obstaculo puesto que existen un sinumero de formas de redactar una cadena (o string) que represente una fecha, que dependeri? fundamentalmente del estado desplazandolo hacia el pelo asi como con los cuales se producen errores al segundo de disponer, explorar y no ha transpirado contrastar fechas.
Ejemplo: Si la data es 10 de agosto sobre 2018, entonces Existen estas alternativas:
- De EEUU desplazandolo hacia el pelo otros paises seria “08/10/2018” (el mes principal)
- En Europa seria comun escribirla como “10/08/2018” (el fecha primeramente)
- O escribir el mes con un texto igual que “30-agosto-2018”
Ej de error al usar strings Con El Fin De representar la dia: Si existe 2 cadenas que representan la fecha almacenada como dia/mes/ano:
-
la forma de mensaje de alguien en ukraine date
- “04/01/2017” ( para el 04 de enero de 2017)
- “03/02/2018” ( para el 03 sobre marzo de 2018)
Se permite la contraposicion de los 2 strings y cual sera inferior? La respuesta es que por comparacion sobre strings el menor es “03/02/2018” lo que seria errado!! puesto que desde el momento de mirada que el string representa una data la cual seria MAYOR que la dia “04/01/2017”.
Si definitivamente Tenemos que usar escrito (o strings) para almacenar la data la sugerencia es usar la criterio ISO 8601, con la cual el string SIEMPRE es:
Con el fin de ano-mes-dia es “AAAAMMDD” o “AAAA-MM-DD” asi como con hora-minuto-segundo es “AAAAMMDDTHHMMSS” o “AAAA-MM-DDTHH:MM:SS” o “AAAA-MM-DD HH:MM:SS”