No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Curso de PostgreSQL

Curso de PostgreSQL

Oswaldo Rodríguez González

Oswaldo Rodríguez González

Inserción y consulta de datos

16/32
Recursos

Aportes 101

Preguntas 23

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Hay una situación importante sobre las claves foráneas (FK) que se explica en esta clase y me gustaría resaltarla un poco mas:
Primeramente recordar del curso de Fundamentos de BD que a las tablas se les llama “independientes” cuando no tienen FK’s. Del mismo modo una tabla es “dependiente” cuando tiene al menos una FK, es decir, son tablas que dependen de tablas independientes.
Es importante** al momento de crear tablas e insertar datos en ellas**, empezar siempre por las tablas independientes y una vez terminadas seguir con las dependientes

Hay que tener mucho cuidado con las llaves foraneas cuando se deja la opcion de CASCADA cuando se borra o se actualiza. Ayuda a ahorrar tiempo, perr esto puede afectar la transacionalidad en bases grandes.

Holaa! Les dejo un dato SUPER importante, a la hora de escribir, tengan mucho cuidado… si usan mayusculas a la hora de insertar un valor, deben escribirlo asi:
“ID_trayecto” o sin mayusculas id_trayecto.
Lo acalro porque postgre les hara la vida imposible si no ponen comillas en las mayusculas, ya que piensa que es un dato de aplicacion, como un INSERT y no como un dato propio. Les dira por ejemplo que esa columna no existe.

--/////////////////
--16.Inserción y consulta de datos
--////////////////



SELECT * FROM public.estacion;--si data
SELECT * FROM public.pasajero;--reto
SELECT * FROM public.trayecto;--si data
SELECT * FROM public.tren;--si data
SELECT * FROM public.viaje;--reto




--insert "estacion"
INSERT INTO public.estacion (nombre,direccion)
VALUES 
    ('Estación Centro','St 1# 12'),
    ('Estación Norte','St 100# 112')
;

--insert "tren"
INSERT INTO public.tren (capacidad,modelo)
VALUES 
    (100,'Modelo 1'),
    (100,'Modelo 2')
;

--insert "trayecto"
INSERT INTO public.trayecto (tren,estacion,nombre)
VALUES
    (1,1,'Ruta 1');
    (2,2,'Ruta 2');
;

-- RETO
INSERT INTO public.pasajero (nombre,fecha_nacimiento,direccion_residencia)
VALUES
    ('José Ordoñez','1987-1-3','St 100# 12'),
    ('Ángel Quintero','1987-1-12','St 101# 12'),
    ('Rafel Castillo','1977-1-12','St 102# 12'),
;
INSERT INTO public.viaje (id_pasajero,id_trayecto,inicio,fin)
 VALUES
    (1,1,'2019-01-02','2019-01-02'),
    (2,1,'2019-01-03','2019-01-03'),
    (2,2,'2019-01-04','2019-01-04'),
    (3,2,'2019-01-04','2019-01-04')

;
-- Delete sin limit
DELETE FROM public.estacion WHERE estacion.id  =4;
--delete limit
DELETE FROM public.estacion WHERE estacion.id IN
     (
		SELECT id FROM public.estacion 
	  		WHERE estacion.id IN(3,4)
			ORDER BY  estacion.id  
		 	LIMIT 2
	 )
;

-- update sin limit
UPDATE public.estacion
SET id=4, nombre='Estación SUR-OESTE', direccion='St 4# 1'
WHERE estacion.id = 4;

-- update utilizando limit
UPDATE public.estacion
	SET 
		id=4, 
		nombre='Estación SUR-OESTE', 
		direccion='St 4# 1'
	WHERE id IN (
		SELECT estacion.id FROM public.estacion
			WHERE estacion.id in(4)
			ORDER BY estacion.id
			LIMIT 1
	)
;

Añadir algo el delete con limit es algo que vi en el curso de mysql sql y es buena práctica limitar la operación por si algo sale mal, pero en el caso de postgres me parece que es algo contra producente ya que para hacerlo con limit hay que hacerlo a través de una subquery

¿Cómo modificar el tipo de de una columna?


Si el tipo al que quieres cambiar es compatible como por ejemplo de integer => numeric puedes poner:

ALTER TABLE public.<table_name> 
ALTER COLUMN <column_name>
TYPE <new_type>;


Pero si quieres cambiar al un tipo que es incompatible como por ejemplo text => integer y te sale un error como este:

ERROR:  column "model" cannot be cast automatically to type integer
SUGERENCIA:  You might need to specify "USING model::integer".


Entonces pones lo sgte para forzar el cambio de tipo:

ALTER TABLE public.<table_name>
ALTER COLUMN <column_name>
TYPE <new_type>
USING <column_name>::<new_type>;

Me siento totalmente perdido en este curso.

Tanto poder en algo tan sencillo 👨‍💻

Postgresql, es una excelente opción para tener una BD relacional.

Utilizando Python me acostumbré a utilizar las comillas dobles como se utilizan las comillas simples ya que en muy pocos casos hay distinción, pero para la inserción de datos solo se puede hacer con comillas simples en pgadmin, de lo contrario, postgres lo tomara como referencia a una columna.
Espero a alguien le sirva tambien.

Este pgAdmin es enserio muy sencillo-

Clase 16/32: Seguimos con el fondo rojo :c jajaa.

La verdad que PostgreSQL si facilita mucho la vida, es una muy buena opción muy intuitiva.

Me parece que con pg admin no se aprende real mente lo que hace postgres es mejor seguir el curso con la consola

Esta clase me ha costado muchísimo trabajo entenderla, tuve que verla 3 veces y es bastante tediosa, me terminó dando sueño.

Pero ahí vamos… 🐺🥚🥚

me tomo 2 horas lograr resolver un error

-- Agregando datos a la tabla estacion
INSERT INTO public.estacion (nombre, direccion)
VALUES ('Estacion Centro', 'St 1#12');

-- comprobamos los datos de la tabla estacion
SELECT * FROM public.estacion;

-- Agregando datos a la tabla tren
INSERT INTO public.tren (capacidad, modelo)
VALUES (100, 'Modelo 1');

-- comprobamos los datos de la tabla tren
SELECT * FROM public.tren;

-- Para eliminar y despues agregar la columna de nombre a la tabla trayecto
ALTER TABLE public.trayecto DROP COLUMN nombre;
ALTER TABLE public.trayecto ADD nombre character varying(100);

-- Agregando datos a la tabla trayecto
INSERT INTO public.trayecto (id_estacion, id_tren, nombre)
VALUES (1, 1, 'Ruta 1');

-- Comprobamos los datos de la tabla trayecto
SELECT * FROM public.trayecto;

-- Eliminar una tubla de la tabla tren con el id = 1, como esta en cascada se elimino la tuplas que tenian ese id_tren
DELETE FROM public.tren WHERE id = 1;

-- Cambiar la tupla que tenda el id = de la tabla tren
UPDATE public.tren SET id = 1 WHERE id = 2;

Por si alguien le sirve, aquí tienen una lista que hice con el nombre y dirección de algunas estaciones de la red de metro de Madrid.

INSERT INTO public.estacion(
	id_estacion, nombre_estacion, direccion_estacion)
        VALUES ('001','Callo', 'C/ Gran Vía, 39');
        VALUES ('002','Tirso de Molina', 'Plaza de Tirso de Molina');
        VALUES ('003','Pinar de Chamartín', 'Av. Arturo Soria, 330');
	VALUES ('004','Plaza Castilla', 'Plaza de Castilla, 01');
	VALUES ('005','Bambú', 'C/ Príncipe de Vergara, 126');
	VALUES ('006','Chamartín', 'Plaza Chamarín');
	VALUES ('007','Alameda de Osuna', 'Av. Cantabria, 01');
	VALUES ('008','El Capricho', 'C/ Pinos de Osuna, 02');
	VALUES ('009','Canillejas', 'C/ Alcalá, 726');
	VALUES ('010','Hospital Infanta Sofía', 'Av. Europa, 7');
	VALUES ('011','Reyes Católicos', 'Av. Europa, 134');
	VALUES ('012','Baunatal', 'Av. Baunatal, 15');
	VALUES ('013','Nuevos Ministerios', 'Paseo de la Castella, 7')
	VALUES ('014','Colombia', 'Plaza de Colombia, 18');
	VALUES ('015','Pinar del Rey', 'C/ Arturo Soria, 15');

Puedo importar tablas de excel a PostgreSQL?

creo que para mejorar la enseñanza se deberían emplear mas herramientas pedagógicas como pueden ser figuras ya que se complica la explicación con la forma en que se desarrollo esta clase

Información resumida de esta clase
#EstudiantesDePlatzi

  • Scripts es la herramienta de PgAdmin para insertar, modificar y borrar datos

  • Con Insert Script puedo agregar datos a una tabla

  • Con Create Script puedo crear una tabla

  • Con Update Script puedo hacer cambios en la información dentro de una tabla

  • Para insertar, actualizar o eliminar datos en una tabla en PgAdmin, click derecho sobre la tabla, seleccionar script y luego selecciona la accion a ejecutar. PgAdmin abrira un script con el formato de la accion que quieres realizar.
  • Para mostrar los valores de una tabla, click derecho sobre la tabla, seleccionar View/Edit Data y elegir All Rows.
  • Cuando deseamos modificar el tipo de una columna, vamos a propiedades de la tabla, vamos a la pestaña columna y desde alli podemos modificar el tipo de dato. PgAdmin te mostrara solamente tipos de datos compatibles con la columna creada. Para agregar otro tipo de dato, debemos borrar la columna y agregarla de nuevo con el tipo de dato que deseamos.
  • Al borrar o actulaizar datos se actualizan todas las tablas dependientes . Esto se logra mediante la accion Cascade

