アカウント名:
パスワード:
インデックスが張られていない
キー項目の桁数がVC255だったとき
プライマリキーすら無いよりマシ
PKが降格して普通のカラムになってしまった時には我が目を疑った。暫くして関連テーブルがキー重複起こして死んでしまったので、やっぱりPKに戻そうという話になったのだけど、PKやめてる間にキー重複しまくっていて（というか、重複しまくることが見込まれたため降格させていた）データ移行出来ないという・・・結局、関連テーブル側に意味の無い採番カラムを追加して、もしキー重複しそうならこれをインクリメントするということになった。しかしそのせいで予期せぬ重複データが生まれてしまい・・・という無限ループ
プライマリキーなのに値が更新されるケースもあるね。プログラムやトリガーで関連テーブルを更新する羽目になってる事もままある。
http://srad.jp/comments.pl?sid=535175&cid=1968855 [srad.jp]
＞ 「インデックスいらないでしょ、これ」＞ 「必要ですよ！」＞ 「なんで？出番あるの？ないんでしょ？」
＞ なんとか笑わずに乗り切ったが、かなり苦しかった。
とあるDBのインデックス。管理と技術が交差する時、会議は踊る。
いつからインデックスはテーブル設計になったのかわからん。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
本気で馬鹿かと思ったのは (スコア:0)
インデックスが張られていない
Re:本気で馬鹿かと思ったのは (スコア:2)
その上で、フィールドは固定長の上で配列変数のような構成
こんなDB押しつけて置いて、出来上がったPGの処理が遅いと文句言われても・・・・
テーブルリンクもさせずに全フィールド取得しかさせない癖に・・・
で、正規化やらインデックス追加、テーブルリンクによる普通のSQL使用で圧倒的に早くなったサンプル見せても却下した癖に・・・
火を噴く前にスキル的な事で他プロジェクトへ回ったんで助かったけど
Re: (スコア:0)
キー項目の桁数がVC255だったとき
Re: (スコア:0)
プライマリキーすら無いよりマシ
Re: (スコア:0)
# 全部合わせて複合主キーなんだって
# 別の表は先頭32カラムだけが主キーだったけど、単にOracleの制限なだけで後ろのカラムも心の中では主キーなんだって
Re: (スコア:0)
PKが降格して普通のカラムになってしまった時には我が目を疑った。
暫くして関連テーブルがキー重複起こして死んでしまったので、やっぱりPKに戻そうという話になったのだけど、
PKやめてる間にキー重複しまくっていて（というか、重複しまくることが見込まれたため降格させていた）データ移行出来ないという・・・
結局、関連テーブル側に意味の無い採番カラムを追加して、もしキー重複しそうならこれをインクリメントするということになった。
しかしそのせいで予期せぬ重複データが生まれてしまい・・・という無限ループ
Re: (スコア:0)
プライマリキーなのに値が更新されるケースもあるね。プログラムやトリガーで関連テーブルを更新する羽目になってる
事もままある。
Re: (スコア:0)
インデックスいらないでしょ（オフトピ） (スコア:0)
http://srad.jp/comments.pl?sid=535175&cid=1968855 [srad.jp]
＞ 「インデックスいらないでしょ、これ」
＞ 「必要ですよ！」
＞ 「なんで？出番あるの？ないんでしょ？」
＞ なんとか笑わずに乗り切ったが、かなり苦しかった。
とあるDBのインデックス。
管理と技術が交差する時、会議は踊る。
Re: (スコア:0)
いつからインデックスはテーブル設計になったのかわからん。