ゆるコンピュータ科学ラジオ#90 を見ていて複数属性を持つデータについて言及されてない設計があったので書きます
動画はこちら
性質毎にテーブルを作成する設計
性質毎にテーブルを作成し、そのテーブル内にデータがあればそのデータはそのテーブルの性質を持っているとする設計です
例
”語釈がおもしろい” テーブル と ”知らなかった” テーブルを作成
”朝涼” を ”語釈がおもしろい” と ”知らなかった” にINSERTすることでその属性であることを示す
題材（第５正規形の表）
動画１１分あたりの第５正規形の表
※単語テーブル
| 単語 | 意味 | 備考 |
|---|---|---|
| 朝涼 | ５月ごろの、朝起きた時の涼しい感じ。 | 朝寒もある（１０月） |
| 揚げ雲雀 | 空に高く飛び上がるヒバリア。 | そんなん載るの？ |
※性質テーブル
| 単語 | 性質 |
|---|---|
| 朝涼 | 語釈がおもしろい |
| 朝涼 | 知らなかった |
| 揚げ雲雀 | 知らなかった |
属性テーブルを作成する設計
※単語テーブル
| 単語 | 意味 | 備考 |
|---|---|---|
| 朝涼 | ５月ごろの、朝起きた時の涼しい感じ。 | 朝寒もある（１０月） |
| 揚げ雲雀 | 空に高く飛び上がるヒバリア。 | そんなん載るの？ |
※語釈がおもしろいテーブル
| 単語 |
|---|
| 朝涼 |
※知らなかったテーブル
| 単語 |
|---|
| 朝涼 |
| 揚げ雲雀 |
以上のような実装でも複数性質を表現することは可能ですね
レコードが存在するかどうかで性質を特定します
水野さんの提案はビットフラグだよね
動画７分あたりからの水野さんの言う小数点を使った設計はビットフラグだよねというつっこみをしようと思ったら動画コメント欄でたくさん指摘されてのでここで言及しなくても良さそうですが
古来からの技だし堀元さんがつっこむだろうな思って見てたら動画の最後まで言及されることがなかったのであえて触れないのかなとか思いましたが、アカデミックにコンピュータを学んだ人間と現場で設計・実装している人間の差なのかもなと思いました
正規化によりパフォーマンスが落ちる問題の解決策の一例
パフォーマンスについて言及があったのでそこについて一例だけ設計を書きます
秒単位のリアルタイム性を捨ててJOIN後のレコードを収めるキャッシュテーブルを作る手法です、実装が楽で物理的に切り離すこともできるのでリアルタイム性を捨てて良い状況であれば常套手段かと思います
本件のテーブル例で作成するなら
SELECT * FROM 単語テーブル LEFT JOIN 性質テーブル ON 単語テーブル.単語 = 性質テーブル.単語
として選択したレコードをあらかじめ作成したキャッシュテーブルにINSERTします
※キャッシュテーブル
| 単語 | 意味 | 備考 | 性質 |
|---|---|---|---|
| 朝涼 | ５月ごろの、朝起きた時の涼しい感じ。 | 朝寒もある（１０月） | 語釈がおもしろい |
| 朝涼 | ５月ごろの、朝起きた時の涼しい感じ。 | 朝寒もある（１０月） | 知らなかった |
| 揚げ雲雀 | 空に高く飛び上がるヒバリア。 | そんなん載るの？ | 知らなかった |
こういったクエリを１分一回とか１０分一回とか定期実行することで検索遅延を軽減することが可能です
本体DBとキャッシュDBを物理的に分けることでCPUやメモリリソースを適切に割り当てることもできます
以上です