#✅ Buena e Importante Práctica 💡
.
➡️ Hay que ser muy específicos al utilizar UPDATE y DELETE por lo que una buena práctica es utilizar el ID de lo que se quiere borrar.
.
➡️ Siempre que se utilicen uno de estos comandos es importante poner un LIMIT de acuerdo al número de datos a modificar.

En caso quieran resetear el contador del id autogenerado, les dejo el codigo:

ALTER SEQUENCE <tablename>_<id>_seq RESTART WITH 1
So, for example for the users table it would be:

ALTER SEQUENCE users_id_seq RESTART WITH 1

PostgreSQL hace que todo sea tan amigable!!

Esta clase se entiende mucho más si antes viste el curso de Fundamentos de BBDD. En ese curso, utilizamos un motor grafico de SQL muy similar a Pg Admin, y este se llama MySQL. Es altamente recomendable ver ese curso antes, pues ahi se explica con detalle sobre las FK y las PK, etc.

PD. esta genial el curso, PgAdmin me parece muy sencillo de utilizar

RETO

INSERT INTO public.pasajeros(
	nombre, direccion_residencia, fecha_nacimiento)
	VALUES ('Mario Hidalgo', 'Caracas, Venezuela', '1999-03-01'),
		     ('Ana Granadillo', 'Maracay, Venezuela', '1968-01-27'),
		     ('Jose Hidalgo', 'Valencia, Venezuela', '1961-03-13');
SELECT * FROM public.pasajeros
ORDER BY id ASC 
INSERT INTO public.viaje(
	id_pasajero, id_trayecto, inicio, fin)
	VALUES (2, 3, '14:00', '16:00'),
		     (3, 3, '14:00', '16:00'),
		     (4, 3, '14:00', '16:00');
SELECT * FROM public.viaje
ORDER BY id AS
DELETE FROM public.pasajeros
	WHERE id = 1;
UPDATE public.pasajeros
	SET id=1
	WHERE id = 2;
UPDATE public.pasajeros
	SET id=2
	WHERE id = 3;
UPDATE public.pasajeros
	SET id=3
	WHERE id = 4;

Esta clase me recuerda a los trileros, muevo aquí toco allí, pongo allá- ¿No hay una forma más fácil de explicar?. He tenido que repasar la clase 3 veces. A lo mejor el problema lo tengo yo.

Excelente curso!!

