アカウント名:
パスワード:
顧客DBのバックアップをとっていないという状況が考えられない。個人のミスの前に会社的にどうなのよと。
本番環境のテーブルに対してtruncateかけるってのがよくわからん。ふつーそんなことする?似たようなテーブルからデータを再作成って、つまりそのテーブルは不要だったかビューの類で良かったんじゃないの?
>似たようなテーブルからデータを再作成って、つまりそのテーブルは不要だったかビューの類で良かったんじゃないの?つまりはデータベースの正規化が出来てなかったと言うことですよね。
それとも似たようなデータではなくて似たような別のデータベースからだったのだろうか?
どっちにしてもデータベースのバックアップも取ってないAnd正規化がまともにできてないってどんな管理体制だったのだろうか?
> そのテーブルは不要だったかビューの類で良かったんじゃないの?
なんだか、頭がおめでたい人ですね。
削除するデータが大量すぎてdeleteするとシステム設計上の許容範囲を上回るログが出力されてしまう場合やログ書き込みがパフォーマンスに影響が出てしまう場合に利用します。
本当は使いたくない手ですがdeleteするだけで1時間かかる作業とか...困るでしょ?バックアップの容量も想定を大きく上回るし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
そもそもだけど (スコア:0)
顧客DBのバックアップをとっていないという状況が考えられない。
個人のミスの前に会社的にどうなのよと。
Re:そもそもだけど (スコア:1)
本番環境のテーブルに対してtruncateかけるってのがよくわからん。ふつーそんなことする?
似たようなテーブルからデータを再作成って、つまりそのテーブルは不要だったかビューの類で良かったんじゃないの?
Re: (スコア:0)
>似たようなテーブルからデータを再作成って、つまりそのテーブルは不要だったかビューの類で良かったんじゃないの?
つまりはデータベースの正規化が出来てなかったと言うことですよね。
それとも似たようなデータではなくて似たような別のデータベースからだったのだろうか?
どっちにしてもデータベースのバックアップも取ってないAnd正規化がまともにできてないってどんな管理体制だったのだろうか?
Re:そもそもだけど (スコア:1)
某社は昔、正規化はおろかindexでさえまともに設定していなかった。
そして、近年また一緒に仕事をしたが正規化を行き過ぎにしていて、
テーブル結合の半数近くが内部結合できず。
さらに事前に決定していた、結合は4テーブルまでという規約を軽く
超える事に・・・
※作成日時・ユーザ、更新日時・ユーザを必ず入れているので
データ量もその分無駄に消費
Re: (スコア:0)
> そのテーブルは不要だったかビューの類で良かったんじゃないの?
なんだか、頭がおめでたい人ですね。
Re: (スコア:0)
削除するデータが大量すぎてdeleteするとシステム設計上の許容範囲を上回るログが出力されてしまう場合やログ書き込みがパフォーマンスに影響が出てしまう場合に利用します。
本当は使いたくない手ですがdeleteするだけで1時間かかる作業とか...困るでしょ?バックアップの容量も想定を大きく上回るし。