Buenas prácticas de nombramiento en JavaScript y bases de datos

Clase 30 de 36 • Curso de NestJS: Persistencia de Datos con TypeORM

Resumen

¿Cómo mantener las buenas prácticas en el nombramiento de bases de datos y código?

El correcto nombramiento de las variables y tablas es fundamental para mantener la coherencia, comprensión y eficacia en la programación y administración de bases de datos. Muchas veces subestimado, el naming es clave para el trabajo colaborativo y la futura escalabilidad del sistema.

¿Cuál es la diferencia entre el naming en JavaScript y bases de datos?

JavaScript: Las variables en JavaScript suelen nombrarse mediante la convención CamelCase, donde cada nueva palabra inicia con mayúscula (por ejemplo, ProductId).
Bases de datos: Aquí las buenas prácticas dictan que no se usen caracteres especiales, incluyendo mayúsculas, para evitar problemas de compatibilidad y facilitar el trabajo en equipo. Un ejemplo sería usar created_at en lugar de CreatedAt.

¿Cómo podemos garantizar buenas prácticas en bases de datos?

Nombres en minúsculas con guiones bajos: Usar una convención consistente como el uso de underscores (_) para separar palabras en nombres de columnas y tablas como product_id.
Tablas en plural: Es común nombrar tablas en plural, como Products, en vez de Product, para expresar que contienen múltiples registros de dicha entidad.
Evitar caracteres especiales: Mantener nombres simples y claros para facilitar futuras consultas y mantenimiento.

¿Cómo personalizar las relaciones de tablas usando TimeWareM?

TimeWareM nos permite personalizar el nombramiento de tablas y columnas mediante el uso de decoradores en entidades de TypeScript:

@Entity('Products')
export class Product {
    @PrimaryGeneratedColumn()
    product_id: number;

    @Column({ name: 'created_at' })
    createdAt: Date;
}

Relaciones uno a uno: Utilizar @JoinColumn para especificar el nombre de la clave foránea, como customer_id.
Relaciones uno a muchos: Se puede añadir el decorador @JoinColumn para establecer claramente el nombre de la columna que lleva la relación.
Relaciones muchos a muchos: Nos permite también determinar el nombre de las tablas ternarias generadas automáticamente, utilizando @JoinTable y especificando nombres para las columnas con @JoinColumn e @InverseJoinColumn.

¿Cuáles son los cuidados a tener al modificar el naming en bases de datos productivas?

Planificación desde el diseño: Pensar en los nombres y normas a usar desde el diseño inicial del sistema evita problemas y migraciones complicadas más adelante.
Migraciones cuidadosas: Cambiar el nombre de tablas o columnas en un ambiente productivo puede conllevar riesgos de pérdida de datos. Es vital coordinar con el equipo de base de datos y aplicar las migraciones con scripts SQL de ser necesario.

¿Qué hacer si la base de datos ya está en producción?

Evaluar riesgos: La modificación del naming en producción requiere un análisis detallado sobre el impacto, especialmente en la integridad de datos y el funcionamiento del sistema.
Consultar con expertos: Es crucial contar con un especialista en bases de datos para determinar la mejor estrategia y reducir riesgos durante las migraciones.

Este tema no solo trata de normas estéticas, sino que impacta en la eficacia, escalabilidad y sostenibilidad del proyecto. Por lo tanto, es vital adoptarlas desde el inicio para facilitar la comunicación entre equipos y evitar futuros errores. Sigue aprendiendo y mejorando tus prácticas para desarrollar sistemas robustos y bien organizados.

Juan Caballero

student•

Apuntes de la clase

Naming o Nombramiento de variables en BD

El naming es una buena practica.
Nombre de una variable tiene que ser representativa
Tiene que ser escrita en camelCase para JavaScript
En BD una buena práctica es no tener caracteres especiales como la mayúscula.
- Debido que si se hace consultas directa a la BD habría que escapar caracteres especiales.
En BD debe ser separadas con _. (snake_case)