#### **Ventajas de** `ON DELETE NO ACTION`: * Garantiza que no elimines registros de la tabla padre si hay dependencias en la tabla hija, protegiendo los datos relacionados. * Te da **control total** sobre las eliminaciones, ya que tendrás que manejar manualmente cómo y cuándo eliminar los registros. #### **Desventajas**: * **Mayor complejidad** en la lógica de tu aplicación, ya que debes asegurarte de eliminar los registros hijos manualmente antes de poder eliminar un registro en la tabla padre. * Si no manejas bien este proceso, puedes terminar con registros que ya no son necesarios pero que no se eliminan (aunque no estarán huérfanos).
# Eliminación segura en SQL Para realizar eliminaciones seguras en la base de datos, siempre es recomendable **verificar** la información antes de proceder con la eliminación. Este proceso implica hacer una consulta previa (con `SELECT`) para asegurarnos de que el registro que queremos eliminar es el correcto. ### Pasos para una eliminación segura: 1. **Verificar los datos** con un `SELECT`: Antes de proceder con una eliminación, ejecutamos un `SELECT` para confirmar que los registros que vamos a eliminar son los correctos. Esto ayuda a evitar errores accidentales:`SELECT * FROM` public.estaciones `WHERE estaciones.estacion_id = 3`; Asegúrate de revisar el resultado de la consulta para verificar que el registro que deseas eliminar es el correcto. 2. **Realizar la eliminación**: Una vez confirmados los datos, procedemos con la eliminación del registro. Usa la instrucción `DELETE` para eliminar el registro específico:`DELETE FROM` public.estaciones `WHERE estaciones.estacion_id = 3`; Esta sentencia elimina el registro cuyo `estacion_id` es 3. 3. **Verificar que la eliminación fue exitosa**: Después de eliminar el registro, realizamos otra consulta `SELECT` para asegurarnos de que el registro ha sido eliminado correctamente: `SELECT * FROM public.estaciones;`
#### **Ventajas de** `ON DELETE CASCADE`: * **Automatiza la eliminación** de los registros dependientes, evitando que queden registros huérfanos. * Simplifica la lógica de eliminación en tu aplicación. #### **Desventajas**: * Puede ser **peligroso** si eliminas registros por error, ya que la eliminación en cascada puede llevar a la pérdida de muchos datos relacionados. * Menos **control** sobre el proceso de eliminación, ya que la eliminación de los registros relacionados ocurre automáticamente.
A continuación se explica cómo realizar inserciones y consultas de datos en PostgreSQL, con ejemplos prácticos. ## **Inserción de Datos** ### **Sintaxis Básica** Para insertar datos en una tabla, utiliza el comando `INSERT INTO`. INSERT INTO nombre\_tabla (columna1, columna2, columna3) VALUES (valor1, valor2, valor3); ### **Ejemplo Práctico** #### Crear la Tabla CREATE TABLE empleados ( id\_empleado SERIAL PRIMARY KEY, nombre VARCHAR(50) NOT NULL, cargo VARCHAR(50), salario NUMERIC(10, 2) ); #### Insertar Datos INSERT INTO empleados (nombre, cargo, salario) VALUES ('Juan Pérez', 'Analista', 2500.50), ('Ana Gómez', 'Gerente', 5000.00), ('Carlos Ruiz', 'Asistente', 1800.75); ## **Consulta de Datos** ### **Sintaxis Básica** Para consultar datos, utiliza el comando `SELECT`. SELECT columna1, columna2 FROM nombre\_tabla WHERE condición; ### **Tipos de Consultas** #### 1. **Consulta de Todos los Registros** SELECT \* FROM empleados; **Resultado**: id\_empleadonombrecargosalario1Juan PérezAnalista2500.502Ana GómezGerente5000.003Carlos RuizAsistente1800.75 #### 2. **Consulta con Filtros** Consulta empleados con salario mayor a 2000. SELECT nombre, cargo, salario FROM empleados WHERE salario > 2000; **Resultado**: nombrecargosalarioJuan PérezAnalista2500.50Ana GómezGerente5000.00 #### 3. **Consulta Ordenada** Ordenar los empleados por salario de manera descendente. SELECT nombre, cargo, salario FROM empleados ORDER BY salario DESC; #### 4. **Consulta con Límites** Obtener los 2 empleados con mayor salario. SELECT nombre, cargo, salario FROM empleados ORDER BY salario DESC LIMIT 2; #### 5. **Consulta con Agregación** Calcular el salario promedio de los empleados. SELECT AVG(salario) AS salario\_promedio FROM empleados; **Resultado**: salario\_promedio3100.42 #### 6. **Consulta con Funciones de Grupo** Número de empleados por cargo. SELECT cargo, COUNT(\*) AS cantidad\_empleados FROM empleados GROUP BY cargo; **Resultado**: cargocantidad\_empleadosAnalista1Gerente1Asistente1 ## **Combinar Inserción y Consulta** ### Insertar y consultar de inmediato WITH nuevo\_empleado AS ( INSERT INTO empleados (nombre, cargo, salario) VALUES ('Laura Sánchez', 'Supervisora', 3000.00) RETURNING id\_empleado, nombre, cargo, salario ) SELECT \* FROM nuevo\_empleado; ## **Buenas Prácticas** 1. **Verificar las restricciones antes de insertar datos**: Define claves primarias, claves foráneas, y restricciones únicas. 2. **Utilizar transacciones para operaciones críticas**: Asegura que las inserciones o actualizaciones sean atómicas. 3. **Evitar consultas sin filtros en tablas grandes**: Usa `WHERE` y `LIMIT` para optimizar el rendimiento. 4. **Utilizar índices para mejorar las consultas**: Especialmente en columnas utilizadas en filtros o uniones.

Muy buenas las explicaciones. Por ahora vengo bien encarrilado 😜

Hola! aqui mi ejercicio de viajes agregando la funcion NOW() para “rellenar” los campos inicio y fin.

2 pasajeros

3 trenes

2 estaciones

Luego para cada pasajero inserté un viaje y utilicé la funcion NOW() para simular el inicio (fin = inicio)

Finalmente actualicé el campo fin de cada viaje con la funcion NOW()

Lo siguiente sería calcular el tiempo que dura cada viaje.

Añadí dos viajeros y les hice su registro de viajes, no tuve ningún problema con actualizar sus datos ni de los datos del viajero ni de Id, de echo cambié todos los datos del viajero y me funcionó de maravilla.

A la 1:00 A.M. estudiando esto, me fascina, aunque es malo, buenas noches… o mañanas?. Bueno, muy buen tutorial de este chico, directo al grano, gracias 😃

ya entiendo mejor sql

Hay alguna otra herramienta gráfica para hacer queries?

A mi el pgAdmin se me bloquea.

No se si el la tabla trayecto tiene mucho sentido si es que no dice a donde va sino de donde sale. Una vez creada la tabla ‘Estaciones’ (si, en plural) se deberia anadir a la dependiente ‘Trayectos’ la columna id_destino (foreign key de id_estaciones).
Es una buena practica?

