Skip to content

ER diagram and MySQL Data Types readings #12

@plopezgit

Description

@plopezgit

https://www.guru99.com/er-diagram-tutorial-dbms.html
https://disenowebakus.net/tipos-de-datos-mysql.php

er-diagram step by step:

In a university, a Student enrolls in Courses. A student must be assigned to at least one or more Courses. Each course is taught by a single Professor. To maintain instruction quality, a Professor can deliver only one course

entities
[student]
[course]
[professor]

  • enrolling_process log

relation
[student] [course] [professor]

cardinality
[student] * * [course] -||- -||- [professor]

min. attributes
(s.id)
(s.name)

(c.id)
(c.title)

(p.id)
(p.name)

best practices checklist

  • Eliminate any redundant entities or relationships (redundant relation between store/client and province #13 (comment))
  • You need to make sure that all your entities and relationships are properly labeled
  • There may be various valid approaches to an ER diagram. You need to make sure that the ER diagram supports all the data you need to store
  • You should assure that each entity only appears a single time in the ER diagram
  • Name every relationship, entity, and attribute are represented on your diagram
  • Never connect relationships to each other
  • You should use colors to highlight important portions of the ER diagram

tipos de datos:

  • Datos numéricos

  • TINYINT

  • SMALLINT

  • MEDIUMINT

  • INT o INTEGER

  • BIGINT

  • FLOAT

  • DOUBLE

  • DECIMAL (ideal para almacenar valores monetarios, donde se requiera menor longitud, pero la "máxima exactitud")

  • Datos para guardar cadenas de caracteres (alfanuméricos)

  • CHAR (textos breves, de hasta 255 caracteres de longitud como máximo en caracteres que le definamos, aunque no lo utilicemos, por lo tanto, no es eficiente cuando la longitud del dato que se almacenará en un campo es desconocida a priori. ''Util si estamos seguros de que la longitud siempre será la misma.)

  • VARCHAR (Util cuando la longitud del dato es desconocida, cuando depende de la información que el usuario escribe en campos o áreas de texto de un formulario. Será más eficiente para almacenar registros cuyos valores tengan longitudes variables, ya que si bien gasta uno o dos caracteres por registro para declarar la longitud, esto le permite ahorrar muchos otros caracteres que no serían utilizados.)

  • BINARY

  • VARBINARY (Estos dos tipos de datos son identicos a CHAR y VARCHAR, respectivamente, salvo que almacenan bytes en lugar de caracteres)

  • TINYBLOB

  • TINYTEXT

  • TEXT (Antes de la versión 5.0.3. de MySQL, este campo era el utilizado para descripciones de productos, coméntarios, textos de noticia, y cualquier otro texto largo. Pero, a parir de la posibilidad de utilizar VARCHAR para longitudes de hasta 65.535 caracteres, es de esperar que se utilice cada vez menos este tipo de campo.)

  • LONGTEX

  • BLOB (El campo BLOB es para almacenar directamente "la imagen" (o un archivo comprimido, o cualquier otro archivo binario), no su ruta.)

  • MEDIUMBLOB

  • MEDIUMTEXT

  • LONGBLOB

  • ENUM (Lo que se almacenará no es la cadena de caracteres en sí, sino el número de índice de su posición dentro de la enumeración.)

  • SET (Conjunto. Podemos elegir como valor del campo más de uno de los valores de la lista)

  • Datos para almacenar fechas y horas

  • DATE (AAAA-MM-DD)

  • DATETIME (AAAA-MM-DD HH:MM:SS)

  • TIME (HH:MM:SS, util para calcular tiempos trancurridos entre dos momentos cercanos)

  • TIMESTAMP (puede variar entre tres opciones: AAAA-MM-DD HH:MM:SS, AAAA-MM-DD, AA-MM-DD; posee la particularidad de que podemos definir que su valor se mantenga actualizado automáticamente,cada vez que se inserte o que se actualice un registro. De esa manera, conservaremos siempre en ese campo la fecha y hora de la última actualización de ese dato.)

  • YEAR

  • Atributos de los campos

  • NULL

  • DEFAULT

  • BINARY

  • INDEX (Un índice no es más que una tabla "paralela", que guarda los mismos datos que la tabla original, pero en vez de estar ordenados por orden de inserción o por la clave primaria de la tabla, en el índice se ordenan por el campo que elegimos indexar. La búsqueda se realizará primero en el índice, encontrando rápidamente el título buscado, ya que están todos ordenados y, como resultado, el índice le devolverá al programa MySQL el identificador (id) del registro en la tabla original, para que MySQL vaya directamente a buscar ese registro con el resto de los datos, sin perder tiempo)

  • PRIMARY KEY

  • AUTO_INCREMENT

  • UNIQUE

  • FULLTEXT (examinará el contenido de este campo palabra por palabra, almacenando cada palabra en una celda de una matriz, permitiendo hacer búsquedas de palabras contenidas dentro del campo, y no ya una simple búsqueda de coincidencia total del valor del campo)

questions
ahorro, optimizacion, eficiencia, agilidad¿Qué tipo de dato permitirá consumir menor espacio físico de almacenamiento y brindará la posibilidad de almacenar la cantidad de datos que se espera almacenar en ese campo?
hay que considerar siempre cuál será el valor maximo/minimo que se almacenará dentro de un campo, antes de elegir el tipo de dato más adecuado
existe la posibilidad de duplicar el limite de valor máximo positivo de cada tipo de dato entero, si eliminamos la posibilidad de almacenar valores negativos mediante modificador atributos>UNSIGNED

Metadata

Metadata

Assignees

Labels

documentationImprovements or additions to documentation

Projects

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions