Terminando de Estructurar Nuestras Tablas (Continuación del paso 4)

Clase 33 de 63 • Fundamentos de Bases de Datos 2017

Contenido del curso

Introducción al Curso Fundamentos de Bases de Datos

Teoría general de Bases de Datos

Bases de Datos Relacionales

Bases de Datos NO Relacionales y Otros tipos de Bases de Datos

Tomar examen

Comentarios

Marcelo Lavizzari

student•

el campo, foto, estaría bueno, dejarlo varchar, y guardar solo la dirección en donde va ha estar guardada la imagen físicamente, en el servidor.

Yeraldine Martinez

student•

En el trabajo, utilizamos esta técnica! 😃

christian jordy mamani sucasaire

student•

siempre en el campo foto pongo varchar y guardar solo el nombre de la imagen la cual genero un nombre aleatorio 😃

Ivan Robles

student•

Unos cuantos apuntes de la clase:

¿Porque asignar una longitud en el tipo de dato?
Dependiendo de nuestro motor de bases de datos; si dejamos la longitud máxima, podríamos ocupar demasiado espacio en memoria que no necesitamos. Hay que economizar datos. 😉

Para evitar inconsistencia en la base de datos, ya que tenemos varios campos que se repiten en diferentes tablas, vamos a utilizar una notación (también por buena practica) donde dependiendo de la tabla, al nombre de la tabla le agregamos el nombre del campo ID como Cliente_ID.

OLE tipo de datos que permite tener objetos en una base de datos. Una base de datos es muy buena trabajando con caracteres, sin embargo se pueden trabajar imágenes, documentos y archivos. Aunque generalmente para ese tipo de cargas vamos a tener una base de datos no estructural.

Debido a que el tipo de dato para moneda ya sea dolares, euros, yenes, etc. no esta estandarizado en los diferentes motores SQL, recomienda utilizar Varchar.

Analia De La Reta

student•

yo uso tu tecnica guardo solo el nombre del archivo y en el web config la ruta…

Joaquin Araujo

student•

Nota importante: No hay datos que no sirvan, simplemente aún no se han convertido en información.

Yeraldine Martinez

student•

Un ejemplo muy sencillo de análisis de los datos en la vida real… En la empresa donde trabajo,hicimos el lanzamiento de un sistema de compra de citas en linea y almacenamos el dispositivo desde donde se hizo la compra. Eso nos ha permitido ver que debemos acelerar el proceso de desarrollo de las App, ya que el porcentaje de compras desde móvil es alto.

Saúl Morales

student•

Y esta estadistica no la podrias medir por ejemplo con google analytics, economizarias memoria en el uso de base de datos

Daniel Cadavid

student•

Pero así el dato seria mas preciso, ya que se tendrían los dispositivos con los que se realizaron compras efectivas

Hector Vasquez

student•

Otra opción para manejar los nombre de campos sin necesidad de usar un prefijo, es usar alias de tablas al momento de consultar los datos:

Campos:
En vez de mCompra_ID —> id
En vez de mCompra_cod --> cod

Consulta:
En vez de select mCompra_ID, mCompra_cod from mCompra; ----> select , mc.cod from mCompra mc;

Más corto e igual de entendible.

Camilo Caquimbo Tabares

student•

Exacto, mucho más práctico y claro a la hora de hacer consultas.

Cesar David Ramírez Dimaté

student•

Toda una vida, agregarle prefijos a los atributos de una tabla cuando puedo colocar un alias en una consulta sql es algo importante de resaltar.

Guillermo R. Pagan

student•

No hay datos que no sirvan si no que hay datos que no se han convertido en información

Transpais

student•

Esta Nomenclatura siempre me ha dado buen resultado

Transpais

student•

lean este articulo también

Daniel Alvarez

student•

Se podrían agregar los siguientes atributos:
ITEM -> precio / proveedor
PROVEEDOR -> ubicación(pais-ciudad)

Cesar David Ramírez Dimaté

student•

El tema es que según como está planteado en el ejercicio un item puede haber sido creado por muchos proveedores. Por ejemplo los componentes de un iphone vienen de varias compañías.

Yury D. Morales

student•

No hay datos que no me sirvan, sino que hay datos que no hemos convertido en informacion

Andre La Rosa Serrano

student•

"Nunca nunca nunca piensen que un dato no les va a servir, que es un dato tonto, prefieran ponerlo o ponerlo opcional, no hay datos que no me sirvan, simplemente hay datos que no se han convertido en información" En serio esa parte fue extremadamente brutal, sobretodo a lo que se refiere a negocios. Muchas gracias Pedro

JUAN SEBASTIAN RODRIGUEZ JIMENEZ

student•

buen aporte

Cristian Orozco Benjumea

student•

Para posteriores analisis financieros yo le agregaría a ITEM los atributos de:

Item_precioVenta
Item_costoUnitario
Item_cantidadVenta

Y en CLIENTE el tipo de dato para la fecha de cumpleaños lo pondría DATE en lugar de TIMESTAMP.

Está muy bueno este curso 👍

Blanca Segura Garcia

student•

Para el tipo “Item_foto” (Atributo OLE - OBJETOS) Se puede usar también VARCHAR y poner un link a un archivo “imagen”. Así se evitaría la carga de la base de datos, puesto que es más rápida con caracteres. Me equivoco?

Diego Forero

Team Platzi•

Si, como buena practica nunca se deben almacenar binarios en la base de datos, lo mejor es usar el sistema de archivo para guardar el archivo y en la base de datos guardas la ruta donde esta el archivo.

German Alberto Cruz Vargas

student•

O puedes reescribir el comentario: “…también VARCHAR y poner la codificación base64 string de la imagen…” y luego completar con “puesto que es más rápida con caracteres”.

Oscar Ignacio Encinas Verduzco

student•

¿Cuándo usar timestamp o datetime y por qué?

Diego Forero

Team Platzi•

TIMESTAMP usa 4 bytes mientras que DATETIME usa 8.
Timestamps son mas rápidos de indexar en la base de datos.
DATETIME se debe usar cuando necesitas guardar día y hora y tiene un soporte de fechas desde ’1000-01-01 00:00:00′ a ’9999-12-31 23:59:59′.
TIMESTAMP tiene un rango de ’1970-01-01 00:00:01′ UTC a ’2038-01-09 03:14:07′ UTC. esto puede cambiar dependiendo de la versión de la base de datos.
DATETIME es un valor constante mientras que TIMESTAMP cambia el valor dependiendo de la zona horaria.

Eloy Rolando Canchanya Balbin

student•

Entonces para datos de diferentes países debo utilizar DATIME?

Carlos Zea

student•

a mi solo me quedo una duda, por qué sería recomendable crear una nueva entidad para trabajar las fechas de inicio, fecha de ultima compra en el proveedor?

Juan Camilo Lezcano Benitez

student•

Hola, es mejor poner esos atributos en una nueva entidad para poder tener el registro histórico de todas las compras hechas a cada proveedor, porque si se deja así como está solo se tiene la información de la última compra hecha por proveedor. En esa nueva entidad se pueden incluir otros atributos como tipo de producto comprado, cantidad, precio y cualquier otro que se nos ocurra relativo a las compras con los proveedores.

Irving Juárez

student•

Creo que las fechas quedan dentro de el producto. Ya que en la entidad producto se puede ver cuando fue comprado y si este fue devuelto

Cesar David Ramírez Dimaté

student•

Realmente no recomiendo colocar un alias por cada atributo de una tabla, porque al final yo puedo colocar ese alias en una consulta.

SELECT cli.nombre, cli.correo FROM Cliente AS cli;

Hans Piña

student•

Creo que abusan de las abreviaciones; sacrifican ‘readability’ por ahorrarse tres caracteres. Lo considero mala práctica.

Fuera de eso, el curso es espectacular.

José Alberto Ortiz Vargas

student•

Con respecto a la entidad PROVEEDOR, en lo personal, en la Universidad me dejaron bien grabado que si ya tienes un dato, NO lo repitas, solo reutilizalo. En esta idea de la PlatziStore si el área de Contabilidad ya cuenta con un registro de PROVEEDORES, ¿Sera más factible “jalar” esta información ya existente y usarla en mi DB? Entiendo que existen sistemas cerrados que no permiten ver sus BD, sin embargo, estos mismos cuentan con API’s para poder consultar la información que necesito para otros fines. Saludos

Diego Forero

Team Platzi•

No hay una verdad absoluta en cuanto a esto, muchas veces si tu base de datos de proveedores es de un programa contable no tienen api que se puedan obtener y no sera factible hacer eso.

Sebastian Gomila

student•

MyTwoCents: Con respecto a esto yo siempre manejo un ID (serial/autoincrement) propio de la entidad y cuando es necesario agrego una atributo Código con un indice unique y not null. De esta manera si, por cualquier razón, ese código cambia puedo actualizarlo sin tener que actualizar relaciones en Base de datos que no soporte cascade.

José Andrés Salmerón Alfaro

student•

Un autoincremento nunca se repite no e tiendo porque le agregan otro campo más a la llave primaria

José Alberto Ortiz Vargas

student•

