データを組んでて思ったこと

SQLiteを使用する場合です。
タグを入れるテーブルとコストを入れるテーブルの関係性をどうやろうか考えました。

t_cost
_id
_value
_timestamp
_tagname

m_tag
_id
_name
_timestamp
_count

ＤＢのアップグレードでカラムを加えるような場合、
前のデータ＋デフォルト値を加えた新しいカラムをテーブルにインサートという感じにしたい。
手間を考えると、copyして古いのDropして新しいのをrenameする形が良さそうだ。
この時、_idを外部キー扱いとすると、_idの値が変わったときに連鎖updateが必要になる。
SQLiteだとシステム的にそういった仕組みがないので、自前でこつこつupdateしないといけない。
これはめんどくさい（ぁ


mapタイプのデータ群でいいや。←手抜き感
アップグレード時の手間を減らしたい。←怠惰
copyして古いのDropして新しいのをrenameすればいいよねー。←簡単
だから関係性はnameでやろう。_idはがんがん変わるし。←言い訳
連鎖アップデートを手動でとかめんどくさいですしおすし。←本音
重複しないようにロジック組めばいいよね（震え声

※良い子のみんなは「_idの値を持つ_idとは別のフィールド」を外部キー扱いして関係のあるテーブルの値を更新するように。

他のDBだったら外部キー制約あるから、ルールに則って連鎖アップデートしてね。

以下蛇足。
でかい規模のサーバにアクセスするシステムってどうなってるんだろう。
例えば、戸籍とか新幹線の予約システムとか。

サーバ系は触ったことはもちろん見たこともないのでどういう処理してるのか一度見てみたい。
サーバに投げて終了の方しかやったことねーんす。今度勉強してみよう。

新幹線の予約システムはマルス(MARS)と読むらしいです。
以下、マルス（システム）より抜粋
元々は"Magnetic electronic Automatic seat Reservation System"（磁気的電気的自動座席予約装置）の略とされていたが、現在では"Multi Access seat Reservation System"（旅客販売総合システム）の略となっている。
抜粋以上。