Cual seri­a el superior prototipo de noticia Con El Fin De acumular nombres, direcciones, entre otros [cerrada]

Cual seri­a el superior prototipo de noticia Con El Fin De acumular nombres, direcciones, entre otros [cerrada]

?Quieres perfeccionar esta pregunta? Actualiza la pregunta con el fin de que se pueda contestar con datos y no ha transpirado citas al editar esta publicacion.

Cerrada hace 3 anos de vida .

Estoy aprendiendo sobre SQL desplazandolo hacia el pelo me ha surgido la duda, en busqueda sobre tener creados de manera adecuada las clases sobre referencia.

Me gustaria saber que modelo de documento recomiendan para almacenar:

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

En caso de que poseen un producto que hable sobre esto, ademas estaria agradecido.

5 respuestas 5

Segun mi vivencia desplazandolo hacia el pelo limitandome al relacion que diste serian sobre la siguiente maneras:

  • Nombres -> Varchar(largura)
  • Direcciones -> Varchar(largura)
  • Correos -> Varchar(longitud)
  • Fechas -> Date o Datetime, dependiendo lo que requieras desplazandolo hacia el pelo la version sobre SQL que estes utilizando.
  • Imagenes -> Varchar(longitud)
  • Numeros enteros -> Int o BigInt en funcii?n el limite del numero a ingresar.
  • Numeros con decimal -> Decimal

Podria acontecer util Ademi?s el tipo BIT que funciona como un true/false , no obstante en la base se almacena como 0 y no ha transpirado 1 .

Los clases sobre 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 escrito Tipos de datos (Transact-SQL) (en espanol) con el fin de que te interiorices mas

Creo que tu pregunta es por el aspecto sobre la BD mas no por el jerga, por ende seria lo recomendado asi:

Nombres nvarchar (cant)

Direcciones nvarchar (cant)

Telefonos nvarchar (cant)

Correos Electronicos nvarchar (cant)

Imagenes nvarchar (Si le pasas una URL)

Imagenes binary(Si le pasas una URL)

Numeros enteros int(cant)

Numeros con decimal decimal()

Espero que te ser !, me cunetas.

En SQL en general, Con El Fin De las nombres, direcciones, telefonos, correos electronicos yo usaria String o VARCHAR. Omitiendo lo indudable como en nombres y no ha transpirado direcciones, el caso sobre los telefonos siempre Existen gente que disenan las bases de datos con NUMERIC o INT aunque invariablemente existe el impedimento con las telefonos con ceros al inicio e inclusive con numeros de identificacion (DNI o cedula). Para el caso de las emails o correos electronicos te recomiendo VARCHAR sobre igual forma que con las nombres o direcciones, controlando el registro sobre que sean unicamente emails, desde tu uso o proyecto, desplazandolo hacia el pelo nunca desde tu BD, es una faena menor para la BD asi­ como la aplicacion o programa la puede controlar desde que se registra en el formulario.

De el caso de las fechas a no ser que necesites enteramente la data con hora usada DATETIME sin embargo si solo seri­a necesario Con El Fin De tu registro en BD la dia emplea tipo DATE. Manejar seguidamente consultas en SQL con datos modelo DATETIME seri­a dificil asi­ como precisas todo el tiempo convertidores o parsear la data en tu programa.

Lo cual en base a la habilidad. Saludos

Si el motor de base sobre datos que se vaya an utilizar goza de un arquetipo sobre dato nativo Con El Fin De acumular fechas, usarlo Con El Fin De almacenar las fechas.

Existe que determinar si de ese motor de base de datos las fechas son unicamente el ano-mes-dia o si se incluye el componente de hora-minuto-segundo.

Es relevante anotar que la cosa seri­a como una base sobre datos almacena un tasacii?n de modelo DIA y no ha transpirado otra bastante diferente igual que se visualiza en pantalla o se imprime esa fecha.

En el caso de Oracle , ( SQL asi­ como el lenguage PL/SQL ) existe el tipo sobre documento DATE (tanto de columnas como Con El Fin De variables) con el cual se almacena una dia con la hora-minuto-segundo.

El usar un arquetipo de antecedente ” STRING ” de recolectar y no ha transpirado manejar fechas es inconveniente ya que Hay un sinumero de maneras de escribir una cadena (o string) que represente una fecha, que depende fundamentalmente del pais y y con las cuales se producen errores al momento sobre ordenar, indagar y contrastar fechas.

Modelo: Si la dia seri­a diez de agosto sobre 2018, entonces hay estas alternativas:

  • Con el fin de Estados Unidos desplazandolo hacia el pelo otros paises seri­a “08/10/2018” (el mes primeramente)
  • En Europa seri­a habitual escribirla igual que “10/08/2018” (el jornada primero)
  • O escribir el mes con un texto como “30-agosto-2018”

Ej de error al utilizar strings Con El Fin De representar la dia: Si Tenemos 2 cadenas que representan la data connecting singles citas almacenada como dia/mes/ano:

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

Se permite la confrontacion sobre las 2 strings desplazandolo hacia el pelo cual sera menor? La respuesta es que por confrontacion de strings el menor seri­a “03/02/2018” lo cual seri­a errado!! ya que desde el aspecto de mirada que el string representa una fecha la que es MAYOR que la dia “04/01/2017”.

Si definitivamente existe que utilizar escrito (o strings) Con El Fin De acumular la dia la sugerencia es utilizar la criterio ISO 8601, con la que el string TODO EL TIEMPO 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”

Tinggalkan Komentar

Alamat email Anda tidak akan dipublikasikan.