Nombre de la tabla debe ser en plural.

//products/entities/product.entity.ts

@Entity({ name: 'products'}) // Nombre de la tabla
@Index(['price', 'stock'])
export class Product{
	
	....

	@CreateDateColumn({
		name: 'created_at', // nombre de la columna en la BD
		type: 'timestamptz',
		default: () => 'CURRENT_TIMESTAMP',
	})
	createdAt: Date;  // Nombre de la variable en el codigo

	@UpdateDateColumn({
    name: 'update_at',
    type: 'timestamptz',
    default: () => 'CURRENT_TIMESTAMP',
  })
  updateAt: Date;
	
	...
}

En los casos de relaciones OneToOne se hace la modificación en la tabla que tenga el decorator @JoinColumn.

//users/entities/user.entity

@OneToOne(() => Customer, (customer) => customer.user, { nullable: true })
  @JoinColumn({ name: 'customer_id' })
  customer: Customer;

En una relación ManyToOne se hace la modificación en quien lleve este decorator.

Se agrega el decorator @JoinColumn

//products/entities/product.entity.ts

@ManyToOne(() => Brand, (brand) => brand.products)
  @JoinColumn({ name: 'brand_id' })
  brand: Brand;

En las tablas muchos a muchos que es manejada por TypeORM se modifica en la entidad que tenga el decorator @JoinTable

Recuerda que en este caso se crea una tabla ternaria.

//products/entities/product.entity.ts

@ManyToMany(() => Category, (category) => category.products)
  @JoinTable({
    name: 'products_categories', //nombre de la tabla que tambien puede ser products_has_categories
    joinColumn: {
      name: 'product_id', // Relación con la entidad donde estas situado.
    },
    inverseJoinColumn: {
      name: 'category_id', // Relación con la otra entidad.
    },
  })
  categories: Category[];

Correr migraciones.
- Debes ser precavido los nombres deben ser ideado desde el diseño.
- Cuando se cambia el nombre de una tabla, crea una nueva tabla no migra los datos.
- Se puede perder datos. Evitar usarlo luego que la BD este en producción.
- Cuando eliminas toda la BD para volverla crear, sin estar en producción, tienes la opción de eliminar las migraciones anteriores, y crear una nueva como estructura inicial.
- En caso de vaciar y volver a crear las tablas en la BD ejecuta
```
npm run migrations:drop
npm run migrations:generate -- init
npm run migrations:run
```

Nicolas Mendoza

student•

1 - En cuanto a migracioens enrtonces lo mejor es no usarlas cuando ya tengo un proyecto en produccion? 2 - Si cambio el nombre e un tabla entonces borra todos los registro de dicha tabla?

Ivan Camilo Buitrago Buitrago

student•

Las migraciones deben manejarse con cuidado en producción. Si cambias el nombre de una tabla, no necesariamente se borrarán todos los registros, pero puedes perder datos si no gestionas adecuadamente la migración. Es mejor planificar el diseño de la base de datos desde el inicio, para evitar problemas en el futuro. Si ya tienes datos en producción, considera realizar migraciones de manera controlada, asegurándote de respaldar la información.

Luis Abdel Rangel Castro

student•

creo que el nombre correcto es: created_at y updated_at

Andres Trujillo

student•

si tienes razón bro, pero suele pasar que aveces se colocan mal lo nombres, me pasa que a veces gracias a la dislexia termino nombrando un campo como "di" en ves de "id".

Ricardo Tribaldos Hernández

student•

Un tip para no tener que hacer drop: Si ejecutan typeorm migration:create -n <nombre-del-refactor>, TypeORM les generará una plantilla de archivo de migración en blanco donde podrían agregar sus Querys 'a mano' como este:

import {MigrationInterface, QueryRunner} from "typeorm";

export class PostRefactoringTIMESTAMP implements MigrationInterface {

    async up(queryRunner: QueryRunner): Promise<void> {
    }

    async down(queryRunner: QueryRunner): Promise<void> {
    }
}

