いうオンラインイベントを開催しました。事前収録した動画を参加者の方にご覧いただく形式でしたが、イベント公開から本日まではイベント参加者の方のみに限定公開としていました。参考になる内容をお聞きできたのでより多くのエンジニアの方の参考になればという思いと、イベントに参加ができなかった方から「ぜひ内容を知りたい」というお声を多くいただいていたことから、この度イベントの動画を全ての方にご覧いただけるように一般公開しました。動画を頭から最後まで全部見ていただける方がイベント中のそーだいさんと私たちの会話の文脈がよりわかるのでオススメではあるものの、全部で約1時間45分という長尺のためそこそこ長いです。この記事では動画の一般公開に合わせて、この勉強会でどのような内容について話されていたかを把握しやすいようイベントレポートとして勉強会の概要をまとめました。動画での該当箇所へのリンクと質問・回答内容の要点を書いていますので、この記事は全体をざっくりと把握するために使っていただき、気になるトピックがあれば該当箇所の動画をご覧いただくような使い方をしていただければと思います。投稿をお願いします!いただいた貴重なご意見ご感想は今後のイベント運営改善のための参考とさせていただきます。だいさんのブログ記事「ユーザ情報を保存する時のテーブル設計」で解説されているエンティティの状態を表現するためのテーブル設計をそーだいさんへの敬意を込めて「そーだいモデル」と呼んでいて、以前からいくつかの機能の設計に取り入れています。その上で、今の使い方で正しいのか?や実際に適用して課題に感じた箇所がいくつかあり、それならご本人に直接質問させていただこう!という案が出てきたのが事の発端です。興梠よりそーだいさんへ連絡したところ、快く引き受けてくださり本イベントを開催することとなりました。社での実際のコードや設計をベースにそーだいさんへ質問させていただきました。私たちの取り組みをご理解いただき、出演を快諾してくださったそーだいさんに改めてお礼を申し上げます。本イベントではこれらのトピックについて質問させていただきました。スコープを絞って今回の題材としています。SCOUTのそれぞれに分けて画面の機能を説明しています。図を元にテーブル設計を説明しています。(約18分)説明させていただいた求人機能についてそーだいさんよりフィードバックを頂きました。パターンが使える場合がある。その他には制約が違うカラムを状態毎のテーブルにそれぞれ持たせるのはアリ。した結果をビューやマテビューで参照を簡単にするやり方もできる。しておいて制約はアプリケーション側でチェックするやり方もあり。この質問から派生して以下についてもお話いただきました。(約2分)質問内容そーだいさんのブログ記事「ユーザ情報を保存する時のテーブル設計」で解説されているテーブル設計について、ここでの状態を表す子テーブルの主キーは親テーブルを参照する外部キーとなっていますか?そーだいさんの回答その通りで親テーブルと必ず1対1になることを表している。使う場合はサロゲートキーが付与されるのでこのテーブルするのはやりにくいためこの形にするは必須ではない。使ったクエリではパッと見でわかりにくいコードになってしまうのを課題に感じています。モデルからはそのビューを参照するように設定するやり方がある。仕組みに乗った形で実現できるところがこの方法のメリット。この質問から派生して以下についてもお話いただきました。ついて子テーブルの主キーを親テーブルを参照する外部キーとするのは妥協しても良いポイントかについて改めてお聞きしたいです。制約をつけたり交差テーブルを入れることで1対1とする制約を入れられるので、この部分は必須ではなく妥協できる。求人関連のテーブル設計について、今回共有した内容について考えられる改善点やそーだいさんが設計するとしたらどうするかをお聞きしたいです。発生する箇所を極小化するために子テーブルに分けるというのも考える質問から派生して以下についてもお話いただきました。過去のデータを残す設計にしている箇所がいくつかあります。変更履歴を保持する場合によく使うパターンなので選択肢として問題はないが、この設計が抱える問題点はデータが大きくなることと、最新データを取得する際の手間が考えられる。データが大きくなることについては任意のタイミングで古いデータを削除したり、全ての履歴を保持する必要があれば履歴は別のテーブルへ退避させるやり方で対処できる。最新データを取得する際の手間については先ほど紹介したようなビューを使うことで回避できる。質問から派生して以下についてもお話いただきました。しようとすると多くのテーブルを経由することになるので、ショートカットのための外部キーを持たせておくというような場合です。質問内容のような問題を感じるとき、そもそもの正規化に失敗しているパターンがある。同じテーブルへの参照が重複して存在している場合に、本来はデータの内容は同じに見えても別々のライフサイクルで変化するデータを保持しないといけないケースがあり、この場合はそもそもの正規化が間違っている可能性がある。手間が面倒という問題についてはビューを使うやり方で回避できる。よってはリレーションを辿るときに中間のテーブルをショートカットできるような書き方ができるものもあるのでその利用を考えるのも良いと思う。可能な限り正しく正規化することを意識して、アプリケーション側の都合に合わせる場合はアプリケーション側で吸収できないかを考える方が良い。質問から派生して以下についてもお話いただきました。(約6分)質問内容データに差分があった場合に変更履歴を残したい場合の設計はどういった選択肢が考えられますか?そーだいさんの回答どのカラムに変更があったかを比較したい場合は、比較対象のカラムを結合した値からハッシュ値を計算して新しいデータと比較することで、データの内容に変更があるかを検知するやり方がある。インデックスが利用できるので変更されたかの検知を高速にできる。このやり方を選択する場合にハッシュ値を別のテーブルに分けるテーブル設計も考えられる。質問から派生して以下についてもお話いただきました。依存の機能を使わない方がいいと考えている。トリガーなどの飛び道具を使いたい場合は一時的な利用に抑えて恒久的には使わないようにする。依存の機能に頼らなければいけなくなる場合にはアプリケーションの設計ミスがどこかにあるはず。その設計ミスを一時的にカバーするために技術的負債を選んでいるという意識を持って使う。一時的な調査のためにトリガーを仕込む場合であればアプリケーションコードを変更せずに適用できることはメリットでもある。ライブラリが対応していてアプリケーションコードで表現できるものであれば使っても問題ない。質問から派生して以下についてもお話いただきました。オブジェクトストレージを使う方がいい。ファイルのバックアップを自動で取ってくれるのでその点でファイルが消えてしまう心配がない。考慮がほとんどなかったが、今は状況が違ってファイルアップロードは非同期で実行される場合が多いのでその場合のテーブル設計はまた違ったものになる。開発チームが実際の開発で直面している課題についてその分野の第一線で活躍している開発者の方からフィードバックをいただくイベントを実施しています。私たちの実際の開発から生じている課題やその解決策についてこのようなイベントを通して公開することで、より多くのエンジニアの方々へノウハウを共有できればと思っております。これからもこのようなイベントを続けていきますので今後もぜひご参加・ご視聴いただけると幸いです。私たちと一緒に開発をしていただけるエンジニアを募集しています!私たちの会社やチームに興味を持っていただいた方はぜひご連絡ください。Frontend以下のリンクは今回のイベントの題材となっていた求人機能を利用しています。ユーザーのみアクセスできます。ソフトウェアエンジニアかつてはDJ担当をしてオフィスのフロアをアゲていましたが、フルリモートになった影響でめっきりその場面がなくなってしまいとても悲しいです。最近はスクラムチームでの...フォローLAPRAS株式会社LAPRASは、「すべての人に最善の選択肢をマッチングする」というミッションのもと、まずは職業分野でのミスマッチを無くすべくSNS情報を利用したエンジニア向け採用サービスを開発・提供をしています。LAPRASは、SNSに上がっている情報を自動で分析・スコアリング、ポートフォリオとして可視化し、エンジニアの「得意」を見つけ出します。LAPRASは、これら情報を元に自分のポートフォリオを公開したり、自分に興味を持つ企業と接触したりすることができる情報提供サービスです。SCOOUTは、LAPRASに登録されたエンジニア情報およびネット上に存在するSNS情報をクロールして自動生成したエンジニア情報を利用した、エンジニアのヘッドハンティングサービスです。SNS情報から個人の能力や属性、転職確度を機械学習で分析し、あるべき採用マッチングのための適切な情報を提供します。サービスサイト:https://scout.lapras.com/フォローもっと見る今週のランキングランキングをみる。