Cual seri­a el mejor modelo sobre dato para acumular nombres, direcciones, entre otros [cerrada]

?Quieres superar esta duda? Actualiza la duda para que se pueda contestar con datos desplazandolo hacia el pelo citas al editar esta publicacion.

Cerrada realiza 3 anos .

Estoy aprendiendo en SQL desplazandolo hacia el pelo me ha surgido la dificultad, en exploracion de tener creados de modo adecuada los clases sobre prueba.

Me gustaria saber que arquetipo sobre documento recomiendan Con El Fin De acumular:

  • Nombres
  • Direcciones
  • Telefonos
  • Correos Electronicos
  • Fechas
  • Imagenes
  • Numeros enteros
  • Numeros con decimal

En caso de que tienen un escrito que hable de esto, igualmente estaria agradecido.

5 respuestas 5

Segun mi destreza y limitandome al relacion que diste serian sobre la sub siguiente maneras:

  • Nombres -> Varchar(longitud)
  • Direcciones -> Varchar(largura)
  • Correos -> Varchar(longitud)
  • Fechas -> Date o Datetime, dependiendo lo que requieras y no ha transpirado la interpretacion de SQL que estes utilizando.
  • Imagenes -> Varchar(largura)
  • Numeros enteros -> Int o BigInt dependiendo el limite del numero a ingresar.
  • Numeros con decimal -> Decimal

Podria acontecer util Ademi?s el prototipo BIT que funciona igual que un true/false , si bien en la base se almacena igual que 0 y 1 .

Las tipos sobre datos que especifique estan pensados para SQL 2008, creo que anadieron mas tipo de datos para versiones posteriores aunque ignoro cuales son.

Te dejo el producto clases sobre datos (Transact-SQL) (en espanol) para que te interiorices mas

Creo que tu duda seri­a por el aspecto sobre 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 una URL)

Imagenes binary(En Caso De Que le pasas una URL)

Numeros enteros int(cant)

Numeros con decimal decimal()

Espero que te asistir !, me cunetas.

En SQL en general, Con El Fin De los nombres, direcciones, telefonos, correos electronicos yo usaria String o VARCHAR. Omitiendo lo obvio igual que en nombres y direcciones, el caso sobre las telefonos continuamente Existen individuos que disenan sus bases de datos con NUMERIC o INT pero continuamente hay el impedimento con las telefonos con ceros al inicio e inclusive con numeros de identificacion (DNI o cedula). De el caso sobre las emails o correos electronicos te recomiendo VARCHAR de igual forma que con los nombres o direcciones, controlando el registro sobre que sean separado emails, desde tu aplicacion o plan, y no desde tu BD, es una actividad menor de la BD y no ha transpirado la empleo o programa la puede dominar desde que se registra en el formulario.

Para el caso de las fechas a menos que necesites enteramente la data con hora usa DATETIME sin embargo En Caso De Que unicamente seri­a necesario Con El Fin De tu registro en BD la fecha utiliza prototipo DATE. Manejar despues consultas en SQL con datos clase DATETIME seri­a complicado desplazandolo hacia el pelo precisas invariablemente convertidores o parsear la data en tu programa.

Lo cual en base a la experiencia. Saludos

Si el motor sobre base de datos que se vaya an usar posee un prototipo sobre prueba nativo de recolectar fechas, usarlo para acumular las fechas.

Existe que precisar En Caso De Que para ese motor de base de datos las fechas son solo el ano-mes-dia o En Caso De Que se abarca el componente de https://datingrating.net/es/interracialcupid-review/ hora-minuto-segundo.

Seri­a relevante anotar que la cosa es como una base de datos almacena un tasacii?n de tipo DATA asi­ como una diferente bastante distinta como se visualiza en pantalla o se imprime esa data.

En el caso sobre Oracle , ( SQL asi­ como el lenguage PL/SQL ) hay el prototipo de dato DATE (tanto para columnas como Con El Fin De variables) con el que se almacena la dia con la hora-minuto-segundo.

El usar un prototipo sobre antecedente ” STRING ” para almacenar y manejar fechas seri­a problema porque Hay un sinumero de formas sobre escribir la cadeneta (o string) que represente una fecha, que va a depender fundamentalmente del pais y no ha transpirado asi­ como con las cuales se producen fallos al segundo sobre adecentar, procurar asi­ como cotejar fechas.

Prototipo: En Caso De Que la dia seri­a 11 de agosto sobre 2018, por lo tanto hay estas alternativas:

  • Con el fin de EEUU y no ha transpirado otros paises seri­a “08/10/2018” (el mes principal)
  • En Europa seri­a habitual escribirla como “10/08/2018” (el jornada principal)
  • O escribir el mes con un texto igual que “30-agosto-2018”

Ejemplo sobre error al utilizar strings para representar la fecha: Si existe 2 cadenas que representan la data almacenada como dia/mes/ano:

  • “04/01/2017” ( de el 04 de enero sobre 2017)
    • “03/02/2018” ( para el 03 de marzo de 2018)

Se hace la confrontacion sobre las 2 strings desplazandolo hacia el pelo cual sera inferior? La solucii?n es que por contraposicion de strings el inferior seri­a “03/02/2018” lo que es errado!! ya que desde el tema sobre mirada que el string representa una dia la que es MAYOR que la data “04/01/2017”.

Si definitivamente Existen que usar texto (o strings) Con El Fin De almacenar una data la recomendacion es utilizar la criterio ISO 8601, con la cual el string SIEMPRE es:

De ano-mes-dia seri­a “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”