アカウント名:
パスワード:
今後、項目が増えたときのために、"予備1", "予備2" ...という列が定義されている。
実際、その項目が使われても、ドキュメントの更新がされず、何が入っているか判らなくなる。
それはドキュメントのアップデートをきちんとしていないという、DBテーブルの設計が悪いこととは別の問題じゃないかな項目が必要になるたびに本番でALTER TABLE叩くっていうのもそれはそれでリスクがあるわけだし、予備を定義しとくこと自体はそう間違いではないと思う
＃逆に言うとどれだけ綺麗にDBテーブルの設計をしていても、改修に伴ってドキュメントのアップデートをきちんとしてなければ、それは「酷いDB」になるんだしさ
何かある度にカラム増やすのはどうかと。
ドキュメントが紙製のものしか現存しておらず、しかもそれにビッシリ注釈が書き足されたモノを渡されたたクソ会社を思い出した…＃しかもぐちゃぐちゃの注釈入りの初版分をコピー→注釈記入で版上げして何度も使いまわしているから、ええそりゃもう金星製曼荼羅かと思ったもんさ＃込められた怨念といい傘連判状 [fukui.jp]並に角度が変わる手書き文字といい、バグ除けのお札として売ったら霊験あらたかだなと思ったもんだ
FILLER は予備つうよりもパディングの意味の方が強いだろうと、、、
「○○を保存するようにしたいけど、カラムがないですねぇ」→「△△が使ってませんから、そこに入れることにしましょう」なんていう、カラム名と中身がまったく一致していない状態に比べれば、予備の方が格段にマシです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
予備項目 (スコア:2)
今後、項目が増えたときのために、
"予備1", "予備2" ...
という列が定義されている。
実際、その項目が使われても、ドキュメントの更新がされず、何が入っているか判らなくなる。
Re:予備項目 (スコア:4, すばらしい洞察)
それはドキュメントのアップデートをきちんとしていないという、DBテーブルの設計が悪いこととは別の問題じゃないかな
項目が必要になるたびに本番でALTER TABLE叩くっていうのもそれはそれでリスクがあるわけだし、予備を定義しとくこと自体はそう間違いではないと思う
＃逆に言うとどれだけ綺麗にDBテーブルの設計をしていても、改修に伴ってドキュメントのアップデートをきちんとしてなければ、それは「酷いDB」になるんだしさ
Re:予備項目 (スコア:2)
何かある度にカラム増やすのはどうかと。
Re: (スコア:0)
ドキュメントが紙製のものしか現存しておらず、しかもそれにビッシリ注釈が書き足されたモノを渡されたたクソ会社を思い出した…
＃しかもぐちゃぐちゃの注釈入りの初版分をコピー→注釈記入で版上げして何度も使いまわしているから、ええそりゃもう金星製曼荼羅かと思ったもんさ
＃込められた怨念といい傘連判状 [fukui.jp]並に角度が変わる手書き文字といい、バグ除けのお札として売ったら霊験あらたかだなと思ったもんだ
Re:予備項目 (スコア:1)
そもそもストーリーで挙げられてた例もCOBOLではよくあったこと。DB設計者の方がPGより年食ってるのかも。
---- 何ぃ！ザシャー
Re: (スコア:0)
FILLER は予備つうよりもパディングの意味の方が強いだろうと、、、
Re: (スコア:0)
「○○を保存するようにしたいけど、カラムがないですねぇ」→「△△が使ってませんから、そこに入れることにしましょう」なんていう、カラム名と中身がまったく一致していない状態に比べれば、予備の方が格段にマシです。