[TIL]タイプORMコンセプト

TypeORM

JavaScriptデータベースをサポートするすべてのアプリケーションで
コードオブジェクトをデータベース言語(SQL)と一致させるツール.
つまり、作成したオブジェクトに基づいてSQLを自動的に生成して同期します.

ORM

object関係マッピングの略語
オブジェクト(クラス)をテーブルシステム(RDBMS)に関連付ける.
オブジェクト向けプログラミング(java、C、javascriptなど)はクラス方式を採用
一方,リレーショナル・データベースはテーブル方式を採用している.
使用するコードの種類も異なります
この点では、オブジェクトモデルとリレーショナルモデルの間に不一致があります.
これらの不一致な相互関係に基づいてSQLを自動的に生成し、それを解決するのがORMです.
ORM開発では,オブジェクトやデートベースの修正を柔軟に扱うことができる.
オブジェクト向けプログラミングの観点から,リレーショナル・データベースの制限を受けずにオブジェクトのように表現しやすく使用できる.

長所

オブジェクト向けコードより直感的に

CRUDの長いSQL文

を記述する必要はありません.

の各モデルごとにコードを記述し、可読性が高い

プログラム化されたSQLではなくオブジェクト化されたSQLによって生産性が向上

により、再利用とメンテナンスの利便性が向上

マッピング情報は明確である.

ERPへの依存性を低減

ORMは独立して作成され、再利用可能です.

DBMSへの依存性の低減

ほとんどのORMはデータベース

に依存しない

の開発者はオブジェクトに集中しており、DBMSを交換する極端な作業にもリスクと時間がかかりません.

は実施方法に依存せず、多くのソリューションからデータ型まで有効である.
(*依存関係:

プログラム構造がデータ構造の影響を受けることを示す

短所

完璧なORMは実現しにくい

は使いやすいが、初期設計時には慎重にしなければならない.

プロジェクトは複雑度が高く、難易度も

高い.

エラー実装時に速度が低下し、重大時にコンシステンシがクラッシュ

プログラム(特定タスクのプログラムの一部)が多いシステムでは,ORMのオブジェクト指向の利点を利用することは困難である.

すでに多くのプロセスが存在するシステムでは、データベース言語をオブジェクトに再変換する必要があり、生産性が低下することがよくあります.

TypeORMは次のように使用されます.
それをエクスポートし、他のts拡張子apiファイルからインポートして使用します.
entityファイルは他のtsファイルとともにapiフォルダに格納されます
もう一人@Entityというやつがいます.
この書類も~.entity.tsと明示されています
Entityについて説明しましょう.

Entity

うん.エンティティ存在する
TypeORM Docsより
Entityは、データベース・テーブル(またはMongoDBを使用した場合の集合)にマッピングされるクラスです.
Entityを作成するには、新しいクラスを定義して@Entity()とマークします.

import {Entity, PrimaryGeneratedColumn, Column} from "typeorm";

@Entity()
export class User {

    @PrimaryGeneratedColumn()
    id: number;

    @Column()
    firstName: string;

    @Column()
    lastName: string;

    @Column()
    isActive: boolean;

}

このように作成されたクラス
1.列の内容のタイプを指定します.
2.@Column列で表記
では、データベースのtableのカラムが生成される原理です.
このEntityのタイプはもちろん@Columnだけではありません
誰もが確認してください.

1. @PrimaryColumn()

すべてのタイプの値を含むPrimary列を作成します.
カラムタイプを指定できます.指定しない場合は、プロパティタイプから類推します.
例えばnumberであれば自動的にInt型が導出される

2.@PrimaryGeneratedColumn()

この列は自動増分値で、自動的に値が生成されます.自動インクリメンタル/シーケンス/シーケンス/アイデンティティを使用してint列を作成します(指定したデータベースと構成によって異なります).自動的に値が生成されるので、保存する前に手動で値を割り当てる必要はありません.

3.@PrimaryGeneratedColumn ( "uuid")

UIDによって自動的に生成されるデフォルト列を作成します.UIDは一意の文字列IDです.保存する前に手動で値を指定する必要はありません.値は自動的に生成されます.

4. Special columns

いくつかの特殊な熱タイプがあり、利用可能な追加機能があります.@CreateDateColumnは、エンティティ挿入日に自動的に設定される特殊な列です.この列は自動設定に設定する必要はありません.
エンティティマネージャまたはリポジトリ内のストレージが呼び出されるたびに、@UpdateDateColumnはエンティティの更新時間として自動的に設定されます.同様に自動設定で、設定する必要はありません.@DeleteDateColumnは、エンティティマネージャまたはリポジトリ内のソフト削除が呼び出されるたびに、エンティティの削除時間として自動的に設定されます.同様に、自動的に設定されているので、設定する必要はありません.@DeleteDateColumnが有効になっている場合、デフォルトのスキャンは「non-delete」です.@VersionColumnは、エンティティーマネージャまたはリポジトリ内のストレージを呼び出すたびに、自動的にエンティティーバージョン(増分番号)に設定されます.同様に自動設定で、設定する必要はありません.

の最後の部分

パフォーマンス上、これは良い選択ではありませんが、TypeORMはSQL構文による最適化もサポートしているので、優れたツールです.
個人的には、オブジェクトモデルをオブジェクトモデルから分離し、エンティティファイルを作成してデータベースに使用するツールです.これにより、構造の確認が容易になり、メンテナンスがより清潔になると思います.

また、このようにentityファイルを分離して使用する場合、graphqlと組み合わせて使用することで、本明細書のコードが長くなることを防止したり、ニワトリ(typeorm)、卵(graphql)を食べたりすることができ、このような方法を使用しない理由はないと思います

Reference

typeormを参照
ORMとは?
TypeOrmの基本概念