Se tiene dos tabla a y b. y tienen los atributos a.id y b.id y b.id_a que referencia al id de la tabla a. Debemos tomar en cuenta que no se pueden insertar id en el registros en la tabla b.id_a que no existan el tabla a.

Configurar una tabla con foreign key en cascada permite que al borrar o actualizar datos en la tabla de origen tambien se borre o actualice los datos en la tabla con el foreign key

Yo trabajo con Ubuntu 18.04 directamente en terminal. He creado un user (transport_manager) con los privileges de ‘update’,‘insert’ y
’select’ pero aún así no podía hacer insert ya que tengo los campos de primary key de una tabla con ‘SERIAL’. Hay que añadir también los privileges ‘update’ y ‘select’ de la table ‘sequence’ asociada, de cada tabla que lo tenga, a este user (transport_manager) para poder hacer insert.

Si la tabla es ‘train’ y quiero dar privileges a la tabla sequence de train para el user transport_manager (las tablas sequence no permiten añadir privileges de insert):
trasnport=# set role postgres;
transpot=# grant update, select on train_id_sequence_id to transport_manager;

Fijar el valor de una tabla sequence (la de mi tabla ‘train’ es ‘train_id_sequence_id’) para que empiece por 0:
alter sequence train_id_sequence_id restart with 0;

Si tras hacer un insert en la tabla train ya existe un elemento con el id que le asigna la tabla sequence de forma automática, el insert no se producirá.

