質問者様の望んでおられる、
ピンポイントで検索文字列が設定されたテーブル内のカラムの特定はなかなか難しそうなので(ストアドでバッチ化すればもしかすると不可能ではない?)、
当方の思いつく限りで何個か提案してみます。
#データベース単位でデータエクスポートして検索文字列を探す
データベースのdump機能などでテーブルとデータをエクスポートし、
それをエディタのGrep検索などで当たりをつけていく方法です。
DBMSによるかもですが、
dumpにはINSERT文としてごと吐き出す等の機能もあるので、
格納されたテーブルとカラムの特定は比較的容易かと思います。
少なくとも仕様書ベースに探すよりは時間が削減できるかと思われます。
#ストアドを作成してゴリゴリと
これもDBMSごとに依存しそうですが、
ストアドで「首相」が設定されたテーブル・レコードをテキスト形式で吐き出すくらいは出来るかもしれません。
0. 検索したいデータベース内のテーブルリストをDBMSのカタログより取得
0. テーブルごとのカラムリストを取得
0. 動的にSQLを作成し、検索結果をテキストファイルか何かに落とす
3番目にて組み立てるSQLは以下のようなイメージ
SQL
1CREATE TABLE table_1(
2 HOGE VARCHAR(10) PRIMARY KEY
3, FUGA VARCHAR(4)
4, PIYO INT
5)
SQL
1SELECT
2 t.*
3FROM
4 table_1 t
5WHERE
6 '首相' IN (t.HOGE, t.FUGA) -- この箇所で指定するカラムは文字列型でないとエラーとなる
ただ上記のようなストアドを作るのもなかなか骨が折れるかもかもしれませんし、
テーブル数、データ数が莫大ともなると実行自体がなかなか終わらないと思われるので(途中でこけたりしたら悲惨)、
採用するに当たっては慎重に検討してください。
#ただ本来の理想を言うと
データがあちこちに散らばっている現状が非常にまずいです。
今回は一時対応でことなきを得たとしても、
同じような状況が再度起こった際再び対応時間が取られるとなると、
非効率極まりません。
システム規模が大きいということから、
大変であろうことは承知で申し上げますと、
例えば項目名マスタとか1つのマスタテーブルをこしらえて、
システムの各機能はそのテーブルを参照するように変更した方が合理的です。
今すぐ対応するというのは困難かもしれませんが、
長期的に見るとテーブル構成の見直しが一番最適解となるので、
そちらも考慮に入れてみてはいかがでしょうか?
データベースの本来の姿としては、
テーブルとカラムをもってデータが識別されるのであって、
登録されたデータからテーブルなりカラムを識別するものではないため、
今回のような処理では、DB単体では不得手となるのは致し方ない所です。
退会済みユーザー
2016/09/03 06:19