LoginSignup
0
0

More than 3 years have passed since last update.

RDBで後になって困ったこと3選

Posted at

その①安直フィールド追加

UserModel
$table = ['id','name', 'email', 'phone'];

例えばusersとかいうテーブルがあるとして、アカウントの基本情報を含めておくときにフィールドとして持たせるのか、user_profileのような子テーブルを作成しそちらにプロフィールや連絡先などの情報を持たせるのか迷う時がある。安直に考えれば、フィールドでいいじゃんとなるが、これに苦しめられた。

苦しむ原因①:フィールドが増えすぎる

後になってこれも必要これも必要という形で追加していくと、どんどんテーブルが肥大化し管理しにくくなる、挙げ句の果てにはジェイウォークとかJsonフィールドとかが出てくるともう触る気が失せる。

苦しむ原因②:単一から複数への仕様変更

もともと、一つの情報しか格納しない予定だったのに、複数情報を格納するように仕様が変更される場合。既存のフィールドの利用をやめ、子テーブルを作成して管理するようになるが、なら元からテーブルを分けておくべき。

苦しむ原因③:使用状況の管理

仕様の変更などで、あるフィールドをもう使わないなどになった時に、フィールドを簡単にドロップさせるのはあまりにもリスキー、IDE等の機能やテストで、落としても大丈夫そうなのは確認できるものの予期せぬ不具合が起こりかねず、起きた時フィールドが落とされていると復旧がめんどくさくなるので使用しなくなったとしても、ある程度の期間フィールドを残したまま様子を見たくなってしまう。(個人の感想)こうなると何時このレコード落としていいのか、誰が落とすのか、どうやって落とすのか、そのフィールドを使わない間どのように対応するのかなど管理するタスクがどっと増えしんどい。

アンチ安直フィールド追加方針

  • 絶対に後になってフィールドが増えない事が保証されている場合にのみフィールドとする
  • 管理する情報が単一から複数に絶対に変更されない事が保証されている場合にのみフィールドとする
  • 該当テーブルにあるフィールドの属性(近しさ)が一致しない場合にはテーブルを極力分けるようにする

上2つは多分基本的なことなのだと思うが、3つめは個人的に思うとこと。卑近な例で言えば従業員テーブルに氏名、メールアドレスなどがあるとして、そこに緊急連絡先も管理するとなった時にフィールド追加せず、テーブルを分ける。従業員に関する情報だけれども属性的には従業員自身が所有するとは言い切れず、緊急連絡先も追加されるとなれば、住所や最寄駅、などなど他の情報を管理する必要も出てくるかもしれないため。これだけわかりやすければいいけど結構微妙なラインに遭遇したため今は迷ったら子テーブル。

その②AUTO INCREMENT PRIMARY KEY

このマスターテーブル作り替える事ないでしょうと思っていたため任意のIDではなく、auto incrementのプライマリキーを使っていたら非常に管理しにくくなってしまった。

苦しむ原因①:繊細な更新

既存のものを更新して、同時に新しいレコードを追加する必要が出たときは最悪。複数のテキストフィールドにwhereで検索をかけて、ある場合にはアプデ、ない場合には作成をしたが、そもそもある程度の長さのあるテキストで検索かける事自体に抵抗があるし、まかり間違って変更対象ではないレコードによきせぬ変更が加えられたら目も当てあられない。
10件とかの本当に極小のカテゴリー用のマスターテーブルとかであれば目視でまあなんとかすることもできるが、CSVから作成するマスターテーブルとなるとかなり精神を削られる更新作業になる。

苦しむ原因②:IDの付け替え

やっぱり後から任意IDで管理したいとなると、当然これまでのプライマリキーから新しく作成したプライマリキーへの移行が必要になる。数多の関連テーブルの内容を一切のミスなく付け替える作業は当然精神が削られる。

アンチAUTO INCREMENT PRIMARY KEY方針

  • マスターテーブルはAUTO INCREMENTであるべき積極的理由がある場合以外には任意IDで管理する

その③INDEXレス スロークエリ

これは比較的軽めだけれど、えこの程度の件数でも必要だったの?!と思うことがあったので事前に知って起きたかった。というか検証しておくべきだった。

勝手に自分の中で100万とかのレコードから検索するならインデックスとかをよく考えて設計する必要があるんだろうなと思っていたら、7万件くらいですでにかなり遅かった。(7万件のレコードのupsertで30分とか)

アンチINDEXレス スロークエリ方針

  • ダミーデータで実行速度を比較しIndexを貼る必要がありそうであれば貼る

まとめ

数ヶ月スパンで過去の自分に首を絞められている気がしている。
レベル感的には、そこでつまづくとかwwwといったレベル感かもしれないけれど、自分への戒めと備忘録として記録。今まさに未来の自分か保守する他人の首を絞めようとしている人への気づきになれば幸い。

皆さんの経験した地獄があれば教えていただけると嬉しいです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0