[TIL]5月6日



チームとN:1の関係でゲームをしようと思っていたのですが、プランを立てていたら失敗してしまいました.またmapping tableを作って、やってみて、やってみたが、成功しなかったので、game tableを置いて、teamと関係を築かなかった.ゲームのコラムにはteamのidがありますが、関係を設定していないので、変に見えますが、これ以上の方法は考えられません.
レコードのクエリー、参照メンバーのレコード?メンバー参照レコード?
{
    "teamId": 1,
    "records": [
        {
            "name": "나지완",
            "position": "타자",
            "atBat": 3,
            "hit": 1,
            "out": 1,
            "average": 3.0
        },
        {
            "name": "김유신",
            "position": "타자",
            "atBat": 3,
            "hit": 1,
            "out": 1,
            "average": 3.0
        }
    ]
}
前述したようにrecordをクエリすると,APIには当然memberのnameが含まれる.ただし、Recordドメインクラスにmemberのnameがフィールドとして存在する場合は、設計上memberにrecordを参照させるべきですが、これはちょっと気まずいです.メンバーがレコードを参照すると、モードはこうなります.
create table member
(
    id       int primary key auto_increment,
    name     varchar(45),
    position varchar(45),
    team     int references team (id),
    record   int references record (id)
);

create table record
(
    id       int primary key auto_increment,
    at_bat   int,
    hit      int,
    `out`    int,
    average  double
);
recordがid値を持つのは違和感があり,recordがmemberを参照する方向が正しいと考えられる.ずっとこの部分を混同していますが、レコード会社のIDがあるのは好きではありません.
そこで、下記のように変更しました.
create table member
(
    id       int primary key auto_increment,
    name     varchar(45),
    position varchar(45),
    team     int references team (id)
);

create table record
(
    at_bat    int,
    hit      int,
    `out`    int,
    average  double,
    member int references member (id)
);
レコードが参照メンバーに変更されました.
したがって、上のJSON形式のようにnameを含めるにはjoinを使用する必要がある場合があります.
public interface TeamRepository extends CrudRepository<Team, Long> {

    @Query("select at_bat, hit, `out`, average, name, position from record left join member 
		on record.member = id where id = :id")
    Optional<RecordMember> findRecordByMemberId(Long id);

}
上記のメソッドを宣言し、joinクエリー文を作成し、RecordMemberというクラスを作成します.
このように私が望むようによく撮れました.

今日やったこと

  • Gameテーブルを追加してDB設計を行い,これに基づいてAPI設計を行った.チームとチームメンバー別のクエリー、チームメンバー別のレコードのクエリー、ゲームチーム別のスコアのクエリー、ゲーム別のクエリーなどの機能が完成しました.Post方式もJSONタイプなので、フロントをどう設計すればいいか分かりません.明日は他のバックエンドに聞いてみます.
  • です.
  • 号Linux導入コース...たぶん何か理解できるけど、一人でやると出来そうにない.
  • 号LinuxインフラストラクチャAWSコース、仮想マシン実践
  • 仮想マシンを作成し、パブリックとプライベートの2つのサブネットを作成し、CIDR範囲を設定し、インターネットゲートウェイを追加して仮想マシンに接続し、NATゲートウェイは
  • である.
  • 火曜日の授業の内容なので、いい感じです.実習をしながら授業を受ける.
  • 明日は、パブリックおよびプライベートの各サブネットにEC 2を作成し、パブリックからプライベートに接続しようとします.
  • 野球競技タスクの実施では、集約ルート内のエンティティのみに対してリポジトリを作成する場合、クエリー文を使用してサブセットを直接取得して更新および保存すると、正常に動作しません.ドメインクラスでサブセットを検索し、情報を更新および保存し、正常に動作します.
  • Todo


    明日、明日
  • は、GameController部分サービス
  • に分かれている.
  • カスタム例外
  • の作成
  • AWS配備EC 2は2つの部分で行い、
  • をまとめた.