Dentro del método up colocan los querys necesarios para hacer los cambios y dentro de down los querys para revertir los cambios en caso de que sea necesario. Por ejemplo:

import {MigrationInterface, QueryRunner} from "typeorm";

export class PostRefactoringTIMESTAMP implements MigrationInterface {

    async up(queryRunner: QueryRunner): Promise<void> {
        await queryRunner.query(`ALTER TABLE "post" RENAME COLUMN "title" TO "name"`);
    }

    async down(queryRunner: QueryRunner): Promise<void> {
        await queryRunner.query(`ALTER TABLE "post" RENAME COLUMN "name" TO "title"`); // reverts things made in "up" method
    }
}

Andres Trujillo

student•

oh super interesante, gran aporte. Me parece ganador el hecho de poder desde un inicio tener claro el diseño de la BD para no tener que estas pasando por este trabajo, y si, esta parte del curso tuvo que estar desde el incio para haberse ahorrado el tiempo

Carlos Alejandro Hernández Mejía

student•

En TypeORM pueden definir una estrategia para el naming implementando la interfaz NamingStrategyInterface o bien, instalando esta librería que ya lo implementa: https://github.com/tonivj5/typeorm-naming-strategies

Renato Renzo Luna Herrera

student•

shait, este tema debimos verlo al inicio del curso, incluso cuando estábamos aprendiendo fundamentos de NestJs. -.-

David Hilera

student•

Estoy de acuerdo, puse las entitys en plural con tal de que salieran con un buen name al crearse en la base de datos. Ahora no solo debo agregar el name a las entitys si no que también debo de cambiar a singular todas la partes del código donde aparezca la entity.

Carlos Rodríguez

student•

No precisamente, la idea es equivocarnos y corregir que es lo ma's común en la práctica, no todo tiene que ser color de rosas. Gracias a estas coreccioens finales tenemos muchos consejosdel profe a la hora de tener data ya en producción

Carlos Rodríguez

student•

Esto no lo veo muy eficiente. Existe alguna manera de hacer esto en automático en toda la aplicación, alguna utilidad de typeorm?

Jordan Salazar

student•

Esta clase es muy importante, siempre tener en cuenta las buenas prácticas y el buen naming de los campos en la DB.

Andres Prieto

student•

¿Exactamente que hacen los 2 puntos en inverseJoinColumn?

    inverseJoinColumn: {
      name: "category:id"
    }

Brandon Lee Aguero Fernandez

student•

Pensé que no se iba a tocar este tema, perdón querido curso de NestJS te juzgue muy antes.

Edgar Roy Huaman Pumachapi

student•

Las migraciones son excelentes cuando se desarrolla un app de cero. Si va hacer mantenimiento a una app en PRD se tiene que manejar con cuidado. El cambiar el nombre de una entidad padre repercute en la table hija. Lo hago normalmente es hacer un bk de la tabla hija y luego hago un truncate de la hija. Luego corro el migrate para que modifique el nombre de la tabla hija. Posterior a ello traigo la data del bk a la nueva tabla. Haciendo un trabajo conjunto en la db y la migracion si se llega a lo que deseamos.

Miguel Angel Reyes Moreno

student•

Las migraciones son muy útiles pero no son mágicas.

SANDRO SIMON

student•

En JavaScript usamos camel case mientras que en bases de datos, por lo menos en las relacionales, se suele usar snake case.

ZANONI ALFREDO SALAS TOBÓN

student•

Name of product.entity.ts

 @ManyToOne(() => Brand, (brand) => brand.products, { nullable: true })
  @JoinColumn({ name: 'brand_id' })
  brand: Brand

  @ManyToMany(() => Category, (categories) => categories.products, { nullable: true })

  @JoinTable({
    name: "product_categories",
    joinColumn: {
      name: "pk_product",
      referencedColumnName: "id"
    },
    inverseJoinColumn: {
      name: "pk_category",
      referencedColumnName: "id"
    }
  })
  categories: Category[];