Al trabajar con Base de Datos con algunos colegas, yo soy de los que les gusta tener información de sobra y varias veces ponía datos de más a mis entidades, a lo cual a mis colegas llegaban a molestarse y algunas veces me decían que eran datos tontos e innecesarios. Ahora se que no estaba equivocado ;´)

Andric Alejandro Vargas Alarcón

student•

SI generas un buen reporte gerencial, con esos datos “tontos” , te preguntarán: y como los viste?;

Renzon Alirio Cáceres Flechas

student•

Creo que también es necesario como buena practica, crear atributos de tipo timestamp para manejar la fecha en que se hace un registro en la tabla, y la fecha en que este se modifique, esto para tener un mejor control de nuestros datos.

Terminando de Estructurar Nuestras Tablas (Continuación del paso 4)

Introducción al Curso Fundamentos de Bases de Datos

¡Vamos a renovar este curso!

Introducción al Curso de Bases de Datos

Teoría general de Bases de Datos

Propósito general de las Bases de Datos

Tipos de Bases de Datos y sus aplicaciones en la industria

Visión general de los datos

Tipos de Datos

Diferentes tipos de Bases de Datos

Reto ¿Hadoop y Blockchain podrían cambiar una Base de Datos tradicional?

Bases de Datos Relacionales

¿Qué es una Entidad?

¿Qué es una Relación?

Características o datos de una Entidad

¿Ya aparecieron las llaves?

Índices e Indexación

Constraints o Restricciones

Capas de abstracción del modelo Entidad-Relación

Metodología básica de 9 pasos con Barker (Paso 1) Identificar Cuáles son las Entidades Resuelven Nuestro Problema

Metodología básica de 9 pasos con Barker (Paso 2): Identificación de las Relaciones de las Entidades.

Metodología básica de 9 pasos con Barker (Paso 3): Entidades y Relaciones

Metodología de Diseño (Correcciónes del paso 2 y 3)

Metodología de Diseño (Paso 4): Asignar Atributos a las Entidades.

Metodología de Diseño (Solución del paso 4): Terminando de Asignar Atributos a las Entidades

Metodología de Diseño (Pasos 5, 6 y 7) 5. Generar un diagrama conceptual, 6. Modelo lógico, 7. Identificar nuevos atributos que generan nuestras entidades débiles.

Metodología de Diseño (Paso 8): Construir el Diagrama del Modelo Físico

Metodología de Diseño (Paso 9): Pasar al estándar de la base de datos (SQL)

Reto con el paso 4 de la Metodología de Diseño

Bases de Datos NO Relacionales y Otros tipos de Bases de Datos

Atomicidad y consistencia

Aislamiento y durabilidad

Bases de Datos In-Memory (Cambio de árboles a columnar)

Otros tipos de Bases de Datos en la industria

Bases de Datos In-Memory con indexación de columnar

Definiendo el Proyecto y Generando Entidades de PlatziStore: Pasos 1 y 2

Definir la Estructura de la Tabla Cliente del Proyecto: Pasos 3 y 4

Terminando de Estructurar Nuestras Tablas (Continuación del paso 4)

Metodología de Diseño (Paso 5): Diagrama Conceptual

Metodología de Diseño (Paso 6 y 7): Modelo Lógico y Entidades Débiles

Solución de atributos de entidad del proyecto - Atributos adicionales a entidad débil creada

Metodología de Diseño (Paso 8)

Llevando nuestro proyecto a SQL (Paso 9)

Terminando la Implementación del Proyecto (Paso 9)

Dependencias funcionales

Normalización, llevando el proyecto hasta tercera forma normal (primera forma normal)

Normalización, llevando mi proyecto hasta tercera forma normal (segunda forma normal)

Normalización, llevando mi proyecto hasta tercera forma normal (Cuarta y quinta forma normal)

Comenzando con SQL

DDL: Data Definition Language y DML: Data Manipulation Language

ACID desde lo no relacional

CAP

Scale Out y Scale Up

¿Scale out o Scale up?

DBMS en nube para poder iniciar una aplicación propia

IMPORTANTE: Preparación del entorno de trabajo

Estructura básica de un Query

Aprendiendo a Hacer más Querys

Estructura básica del Query con más de una tabla

Estructura básica del Query con más de una tabla 2

Tuplas y más tuplas

Insertar registros

Joins

Noo SQL Aplicado, Planteando el Problema

Aplicando NoSQL: Colecciones y Shards

Aplicando noSQL: Integración de Comunicaciones y Hardware en una Base de Datos Scale OUT

Aplicando noSQL: Integrando JSON a Bases de Datos No Relacionales

Conclusiones del curso