Q&A
本文中の[再定義]も直しませんか？
開発で仕様変更などに対応するテーブルの列追加を行おうと思います。
ただ、テストなどでSELECT *の実行を考えて列の最後に追加されるALTER TABLEではなく、テーブルをあらためて作成しデータの移管が良いのかなと思い次のようなパターンまで考えましたがもっと良い方法やベストプラクティスがあればご教授いただけますでしょうか？
できれば、列削除や列の位置移動なども考慮していただけると嬉しいです。
SIerなのでやたら謎の汎用性とかを求められるので(レビューアーが理解できない)その点をご容赦願えればと思います
- コピー元テーブルにロックをかける
- CTAS(CREATE TABLE AS SELECT)を実行してコピー先テーブルを作成
- コピー元テーブルをリネーム
- コピー先テーブルをリネーム
- コピー先テーブルにprimaryや外部参照の制約、インデックス、デフォルト値を作成(ここで何か何か漏れている気がするのですが)
- コピー元テーブルに依存する制約をコピー先に変更(ここがものによって作業が多そう)
- コピー元テーブルのロック解除
アドバイスありがとうございます。
テーブル定義という言葉を修正してみました。
また、列の削除などのニュアンスも含めたいのでその一文を付け足させていただきました
回答2件
0
ベストアンサー
そもそも SELECT * がよくないと思っています。カラム名列挙すべきです。
DBとアプリが密結合になるため (先に DB カラム追加しておいて後からアプリリリースということができない)。
列順が仕様書と異なってしまい
仕様書でも最後に追加しましょう。
お客様環境などでSELECT *されたときに想定外だとクレームが入ったりするので
view を作りましょう。
まぁ SI でお客さんが絶対にそうすべきというなら、作業分の対価をもらってそうせざるを得ませんが、例えば新テーブル作るにしても統計情報更新とかいろいろ見落としやはまりどころがある気はします。
DWH 用途ならわからなくもないんですが、何億・何十億レコードのテーブルとかでもそのやり方でやるんですか?
投稿2022/04/02 04:33
総合スコア2005
ご回答ありがとうございます。
確かに仕様書の最後に追加もありかもなのですが、作成日、更新日が最後の列というものがあり、なかなか難しいのかなと思います。
SELECT *でアプリを作るというか、クライアントでログインして見るということがあります。もしくはA5M2でログインしてみるみたいな。
ビューで見え方を変える方法は外部スキーマと概念スキーマに分けることで取り扱いやすくなるなと思います。
ある種、これが正攻法な気がします。
ただ「管理物が増えるじゃないか」というPM層の頭の固いコメントが投げられそうです・・・
統計情報などの話をしても「なんのことか分からないが今まで通りにして」と要求されちゃうんですよね。
あとはこれくらいですか。
・作成日・更新日等共通カラム系を先頭に持っていく (たまに見る)
・必殺「予備カラム1～10」
論理でも物理でもわかりやすい順に並んでいる方がよいという価値観はあって、
とはいえ途中にカラム追加できない DB もあるということで、どっちを優先するのか、
前者であるならコストをかけてもそうすべきかという話ですね。
対お客さんなら両方のパターンについて見積もりと作業時間を提示すればよいし、
対内部なら転職活動です。
手順としては別によいんじゃないでしょうか。参照している view が invalid になった場合の再有効化とか、通番作成用シーケンス参照されて通番が飛んでクレームとか、いろいろありそうではありますが、広く検討/検証してみるしかないと思います。
追加の回答ありがとうございます。
> ・作成日・更新日等共通カラム系を先頭に持っていく (たまに見る)
> ・必殺「予備カラム1～10」
この手段は使えそうですね。
とりあえず文句をつけなきゃレビューにならないと思っておられる年齢高めのレビューアーさんの「作成日・更新日が前って変じゃない」「予備ってなに？検討もれを前提にするの？」みたいなのをかわせばいけそうな気がします。
> 論理でも物理でもわかりやすい順に並んでいる方がよいという価値観はあって、
> とはいえ途中にカラム追加できない DB もあるということで、どっちを優先するのか、
> 前者であるならコストをかけてもそうすべきかという話ですね。
そうなります。
品質・コスト・期日全部守ってね！な契約だったりするのでなかなかお金がもらえないので
しんどかったりはあるのですがとにかくテストで潰していくしかないかなと思っています。
> 手順としては別によいんじゃないでしょうか。参照している view が invalid になった場合の再有効化とか、通番作成用シーケンス参照されて通番が飛んでクレームとか、いろいろありそうではありますが、広く検討/検証してみるしかないと思います。
ありがとうございます。
そこはなるべく依存関係を出す関数やシステムビューなどを駆使していくしかないかなと。
ただ、そういう風にアプリケーションに依存する制約は想定外でした。ありがとうございます。
あまり、やったことがない分野だったので前任者にも聞いてみたところ「基本的にビューも外部参照制約も業務システムで普通ないんで気にしなくていいですよ」とのこと。
色々と闇が深いです・・・
0
テーブル変更の影響を調査した上で、開発環境で列追加のチェックをして普通にALTER TABLE ... ADD COLUMN しますが、PRIMARY KEY, INDEX, GRANT, SYNONYM や外部キーがあれば付け直しが必要になる別テーブルを作るのにこだわる理由は？
[テーブルの再定義]って表現は誤解を招き易いし、たぶん使わない表現なので、単に[テーブルへの列追加]と質問を修正しては？
投稿2022/04/02 03:52
総合スコア16415
ALTER TABLE ADD COLUMNで十分だと私も思うのですが、この場合、列が最後になってしまい
列順が仕様書と異なってしまい、そういうことを嫌がる傾向がある職場という背景があります(お客様環境などでSELECT *されたときに想定外だとクレームが入ったりするので)
MySQLなどは列順変更できるようですが、あまりそういうお客様だとSQLServerだったりして。
exp/impしたら表示順が変わったってクレームあるようなお客様がいたりするので(元々使ってたSQLにORDERが入ってなかった)
別テーブルにすると統計情報もぶっ飛ぶし、あまり筋がいいやり方とは思えないんですが、なかなか理解してもらえないんですよね。
すみません、お礼を言い忘れてしまい申し訳ありません。
ご回答ありがとうございます。
SELECT文はORDER BY句でソート順を明示しない限り表示される順序は保証されません。SQL入門レベルで習う内容です。
>exp/impしたら表示順が変わったってクレームある
バックアップ計画もないのでは？
定期的にバックアップは取っていますか？
リカバリが必要になった時にバックアップを取っていないことが発覚したら笑い話にもなりません。
> SELECT文はORDER BY句でソート順を明示しない限り表示される順序は保証されません。SQL入門レベルで習う内容です。
流石にそれは「そういう仕様です」で了承していただけましたが、全く別の畑にいた私からは結構衝撃的でした・・・
データ移行の確認のためのSELECT *での話でしたが、それがシステムに使われてたらと思うとゾッとしましたね。
>> exp/impしたら表示順が変わったってクレームある
> バックアップ計画もないのでは？
> 定期的にバックアップは取っていますか？
おそらく、本稼働後、一度も本体の障害がなかったか、ディスク全体でミラーリングしてたのかなと思います。
多分、リカバリすることなく本稼働以来そのまま来たと思います。
(私はそういうのをやってるうちに体をやってしまったので・・・詳しい話を聞けずじまい)
あなたの回答
tips
プレビュー
