Database Naming Standards

[llong2195]

Is your feature request related to a problem?
I want to introduce the rules for naming entities and columns
This helps everything look clearer
I can monitor the column without having to go into the database or migration file to see it

Describe the solution you'd like

 @Column({ name: 'user_id', type: 'int', unsigned: true, default: () => "'0'" })
 userId: number;`

 @Column({ name: 'user_name', type: 'varchar', nullable: true, length: 512 })
 userName: string;

We have to code and rewrite a lot more, but compared to the benefits it seems great :)

Describe alternatives you've considered
No ideas
Additional context

[vygandas]

@llong2195 great initiative :)
Let's figure this out: why do we need to mix camel and snake cases?
I mean, why this isn't ok 👇🏻 ?

 @Column({ name: 'userName', type: 'varchar', nullable: true, length: 512 })
 userName: string;

[llong2195]

@vygandas No problem, it seems I'm used to working with mix =))

[vygandas]

@llong2195 One more thing - since we do not use automatic sync and rely on migrations, we don't really need to put all these database column parameters. It won't generate types or won't do anything with the database itself. Unless I don't know something myself lol 😅

[llong2195]

@vygandas Just a few important parameters like type, default, comment or name if using mix like me

[llong2195]

@vygandas It's scary to use auto-sync on a production environment 🤣

[vygandas]

@llong2195 so many things could go wrong with auto 🤣

[llong2195]

@vygandas As I described, this just makes it easier for us to monitor the database

[llong2195]

@vygandas Considering the benefits it brings, should we use it?
We have to write more, edit more after each migration update...

[vygandas]

@llong2195 I've started digging a bit to find more info. Take a look at this one https://www.reddit.com/r/laravel/comments/dd8l90/using_snake_case_database_fields_is_making/ . It's for Laravel, but practically, they are discussing the same problem. It is also reflecting the same concern I have regarding different naming conventions and consistency.

[llong2195]

@vygandas Now both are fine.
So which option do you think is suitable for the project?

[vygandas]

@mantaskaveckas @algirdaspaskevicius @naftalimurgor @SpaceHolderdJs, what is your position on this?

[algirdaspaskevicius]

I think that a naming convention should definitely be agreed, however, which one is a question of preference.

Personally, I prefer snake_case naming strategy for database, the first Stack Overflow answer explains why:

https://stackoverflow.com/questions/2878248/postgresql-naming-conventions

Additionally, if I remember correctly, TypeORM will add some additional data like "entity" in the table name, which I personally don't like. I think that database should have a structure, that is acceptable in the SQL environment, because there may be cases where you may interact with the database without ORM.

Finally, there is no need to add column names manually, just use the SnakeNamingStrategy in the ORM config:

import { SnakeNamingStrategy } from 'typeorm-naming-strategies';

And in your ORM config, specify the naming strategy:

const ormConfig = { ...otherConfigData, namingStrategy: new SnakeNamingStrategy() }

Note, that there are other naming strategies as well.

[llong2195]

@vygandas After some research, it seems that when we pre-define the name for the column, there is no need to go through snakeCase().
typeorm-naming-strategies, typeorm
So by using the name: 'snake_case' the speed will look a bit faster

[vygandas]

@llong2195 I think that's overkill. We aim to make this as easy as possible for developers who will take this starter. I'd go with adding a naming strategy and keeping the code thinner.

[algirdaspaskevicius]

Well, defining the naming strategy in ORM config, will take care of the snake_case style in the database for the tables and columns. It will also take care of the snake_case strategy in the migrations. On the other hand, the code part will still have defined camelCase so the data from the database will still be returned as someField while in the database it will look like some_field. So simply defining the naming strategy will take care of everything.

[vygandas]

@algirdaspaskevicius , ok sounds nice. One question regarding mentioned migrations.. Will it convert this https://github.com/cortip/isomera/blob/main/apps/api/src/migrations/1700759687513-user-basic-table.ts#L27 or you'd need to write snake_case in that name field?

[vygandas]

@llong2195 btw, could you ping me on discord please?