Alias

SQL & Hibernate
Nivel 3 , Lección 1
Disponible

Cambiar los nombres de las columnas

También tenemos que lidiar con los nombres de las columnas. De lo contrario, repetimos los nombres name e id, pero contienen datos diferentes. Por otro lado, está la primera columna id y la columna employee_id, que contienen los mismos datos.

Escribamos una consulta, donde solo habrá las columnas necesarias, y también cambiaremos el nombre de las columnas con los mismos nombres:

SELECT task.id AS task_id, task.name AS task_desc, task.deadline AS deadline, emploee.id AS emploee_id, emploee.name AS emp_name, emploee.occupation AS emp_occupation FROM employee, task WHERE emploee.id = task.emploee_id 

Y el resultado de esta consulta:

ID_tarea task_desc fecha límite empleado_id nombre_emp ocupacion_emp
1 Arreglar un error en la interfaz 2022-06-01 1 ivanov ivan Programador
2 Arreglar un error en el backend 2022-06-15 2 petrov petr Programador
7 Disfruta la vida (NULO) 4 Rabinovich Moisha Director
3 comprar cafe 2022-07-01 5 Anastasia Kirienko Gerente de oficina
4 comprar cafe 2022-08-01 5 Anastasia Kirienko Gerente de oficina
5 comprar cafe 2022-09-01 5 Anastasia Kirienko Gerente de oficina
8 Disfruta la vida (NULO) 6 Vaska gato

Genial, el problema con los nombres de columna incomprensibles se ha solucionado con éxito. La consulta se ha vuelto un poco larga, pero todo está claro en la tabla resultante. Y sin columnas adicionales.

Alias ​​de tabla

A veces, los nombres de las tablas son demasiado largos y ocupan mucho espacio en la consulta. Por lo tanto, los creadores de SQL, para mejorar la legibilidad, como en el caso de las columnas, ofrecieron la posibilidad de especificar alias de tablas.

La forma general de los alias (alias de tabla) es la siguiente:

FROM table1 alias1, table2 alias2

Reescribamos nuestra consulta anterior con alias cortos:

SELECT t.id AS task_id, t.name AS task_desc, t.deadline AS deadline, e.id AS emploee_id, e.name AS emp_name, e.occupation AS emp_occupation  FROM employee e, task t  WHERE e.id = t.emploee_id 

La legibilidad ha disminuido ligeramente, pero esto se debe a que los nombres de las tablas eran inicialmente simples y claros. Bien podría ser así:

SELECT task.id AS task_id, task.name AS task_desc, task.deadline AS deadline, emploee.id AS emploee_id, emploee.name AS emp_name, emploee.occupation AS emp_occupation  FROM  Microsoft_it_department_employee employee, Year2022_priority_task task WHERE emploee.id = task.emploee_id 

Y en este caso, los alias ya sirven, ¿no? ;)

Clave primaria

Y una información más importante sobre las tablas. ¿Recuerdas que teníamos una columna employee_id en la tabla de tareas? Con él, hicimos referencia a la identificación del empleado de la tabla de empleados.

Si queremos hacer referencia de una tabla a las filas de otra tabla, entonces la tabla a la que se hace referencia debe tener una columna con una ID, que también se denomina clave principal: PRIMARY KEY .

La mayoría de las veces, esta es una columna especialmente agregada cuyo tipo de valor es int . Al agregar registros a una tabla, SQL establece automáticamente el valor de esta columna.

Entonces muchas cosas están ligadas a estas teclas:

  • vincular diferentes tablas entre sí;
  • búsqueda rápida y filtrado por id;
  • integridad de los datos en la base de datos (sin referencias a una identificación inexistente);
  • eliminar datos a los que nadie hace referencia;
  • y muchos muchos otros.

Por cierto, hay situaciones en las que una tabla tiene la llamada clave natural . Esto es cuando hay una columna cuyo contenido implica unicidad. Por ejemplo, decidimos agregar a la tabla de empleados:

  • El orden de su llegada a la empresa;
  • Número de impuesto;
  • Número y serie del pasaporte.

A veces, los diseñadores de bases de datos usan una clave natural como clave principal, pero la mayoría de las veces se usan por separado. Después de todo, los registros se pueden eliminar, cambiar y similares.

¿Supongo que lees historias en Internet cuando los alguaciles cuelgan deudas de su homónimo completo en una persona? Esto solo está relacionado con el concepto de una clave única. Es muy conveniente para los bancos y alguaciles buscar a una persona por nombre completo y año de nacimiento. Y en el 99% de los casos esto es suficiente para identificar a una persona.

Pero el <1% restante son homónimos completos, con el mismo año de nacimiento. En la vida de cada uno de nosotros, lo más probable es que no existan tales personas, pero a escala nacional, las hay. En general, si está escribiendo software o diseñando una base de datos, es útil saber que este también puede ser el caso.

Comentarios
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION