人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

DB上にFLEE項目を設ける理由はなんでしょうか?
既に居ない方(元SE)が作成したDBを見ると、フィールド名に「店コード」「売上1」「売上2」・・などの必要な項目のほかに「Flee1」「Flee2」「Flee3」などの項目がありました。設計書を見ても「予備項目」とあるばかりで、Distinctなどで集約をかけてもやはり、空白で、Varchar型で100文字分×3フィールドとってあるばかりです。その人が設計したテーブルは運用中も含めて40以上あるのですが、すべて同様になっています。
運用環境はOracleだったりAccessだったり色々ですが、同様になっています。
?これは何のためにあるのでしょうか。テーブル再設計よりもメリットのあることなのでしょうか。メリットデメリットを教えてください。
?この方法って一般的なのでしょうか。

●質問者: hakob
●カテゴリ:コンピュータ インターネット
✍キーワード:access dB Oracle SE とある
○ 状態 :終了
└ 回答数 : 3/3件

▽最新の回答へ

1 ● hirotow
●28ポイント ベストアンサー

データベースというのは基本的に一定長のバイナリを連結したものですが、

この構造上列の追加と削除はかなり負荷が大きい処理で、たぶん分単位の時間がかかります。

そこで、ある程度余分な列を確保しておくことで負荷をかけずに列追加ができるようにすることがあり、結構ポピュラーな方法です。


デメリットとしてはデータベースのサイズが必要以上に大きくなることと見た目が悪いことです。


ちなみにここらへんで質問するともっと詳しいことが聞けるかと思います。

http://bbs.wankuma.com/

◎質問者からの返答

なるほど。確かに列の追加やテーブルを一度Dropして再度作成・・・などすると時間がすごくかかるので、対処としてですか。

Web公開サービスなどで緊急に、かつ処理をとめることが出来ないときなどにはもちろんその他の場合もメリットはありそうですね。納得できました。ポピュラーな手段なのですね。


2 ● memo77
●26ポイント

運用を開始してからのフィールド追加に対応するためですね。

過去、言語的にデータベースへのフィールド追加が困難だった時代の名残です。

特にSQLに馴染めずに、いつまでもカーソルを回すことしかできないようなエンジニアがよく使うようです。


個人的には、現在のデータベースアーキテクチャや開発環境であれば、メリットよりもデメリットのほうが大きいと評価します。

フィールドにしっかりと意味を持たせて名前をつけ、必要な型を指定したほうが、設計の見通しもいいです。

型変換によるオーバーヘッドも、データの不整合に備えてエラーチェックを組む必要もありません。

◎質問者からの返答

確かに名前の付け方からしてあまり気持ちのいいものではありませんね。実環境で使用する変数名にfoo だの barだのついているのを見るようで。

個人的にはストアドも、あの言語性もあって「気持ち悪い」と感じてしまうのですが。もちろんストアドでないと不可能なこともいくつかありますけどが・・・。

型変換すればいかようにでも使いまわせる、というのはちょっと盲点でした。だからvarcharでとるのか。

全体の規模感・運用性を考慮して必要が無いのならば削っていこうと思います。ありがとうございました。


3 ● chuken_kenkou
●26ポイント

階層型やネットワーク型DBの場合は、定義変更が簡単ではないので、予備のフィールドを作っておく

ことが常識でした。

一方、RDBMSでは、列追加や列削除を容易にできることがメリットなのですけどね。

MySQLでは列追加で全行の更新が発生したり、PostgreSQLでもNOT NULLの列追加をすると、全行

更新になるようですが、商用RDBMSでは定義情報の更新だけで、実際のDB中の行は更新されない

(nullが入っているように動作する)というものが主流だと思うのですが。

◎質問者からの返答

どうにもメリットが見えづらいですよね。もちろん、表の定義情報の変更はコストのかかる処理ですが・・・

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