アカウント名:
パスワード:
最近かかわったプロジェクトで1テーブル300カラム以上のものがあった既に2,3回程の改修が行われていたものに今回必要になるカラムを追加していったFoo1,Bar1,Baz1,Foo2,Bar2,Baz3...が40くらい繰り返されているものが2パターン存在していて、明らかに使われていないしかも主キーが数値型で1つしかない便利なテーブルとしてなんでもかんでも詰め込み過ぎで正規化されていない
年配SEに再三テーブルの設計を見直しませんかと打診するが、昔から使っているから他に影響してはいけないし、今回はこのままでいきましょうというのださらに、昔はExcelVBAでこのテーブルの値を読み書きしていて、この設計しかできなかったというのだ
頭が痛くならないうちに、必要な項目だけを抽出するSQL文とDtoとCriteriaを作って、見なかったことにした
メインフレーム側のデータを丸々移行するんだ!というプロジェクトに携わった際に、DB設計者が作ったDDLによるテーブル構築時にこのエラーをたたき出したことがあります。
------------------ORA-01792 2 表またはビューに指定できる最大列数は1000 です。
原因: 1001 列以上ある表またはビューを作成しようとしたか、列を追加しすぎたため許容できる最大の列数1000 を超えました。表にある未使用の列も最大列数1000 に含まれることに注意してください。------------------
300カラム?まだまだっすよ。エラーが出たから2分割して500x2~ですよ。
初めて見る事例だったので、ブログに書いて記録してあります(笑)自分は直接そのテーブルは見ないサブシステム担当だったので直撃は免れましたが、当時、直接関与してたグループはよくモチベーション維持できたな……とw
当時のExcelが256カラムしか(しか?)使えなかったという理由で、2テーブルに分けたOracleDBなら見たことがあります
#今のExcelはもっと使えます 念の為##多カラムの推奨ではありません
ある種のDBMSは更新時のロックに難があるので、処理に応じてテーブル分割ってのはありましたよ。正規化で一意となってもテーブル分割するのは有りです。
そんな高尚な理由ではなく本当にExcelにあわせるためだけのテーブル分割だったんです…#あとで3テーブルになった…
今まで火消しに参加した中で最悪といえるのは、あるテーブルの主キーが可変長文字列(これはまだいい)で運用中に主キーの値が手作業で直接変更出来てしまう(普通はできない)というシステム。しかもご丁寧に入力段用のDB(A)と出力段用のDB(B)に分割されていて、AからBへは日時バッチでデータ転送がおこなわれることになっていた。そのため運用を続けるうちに (A)と(B)の同名テーブルの主キーに差異が増えてしまう。当然入力時と出時のデータで内容が一部食い違っておりデータ照合は出来なくなるという今思い出しながら書いていてもまるで訳が分からないカオスな仕様。
設計者いわく元々MS-Accessで作られた2つのツールだったのだが事業規模拡大に伴い登録件数が上限に達した為、DBをOracleに変更することに成った際、もともとの設計どころかローカルな運用方までまるっと引き継いだとのこと。開発者を火消しに送る前に前にまず、論理的にでも良いからDBを一つにして設計しなおせといいたかった。当然収束なんてしなかった orz
DBのことは、よくわからないのですが、新しくテーブル設計した場合、古いテーブルに対応していたソフトなどはそのまま使えるものなのですか?
元のテーブルもまじめに設計されてれば、多少のことはビューとかで何とかなるような気がします。元々のテーブル設計が悪いなら、アプリも含めて改修したほうがよさそうです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
300カラムに主キー1つのテーブル (スコア:0)
最近かかわったプロジェクトで1テーブル300カラム以上のものがあった
既に2,3回程の改修が行われていたものに今回必要になるカラムを追加していった
Foo1,Bar1,Baz1,Foo2,Bar2,Baz3...が40くらい繰り返されているものが2パターン存在していて、明らかに使われていない
しかも主キーが数値型で1つしかない
便利なテーブルとしてなんでもかんでも詰め込み過ぎで正規化されていない
年配SEに再三テーブルの設計を見直しませんかと打診するが、昔から使っているから他に影響してはいけないし、今回はこのままでいきましょうというのだ
さらに、昔はExcelVBAでこのテーブルの値を読み書きしていて、この設計しかできなかったというのだ
頭が痛くならないうちに、必要な項目だけを抽出するSQL文とDtoとCriteriaを作って、見なかったことにした
Oracleのカラム数上限は1000であることを体感する貴重な機会を得た (スコア:1)
メインフレーム側のデータを丸々移行するんだ!というプロジェクトに携わった際に、
DB設計者が作ったDDLによるテーブル構築時にこのエラーをたたき出したことがあります。
------------------
ORA-01792 2 表またはビューに指定できる最大列数は1000 です。
原因: 1001 列以上ある表またはビューを作成しようとしたか、列を追加しすぎたため許容できる最大の列数1000 を超えました。表にある未使用の列も最大列数1000 に含まれることに注意してください。
------------------
300カラム?まだまだっすよ。エラーが出たから2分割して500x2~ですよ。
初めて見る事例だったので、ブログに書いて記録してあります(笑)
自分は直接そのテーブルは見ないサブシステム担当だったので直撃は免れましたが、
当時、直接関与してたグループはよくモチベーション維持できたな……とw
Re: (スコア:0)
当時のExcelが256カラムしか(しか?)使えなかったという理由で、2テーブルに分けたOracleDBなら見たことがあります
#今のExcelはもっと使えます 念の為
##多カラムの推奨ではありません
Re: (スコア:0)
ある種のDBMSは更新時のロックに難があるので、処理に応じてテーブル分割ってのはありましたよ。
正規化で一意となってもテーブル分割するのは有りです。
Re: (スコア:0)
そんな高尚な理由ではなく本当にExcelにあわせるためだけのテーブル分割だったんです…
#あとで3テーブルになった…
主キーでひどい目にあった経験といえば (スコア:0)
今まで火消しに参加した中で最悪といえるのは、あるテーブルの主キーが可変長文字列(これはまだいい)で
運用中に主キーの値が手作業で直接変更出来てしまう(普通はできない)というシステム。
しかもご丁寧に入力段用のDB(A)と出力段用のDB(B)に分割されていて、
AからBへは日時バッチでデータ転送がおこなわれることになっていた。
そのため運用を続けるうちに (A)と(B)の同名テーブルの主キーに差異が増えてしまう。
当然入力時と出時のデータで内容が一部食い違っておりデータ照合は出来なくなるという
今思い出しながら書いていてもまるで訳が分からないカオスな仕様。
設計者いわく元々MS-Accessで作られた2つのツールだったのだが
事業規模拡大に伴い登録件数が上限に達した為、
DBをOracleに変更することに成った際、もともとの設計どころかローカルな運用方までまるっと引き継いだとのこと。
開発者を火消しに送る前に前にまず、論理的にでも良いからDBを一つにして設計しなおせといいたかった。
当然収束なんてしなかった orz
Re: (スコア:0)
DBのことは、よくわからないのですが、新しくテーブル設計した場合、古いテーブルに対応していたソフトなどはそのまま
使えるものなのですか?
Re:300カラムに主キー1つのテーブル (スコア:1)
元のテーブルもまじめに設計されてれば、多少のことはビューとかで何とかなるような気がします。
元々のテーブル設計が悪いなら、アプリも含めて改修したほうがよさそうです。