Usar **CASCADE** como acción en las **Foreign Keys** en bases de datos de producción depende del caso de uso y del diseño del proyecto, pero en general, en proyectos grandes y críticos, es una decisión que se toma con mucho cuidado. A continuación, te detallo las principales consideraciones y prácticas: ### **Cuándo se puede usar CASCADE:** 1. **Simplicidad y coherencia:** * Si tienes un modelo donde la eliminación o actualización de registros debe propagarse automáticamente a las tablas relacionadas (por ejemplo, en datos que tienen una relación lógica muy fuerte). * Ejemplo: Un sistema de órdenes donde si eliminas un cliente, quieres borrar automáticamente todas sus órdenes asociadas. 2. **Mantenimiento mínimo:** * Si quieres delegar a la base de datos la responsabilidad de mantener la integridad referencial sin necesidad de escribir lógica adicional en la capa de aplicación. ### **Cuándo evitar CASCADE en producción:** 1. **Riesgo de eliminación accidental:** * En sistemas grandes, un comando como `DELETE` o un cambio en la tabla padre podría desencadenar eliminaciones masivas en las tablas dependientes, causando una pérdida de datos irreversible. 2. **Impacto en el rendimiento:** * Si tienes tablas relacionadas con millones de registros, una acción en cascada podría bloquear consultas y causar problemas de rendimiento en la base de datos. 3. **Falta de control:** * En proyectos críticos, a menudo es mejor que la capa de aplicación maneje las actualizaciones o eliminaciones de forma explícita para mantener control sobre lo que ocurre con los datos. 4. **Auditoría y trazabilidad:** * Si necesitas un registro detallado de qué datos se eliminaron o actualizaron, es preferible manejarlo manualmente en la capa de aplicación o con triggers controlados. ### **Prácticas comunes en proyectos grandes:** 1. **Manejo explícito en la capa de aplicación:** * Se prefieren procedimientos almacenados (stored procedures) o lógica en la aplicación para manejar actualizaciones o eliminaciones. * Esto te permite validar condiciones antes de realizar cambios en cascada. 2. **Soft Deletes:** * En lugar de eliminar registros físicamente, se utiliza una columna como `is_deleted` o `deleted_at` para marcarlos como eliminados. Esto evita eliminaciones accidentales y permite revertir cambios si es necesario. 3. **Triggers personalizados:** * Los triggers pueden usarse en lugar de **CASCADE** para tener más control sobre lo que ocurre con las tablas relacionadas. Estos son útiles para auditar o limitar el impacto de cambios. 4. **Planificación de transacciones:** * Se escriben transacciones en la aplicación o en procedimientos almacenados para asegurar que las dependencias se manejan de forma controlada. ### **Conclusión:** En proyectos grandes y críticos, generalmente se evita el uso indiscriminado de **CASCADE** en producción debido a los riesgos de control, rendimiento y auditoría. Sin embargo, puede ser útil en sistemas más simples o en situaciones donde la relación entre las tablas es estrecha y bien definida. Lo ideal es evaluar cuidadosamente el diseño y las necesidades del sistema, documentar el comportamiento esperado y probar exhaustivamente los casos de uso antes de decidir.
![](https://static.platzi.com/media/user_upload/image-c07de3d7-3006-4b63-81a0-dccf4b1e5c8a.jpg) Hola, alguien sabe lo siguiente? si borro id\_estacion no me deja ingresar la informacion, pero si dejo el item id\_estacion ,si me deja.....el profesor no hizo esto...alguien sabria porque? muchas gracias
INSERT INTO public.Estación (nombre, dirección) VALUES
    ('Estación Central 1', 'Calle 123, Ciudad A'),
    ('Estación Oliveros', 'Avenida XYZ, Ciudad B'),
    ('Estación Rafael pombo', 'Carrera 456, Ciudad C'),
    ('Estación Estrella', 'Avenida Principal, Ciudad X'),
    ('Estación Volivar', 'Calle Secundaria, Ciudad Y'),
    ('Estación Capital', 'Carretera 789, Ciudad Z');
	

INSERT INTO public.Tren (modelo, capacidad) VALUES
    ('Tren A1', 150),
    ('Tren B2', 200),
    ('Tren C3', 180),
    ('Tren X48', 220),
    ('Tren Y49', 190),
    ('Tren Z50', 210);
	
	-- Insertar datos en la tabla Trayecto
INSERT INTO public.Trayecto (id_tren, id_estacion_origen, id_estacion_destino) VALUES
    (1, 2, 3),
    (2, 1, 4),
    (3, 3, 2),
    (48, 1, 5),
    (49, 4, 3),
    (50, 5, 2);
	
INSERT INTO public.Trayecto (id_tren, id_estacion_origen, id_estacion_destino) VALUES
    -- Trayectos para el Tren A1
    (1, 1, 2), (1, 2, 3), (1, 3, 4), (1, 4, 5), (1, 5, 6),
    -- Trayectos para el Tren B2
    (2, 2, 3), (2, 3, 4), (2, 4, 5), (2, 5, 6), (2, 6, 1),
    -- Trayectos para el Tren C3
    (3, 3, 4), (3, 4, 5), (3, 5, 6), (3, 6, 1), (3, 1, 2),
    -- Trayectos para el Tren X48
    (4, 4, 5), (4, 5, 6), (4, 6, 1), (4, 1, 2), (4, 2, 3),
    -- Trayectos para el Tren Y49
    (5, 5, 6), (5, 6, 1), (5, 1, 2), (5, 2, 3), (5, 3, 4),
    -- Trayectos para el Tren Z50
    (6, 6, 1), (6, 1, 2), (6, 2, 3), (6, 3, 4), (6, 4, 5),
    (1, 3, 5), (2, 4, 6), (3, 5, 1), (4, 6, 2), (5, 1, 3),
    (6, 2, 4), (1, 4, 6), (2, 5, 1), (3, 6, 2), (4, 1, 3);

Yo puse un biginit en la columna de capacidad

Desde que comenzó el curso me he estado preguntando si no tiene mas sentido que la relación Trayecto fuese una relación ternaria y reflexiva. Es decir 2 instancias de estacion y un tren se relacionan y forman un trayecto. Esto porque una trayecto tiene un principio y un fin (el tren 1 recorre el trayecto X desde la estacion A hasta la estacion B) id\_Trayecto (PK) id\_Estacion\_Salida (PK y FK) id\_Estacion\_Llegada (PK y FK) id\_Tren (PK y FK) Nombre

genial…!

**Insertaremos valores a la tabla tren: Click derecho a la tabla tren, Scripts, INSERT Script** `INSERT INTO public.tren` `( modelo, capacidad) ` `VALUES ('Modelo 2', 150);` **Actualizaremos los trayectos: Click derecho a la tabla trayecto, Scripts, INSERT Script, \*omitimos el primer id** `INSERT INTO public.trayecto( ` `id_estacion, id_tren, nombre) ` `VALUES (1,2,'Ruta 2');`
Tengo un problema al crear un nuevo trayecto. Me aparece el error siguiente pero luego si fuerzo el id dentro del query no sucede. entiendo que la configuracion esta forzando un id que siempre crece pero no se como arreglarlo```js INSERT INTO public.trayecto( id_estacion, id_tren, nombre) VALUES (1,2, 'Ruta 2' ); ```El error: ERROR: inserción o actualización en la tabla «trayecto» viola la llave foránea «trayecto\_estacion\_fkey» DETAIL: La llave (id)=(17) no está presente en la tabla «estacion». SQL state: 23503

Ví la clase 3 veces y no entiendo por qué desde el test enlazan a ésta clase para responder correctamente al cuestionamiento “relación entre objetos tangibles normalmente se traduce en” … He hecho varios cursos y siempre sueltan alguna pregunta en el test formulada de la peor manera

-- Agregar datos a la tabla "tren"
INSERT INTO tren (modelo, capacidad)
VALUES ('TrenXpress', 200),
       ('RápidoRail', 150),
       ('ComfyTransit', 120);

-- Agregar datos a la tabla "proyecto"
INSERT INTO proyecto (id_tren, id_estacion, nombre)
VALUES (1, 3, 'Proyecto A'),
       (2, 1, 'Proyecto B'),
       (3, 2, 'Proyecto C');

gracias

Creamos pasajeros:
INSERT INTO passengers(name, address, age) VALUES(‘Pasajero 1’, ‘St 5 #145’, ‘1980-08-23’);

INSERT INTO passengers(name, address, age) VALUES(‘Pasajero 2’, ‘St 123 #1565’, ‘1993-02-03’);

Actualizamos la ruta:
UPDATE routes SET id=1 where id=2;

Cremos otro tren:
INSERT INTO trains(model, capacity) VALUES(‘Modelo 3’, 120);

Creamos otra ruta:
INSERT INTO routes(station_id, train_id, name) VALUES(2,3,‘Ruta 1 de la estación 2’);

Creamos viajes:
INSERT INTO travels(passenger_id, route_id, ini_hour, end_hour) VALUES(1, 1, ‘07:00’, ‘07:20’);

INSERT INTO travels(passenger_id, route_id, ini_hour, end_hour) VALUES(2, 3, ‘18:00’, ‘19:30’);

transport=# select * from stations;
id | name | address
----±----------------±------------
1 | Estación Centro | St 1#12
2 | Estación Norte | St 100 #112
(2 rows)

transport=# select * from trains;
id | model | capacity
----±---------±---------
1 | Modelo 2 | 150
3 | Modelo 3 | 120
(2 rows)

transport=# select * from routes;
id | station_id | train_id | name
----±-----------±---------±------------------------
1 | 1 | 1 | Ruta 2
3 | 2 | 3 | Ruta 1 de la estación 2
(2 rows)

transport=# select * from passengers;
id | name | address | age
----±-----------±-------------±-----------
1 | Pasajero 1 | St 5 #145 | 1980-08-23
2 | Pasajero 2 | St 123 #1565 | 1993-02-03
(2 rows)

transport=# select * from travels;
id | passenger_id | route_id | ini_hour | end_hour
----±-------------±---------±---------±---------
2 | 1 | 1 | 07:00:00 | 07:20:00
4 | 2 | 3 | 18:00:00 | 19:30:00
(2 rows)

transport=#

Un Ejemplo de creación de los datos de un pasajero:

Una buena practica con las actualizaciones y borrados, es primero hacer la consulta, en ese sentido se tiene el estimado de la cantidad de filas actualizadas y/o borradas.

INSERT INTO public.estacion(nombre, direccion)
VALUES(‘Estacion Norte’,‘St 1#12’);

SELECT * FROM estacion;

UPDATE estacion set direccion=‘100#12’ where id=2;

insert into tren(modelo, capacidad)
values(‘Modelo 2’,150);

SELECT * FROM tren;

INSERT INTO public.trayecto(
id_estacion, id_tren, nombre)
VALUES (1, 1, ‘Ruta 1’);

PostgreSQL es un buen motor aunque al principio un poco complicado, siguen sin gustarme algunas cosas si las comparo con otras, por ejemplo, otras bases de datos me va mas rapido la interfaz gráfica (en este caso pgadmin), por otro lado, hay muchas cosas que no te deja hacer a no ser de que borres y lo vuelvas a crear o por ejemplo el hecho de que debes escribir entre comillas un valor que empiece por mayúsculas.

por que no se puede alterar la table en el tipo de dato en vez de drop y luego create de nuevo?

Se debe tener en cuenta los delete que se haga en una de las tablas, ya que si borro alguno de los datos, se verá afectada la forma en que venia trabajando.
Debido a la configuración de cascada, se actualizan los datos de las tablas que se encuentren con llaves foráneas, si genero cambios en una de las tablas asociada a estás.

Excelente clase.

Excelente la recomendación de realizar eliminaciones lógicas, pero…
¿Está bien no borrar ningún dato de la base de datos?

Se puede responder esta pregunta con una necesidad de todo sistema (pues los recursos ilimitados no existen, dado que siempre está asociado a un costo): La gestión del uso de disco.

La gestión de uso disco requerirá que el sistema tenga algún mecanismo de limpieza, eliminando la data antigua y dejando espacio para la nueva (esto requerirá un mantenimiento a la BD, como la desfragmentación y actualización de estadísticas, recomiendo el curso de Optimización de BD). Solo de esta manera aseguramos que el recurso de uso de disco no se agote.

¿Y qué pasaría si la información histórica es indispensable?
Por ejemplo, en bancos se requieren datos de al menos 5 años atrás para verificar o validar la trazabilidad de las transacciones financieras.
Normalmente se usan otros sistemas para guardar la data histórica, quizás un Datawarehouse (diferente a los sistemas de operación o gestión de operación, donde la transaccionalidad es alta).

la interfaz a vece es algo complicada, pero a la ves también sencilla

Que buen ejemplo el que tiro el profe para las relaciones de tablas

Importante acotar que la modificación de un tipo de dato en una columna se puede realizar solamente cuando la tabla está vacía, sino, podría generar conflicto de compatibilidad con los datos ya cargados para esa columna.

Para asegurarme que estoy insertando un ID referido existente cuando usamos foreing key.
Puedo hacer cosas como:
INSERT INTO bar (description, foo_id) VALUES ( ‘testing’, (SELECT id from foo WHERE type=‘blue’) ).
Donde:
La columna “foo_id” de la tabla “bar” es la columna local (la que tiene la foreign key).
La tabla referida es “foo” y la columna referida es “id”.
Fuente:
https://dba.stackexchange.com/questions/46410/how-do-i-insert-a-row-which-contains-a-foreign-key/46415

Hola!
El planteamiento que hice para mi proyecto tiene peculiaridades interesantes que les quiero compartir. Basado en la red de transporte colectivo de trenes que hay en Ciudad de México, di de alta algunos ejemplos de trayectos, que se denominan líneas, los cuales son rutas estaticas que siguen los trenes en su día a día. Estas líneas son bidireccionales, por lo que, el origen y el destino dependiendo de su orientación, hacen que una línea en realidad sean dos.
Ahora, además de eso, existen estaciones que comunican líneas entre si, lo que se conoce como trasbordos. Y como esas estaciones ocurren de igual forma en líneas bidireccionales, pues su existencia en la definición de las líneas es mayor a 2 en todos los casos.
Para darle orden a las líneas, ya que no use IDs numéricos, sino de tipo UUID, agregué un campo de ordenamiento que da tambien el sentido de las estaciones.

Por ejemplo, las estaciones en una línea, se ven como sigue:

Mientras que, para la misma línea pero en sentido contrario, se ven asi:

Nótese que existe una condición en la consulta que ordena no por ID, sino por el valor asignado a la linea con respecto a su continuidad y su sentido.

Y por ejemplo, las estaciones de trasbordo lucen de la siguiente manera:

El proyecto esta siendo muy ilustrativo, sugiero encarecidamente que se realice bajo planteamientos propios y se piense en un problema a resolver. Creo que eso da mayor panorama y una practica mas consciente y profunda.

Saludos!

Este curso es un buen F5 de los demás cursos de SQL.

En caso de que quieran o necesiten varios registros pasa sus tablas, les recomiendo esta pagina la cual genera hasta 10.000 registros de cualquier ámbito.
https://mockaroo.com/

Tabla Viaje

tabla pasajeros




La facilidad que nos da SQL para insertar datos y consultas

la magia del update y delete cascade

La verdad ahora que estoy aprendiendo SQL, no veo tan complicado esto, todo es muy intuitivo

super bien explicado me, muy bueno le contenido los vídeos son cortos pero se entiende lo que explica

Aqui algunas insersiones

INSERT INTO public.pasajero(
	nombre, direccion_residencia, fecha_nacimiento)
	VALUES ('Alejandro Mota', 'EDO Mex, Cusil V' , '1985-06-26');
	select * from public.pasajero;```

Listo!

Alguien mas siente que no tiene sentido que un trayecto tenga como atributo una sola estacion? Un trayecto no se deberia componer de una estacion inicial y otra final?

aqui

Para realizar un insert en nuestras tablas desde PgAdmin hacemos clic derecho en la tabla->Script->Insert Scritp

Sí tenemos un ID serial, cuando tengamos insert podemos quitarlo del script insert porque el mismo motor de base de datos se encarga de asignar este número

Para modificar un tipo de dato en una columna se debe tomar en cuenta que el motor de B.D nos dejará hacer el cambio por un tipo de dato equivalente. Sí se desea cambiar el tipo de dato por my distinto seguramente se tendrá que hacer un drop column y luego un add column

Sí sé una acción como: borrar, actualizar en una registro que está en la tabla a y la llave primaria de esa misma se referencia en otra tabla b, y tenemos la opción ON CASCADE está acción actualizará el registro que está relacionado por medio del id

Increible clase

Podemos consultar datos con: View/Edit Data

Insertar datos a través de pgAdmin: Selección de la tabla + clic derecho / Scripts / INSERT Script

Para modificar un tipo de dato: En Properties borramos la columna y la creamos de nuevo.

Borrar y añadir una columna con Queries: ALTER TABLE ... DROP COLUMN / ALTER TABLE ... ADD COLUMN

Borrar un dato pgAdmin: Scripts / DELETE Script

Borran con Queries: DELETE FROM ... WHERE 'condición'

Cambiar un dato: Scripts / UPDATE Script

Interesante clase!

Es muy fácil de manejar con la interfaz, excelente

Hasta ahora todo super!!

Es muy sencillo de utilizar PostgreSQL con la interfaz, aunque también el manejo con consola es buena

Informacion lista!

![](