*¡Diseña la base de datos de un proyecto real!* Olvídate del típico curso de base de datos donde solo te enseñan teoría. En este taller 🛠 bit.ly/3fHNu4i aprenderás con proyecto real.
Espectacular, hice un return mental al 2015, donde me toco realizar cada uno de los pasos aquí mencionados. El correcto analisis de datos es un proceso complejo cuando tienes empresas con ideas novedosas. Buen video.
Profesor me parece un excelente vídeo introductorio al mundo de las bases de datos, sin embargo difiero con usted con la etapa de modelo entidad relación. Considero que es una etapa muy importa aunque como usted dice puede realizarse o no; todo dependerá de la complejidad del proyecto porque para principiantes incluyo experto desarrollando base de datos, esta etapa otorga mucha información sobre el flujo de los datos, es decir, como funciona la organización y como están relacionadas las entidades bajo que verbo están relacionadas las entidades. Entonces es una etapa muy vital 1-si eres principiante 2-si no se entiende muy bien cual es el problema que se quiere resolver porque es algo nuevo o es complejo 3-permite saber desde el principio la cardinal de las entidades 4-el grado de la entidades 5-el mas importante si no se entiende como fluye la información en la empresa se logra con este diagrama entender como están relacionadas las entidades
Yo siento diferir con el que difiere :). En mi opinión y vivencia personal (llevo los últimos 15 años trabajando con bases de datos en grandes proyectos nacionales e internacionales), la única utilidad del modelo E/R es su faceta docente. La cual considero muy importante para cuadrar ideas. En serio, el último diagrama E/R que tuve que hacer fue en 2002 para un examen en la universidad. Por cierto, me pusieron el modelo de subastas Ebay y me estalló un poco la cabeza en las 4h de examen. En el trabajo, nunca he visto uno ni he tenido que hacer uno. ¡Nunca!. Y trabajo con bases de datos a diario. ¿Quiere decir eso que no se analiza o diseña? No. Quiere decir que no es una herramienta que haya utilizado en mi experiencia, ni nadie con quién haya trabajado, que han sido muchos profesionales de numerosos países. Luego podríamos hablar de los diagramas de clases, ese gran contendiente supuestamente venido a solventar muchos de los problemas del E/R. Si bien sí que me he encontrado e incluso he credo bastantes a lo largo de mi carrera, tampoco han sido imprescindibles (me solían mirar raro cuando llegaba con uno hecho). Al final, los diseños de datos que he elaborado y que he visto elaborar han comenzado directamente con el modelo relacional y de ahí, salvo detalles de implementación, al RBDMS del tirón. En proyectos medianos, directamente al RDBMS. En el último proyecto que estuve creamos unas 500 tablas para un negocio del cual no teníamos ni idea cómo funcionaba (ya sabemos algo :)), y no pintamos ni una sola caja/rombo. A día de hoy es un sistema en el que trabajan miles de usuarios en paralelo y no tenemos problemas de datos. Más bien, el diseño de nuestras tablas nos facilita enormemente el día a día resolviendo incidencias en productivo. Ergo, no fue ninguna lastra no haber recurrido a E/R. En el fondo, son conceptos que al final ya llevas por dentro y los aplicas de forma ágil sin necesidad de pintarlos (así lo veo yo). El otro día leí una encuesta/reflexión, creo que en stack overflow, en la que se hablaba precisamente de la falta de uso real de los diagramas clásicos (UML fundamentalmente) a pesar de habernos grabado a fuego en nuestros periodos formativos cuan importantes eran. En fin. Para gustos colores y para opiniones personas :). Aunque hay que rendirse ante la evidencia.
@@sandyland170 Hay mucha evidencia de que el diseño conceptual se omite en la gran mayoría de casos. No hay evidencia de que sea la mejor alternativa. Pues el que la gran mayoría elija omitir este paso no implica que sea lo ideal ni lo mejor. ¿Es necesario? No ¿Es Imprescindible? No ¿Es mejor no omitirlo? Debatible Lo que yo he visto observando a varios equipos, con distintas metodologías, trabajando con varios clientes, es que en un principio parece una perdida de tiempo empezar con un diseño conceptual; pero a la larga, el soporte y mantenimiento de la base de datos que se empezó diseñando a partir de este punto era mucho más eficiente y las bases de datos en sí eran mucho más robustas. Sin embargo, desconozco si hay estudios serios sobre el tema, lo mío es una observación empírica y yo soy solo una persona por ende lo que digo no sirve como evidencia incluso habiendo trabajado con más de 40 equipos diferentes y miles de clientes. Se necesitaría un estudio con más personas, y muchos años vigilando proyectos para sacar una conclusión más certera. Pero mi opinión es que, personalmente creo que el diseño conceptual está infravalorado, en parte por desconocimiento y en parte por pereza.
En la teoría así se modela, en la práctica el cliente pide una monstruosidad a ultimo momento que hace que empieces a duplicar registros hasta que un día tienes tablas duplicadas y si las borras le das en la madre a las reglas de negocio. Lo que enseñan en la escuela es para casos iniciales, muy pocas empresas mantienen una base correctamente relacionada durante las etapas de crecimiento.
En EDteam los primeros meses de la plataforma tuvimos que hacer muchos cambios a ultimo minuto. Pero, jamás dupliqué registros innecesariamente. Porque en ese último minuto tu debes documentar bien (por lo menos el proceso tabular) y ahí ya evitas esos problemas. Ahí entra tu criterio para que en el último minuto se siga haciendo correctamente.
Lo último que menciona es muy importante, yo siempre tengo un dilema con eso, pero hay veces en que, o cumples con los principios de la normalización de bases de datos, o con los requerimientos del cliente (obviamente este último es el más importante, y es allí cuando empiezas a aplicar redundancia en algunas tablas)
las excepeciones que me tocaron hacer es cuando hago tablas "auditorias" es decir para que la data quede cruda sin dependencia de campos para usarlas posteriormente en un ETL , porque si jalo la data por ejemplo de un detalle de factura. los usuarios por lo general tienden a cambiar información de un producto o eliminarlos.
A mí personalmente no me gustan. Si no sabes SQL, úsalos. Si el proyecto es un prototipo, úsalo. Si el proyecto es pequeño, úsalo. Luego vas a tener que ir migrando a escribir los SQL para mejorar el performance y personalización
@@Alexyslozada podrian hacer un video de pros y cons de usar ORM y cuando es recomendable usar y cuando no saludos excelente contenido mucho exito!!! 👍
@@Alexyslozada muchas gracias. Yo tampoco lo prefiero pero lo veo en frameworks muy potentes como "Grails". He visto proyectos enormes que trabajan muy ágiles usando ese framework. De allí nació mi duda 🤔😁👌
Soy yo Pero Visual Studio code no te deja instalar el interprete de python y si lo tienes instalado te lo desintala y te dice que lo vuelvas ha instalar
Gracias por su vídeo. Debería de ir más al grano con su exposición ya que da muchas vueltas para decir una cosa muy simple. Le ánimo a lanzar vídeos en esta línea para ser más didáctico. Gracias por su trabajo. Saludos des de España.
![[UNCUT] The Loyal Pin ปิ่นภักดิ์ EP.15 (3/4)](http://i.ytimg.com/vi/IVwR87OH0_A/mqdefault.jpg)
![[안방1열 직캠4K] 베이비몬스터 치키타 'DRIP' (BABYMONSTER CHIQUITA FanCam) @SBS Inkigayo 241110](http://i.ytimg.com/vi/tnlxo79cAqY/mqdefault.jpg)
*¡Diseña la base de datos de un proyecto real!*
Olvídate del típico curso de base de datos donde solo te enseñan teoría. En este taller 🛠 bit.ly/3fHNu4i aprenderás con proyecto real.
Estoy intentando acceder para empezar un curso y no se puede, 502 Bad Gateway... :(
Espectacular, hice un return mental al 2015, donde me toco realizar cada uno de los pasos aquí mencionados. El correcto analisis de datos es un proceso complejo cuando tienes empresas con ideas novedosas. Buen video.
Esta clase está magistral
Profesor me parece un excelente vídeo introductorio al mundo de las bases de datos, sin embargo difiero con usted con la etapa de modelo entidad relación. Considero que es una etapa muy importa aunque como usted dice puede realizarse o no; todo dependerá de la complejidad del proyecto porque para principiantes incluyo experto desarrollando base de datos, esta etapa otorga mucha información sobre el flujo de los datos, es decir, como funciona la organización y como están relacionadas las entidades bajo que verbo están relacionadas las entidades.
Entonces es una etapa muy vital
1-si eres principiante
2-si no se entiende muy bien cual es el problema que se quiere resolver porque es algo nuevo o es complejo
3-permite saber desde el principio la cardinal de las entidades
4-el grado de la entidades
5-el mas importante si no se entiende como fluye la información en la empresa se logra con este diagrama entender como están relacionadas las entidades
Interesante! Por supuesto que si. Para empresas que no cambian, que son muy estables está bien.
Yo siento diferir con el que difiere :). En mi opinión y vivencia personal (llevo los últimos 15 años trabajando con bases de datos en grandes proyectos nacionales e internacionales), la única utilidad del modelo E/R es su faceta docente. La cual considero muy importante para cuadrar ideas.
En serio, el último diagrama E/R que tuve que hacer fue en 2002 para un examen en la universidad. Por cierto, me pusieron el modelo de subastas Ebay y me estalló un poco la cabeza en las 4h de examen. En el trabajo, nunca he visto uno ni he tenido que hacer uno. ¡Nunca!. Y trabajo con bases de datos a diario. ¿Quiere decir eso que no se analiza o diseña? No. Quiere decir que no es una herramienta que haya utilizado en mi experiencia, ni nadie con quién haya trabajado, que han sido muchos profesionales de numerosos países.
Luego podríamos hablar de los diagramas de clases, ese gran contendiente supuestamente venido a solventar muchos de los problemas del E/R. Si bien sí que me he encontrado e incluso he credo bastantes a lo largo de mi carrera, tampoco han sido imprescindibles (me solían mirar raro cuando llegaba con uno hecho). Al final, los diseños de datos que he elaborado y que he visto elaborar han comenzado directamente con el modelo relacional y de ahí, salvo detalles de implementación, al RBDMS del tirón. En proyectos medianos, directamente al RDBMS.
En el último proyecto que estuve creamos unas 500 tablas para un negocio del cual no teníamos ni idea cómo funcionaba (ya sabemos algo :)), y no pintamos ni una sola caja/rombo. A día de hoy es un sistema en el que trabajan miles de usuarios en paralelo y no tenemos problemas de datos. Más bien, el diseño de nuestras tablas nos facilita enormemente el día a día resolviendo incidencias en productivo. Ergo, no fue ninguna lastra no haber recurrido a E/R. En el fondo, son conceptos que al final ya llevas por dentro y los aplicas de forma ágil sin necesidad de pintarlos (así lo veo yo).
El otro día leí una encuesta/reflexión, creo que en stack overflow, en la que se hablaba precisamente de la falta de uso real de los diagramas clásicos (UML fundamentalmente) a pesar de habernos grabado a fuego en nuestros periodos formativos cuan importantes eran.
En fin. Para gustos colores y para opiniones personas :). Aunque hay que rendirse ante la evidencia.
@@sandyland170 Hay mucha evidencia de que el diseño conceptual se omite en la gran mayoría de casos.
No hay evidencia de que sea la mejor alternativa. Pues el que la gran mayoría elija omitir este paso no implica que sea lo ideal ni lo mejor.
¿Es necesario? No
¿Es Imprescindible? No
¿Es mejor no omitirlo? Debatible
Lo que yo he visto observando a varios equipos, con distintas metodologías, trabajando con varios clientes, es que en un principio parece una perdida de tiempo empezar con un diseño conceptual; pero a la larga, el soporte y mantenimiento de la base de datos que se empezó diseñando a partir de este punto era mucho más eficiente y las bases de datos en sí eran mucho más robustas.
Sin embargo, desconozco si hay estudios serios sobre el tema, lo mío es una observación empírica y yo soy solo una persona por ende lo que digo no sirve como evidencia incluso habiendo trabajado con más de 40 equipos diferentes y miles de clientes.
Se necesitaría un estudio con más personas, y muchos años vigilando proyectos para sacar una conclusión más certera.
Pero mi opinión es que, personalmente creo que el diseño conceptual está infravalorado, en parte por desconocimiento y en parte por pereza.
Gracias por la información, excelente aporte
Gracias tío Alexis, recién estoy comenzando con el curso
Muchas gracias
al fin youtube hace una buena recomendación, y justo ahora que esa es mi tarea en la universidad.
En la teoría así se modela, en la práctica el cliente pide una monstruosidad a ultimo momento que hace que empieces a duplicar registros hasta que un día tienes tablas duplicadas y si las borras le das en la madre a las reglas de negocio. Lo que enseñan en la escuela es para casos iniciales, muy pocas empresas mantienen una base correctamente relacionada durante las etapas de crecimiento.
En EDteam los primeros meses de la plataforma tuvimos que hacer muchos cambios a ultimo minuto. Pero, jamás dupliqué registros innecesariamente. Porque en ese último minuto tu debes documentar bien (por lo menos el proceso tabular) y ahí ya evitas esos problemas. Ahí entra tu criterio para que en el último minuto se siga haciendo correctamente.
🤔😭
Lo último que menciona es muy importante, yo siempre tengo un dilema con eso, pero hay veces en que, o cumples con los principios de la normalización de bases de datos, o con los requerimientos del cliente (obviamente este último es el más importante, y es allí cuando empiezas a aplicar redundancia en algunas tablas)
Muy buena teoría y ejemplos prácticos
las excepeciones que me tocaron hacer es cuando hago tablas "auditorias" es decir para que la data quede cruda sin dependencia de campos para usarlas posteriormente en un ETL , porque si jalo la data por ejemplo de un detalle de factura. los usuarios por lo general tienden a cambiar información de un producto o eliminarlos.
Por supuesto, hay procesos de desnormalización. Pero ese sería un paso después del diseño de la BD.
Que buen video.
Admiro al tío Alexis
Muy buen video gracias por siempre subir contenido de calidad Edteam
Gracias por el contenido EDteam.
Instructivo, gracias
Gran video, muchas gracias.
Excelente video Freddy.
Buena tio Alexis , gracias por la información
Buen video!
Excelente ... De hecho el modelo de entidad relación es bien, solo hay que practicar
Buen video. Tienes un video sobre cómo hacerlo lo mismo pero en NoSQL??. Saludos Desde Panamá.
Creo que tuve un Deja-Vu ya había visto este vídeo hace como 1 año atrás. ajajajaja
EDTeam expertos en reciclar
@@rubensoto2295jajajaja 😂😂😂😂😂
Muy Buena Info!
Buen video bro ando pensando a comprarle un curso se ven buenos
Compañeros de EDTeam... Que opinan del uso de los ORM ?? Es limpio? El ORM es "el futuro"? Me gustaría saber 🤔
A mí personalmente no me gustan. Si no sabes SQL, úsalos. Si el proyecto es un prototipo, úsalo. Si el proyecto es pequeño, úsalo. Luego vas a tener que ir migrando a escribir los SQL para mejorar el performance y personalización
@@Alexyslozada podrian hacer un video de pros y cons de usar ORM y cuando es recomendable usar y cuando no saludos excelente contenido mucho exito!!! 👍
@@Alexyslozada muchas gracias. Yo tampoco lo prefiero pero lo veo en frameworks muy potentes como "Grails". He visto proyectos enormes que trabajan muy ágiles usando ese framework. De allí nació mi duda 🤔😁👌
@@Mike-df4ze No se necesario hacer un video para eso. Es muy subjetivo el uso de los ORM.
¿Para cuando un EDycupón?, quiero terminar el curso de Java
Soy yo Pero Visual Studio code no te deja instalar el interprete de python y si lo tienes instalado te lo desintala y te dice que lo vuelvas ha instalar
Quisiera la documentación que presenta
Es el mismo video del año pasado solo que le agregaron musica de fondo
👍
amigo podrias compartir el documento word
Gracias por su vídeo. Debería de ir más al grano con su exposición ya que da muchas vueltas para decir una cosa muy simple. Le ánimo a lanzar vídeos en esta línea para ser más didáctico. Gracias por su trabajo. Saludos des de España.
Pensé que iba explicar Álvaro..
Los videos de EdTeam no son los mismos sin Álvaro :(
Anda de vacaciones
En mi opinión tienes razón, pero Alexis también explica bien. Se nota que la gente de EDteam sabe
hola como estas,ese documento lo estas compartiendo??
Mi talon de Aquiles 😂😅😅😅
me salio un anuncio de otra plataforma de cursos en el video
que onda ? : )
Buenas tardes, algún correo para una solicitud
Que es el universo del discurso.
No entendí ni madres 😂
Npi
Excelente explicacion!!