アカウント名:
パスワード:
実際のところ, テロリストを識別する情報というのが要件定義できなければ, 生データをそのまま持ってくるしか方法が無いんじゃないでしょうか.
一見同じに見える項目でも意味合いが異なるとか, 不要に思える項目でも他の項目と突き合わせれば不信点が浮かび上がってくるとか. 9/11の時もそうした後付けで見直せば分かる事項が複数有ったのに, 上に上がってくる間にクリーンアップされて見逃していたってことがあったのが, こうした設計の真の原因じゃないかと思います.
まあ, あと10回や20回ぐらいテロが起きれば, 本当に必要な情報が分かって設計も最適化できるでしょうが.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
分割ルール (スコア:2, 興味深い)
パーティショニングだったら多過ぎじゃないかと。(分割損がメリットを上回る)
正規化だとして、パフォーマンスを死守するためにあえて正規化を崩すという手法は一般的ですが、一人当たりの項目数ってどの程度あったんでしょうね。
てか50万人程度でパフォーマンス云々はマズイですよねぇ。
Re: (スコア:0)
テーブルの多さの原因。
Re:分割ルール (スコア:2, 興味深い)
実際のところ, テロリストを識別する情報というのが要件定義できなければ, 生データをそのまま持ってくるしか方法が無いんじゃないでしょうか.
一見同じに見える項目でも意味合いが異なるとか, 不要に思える項目でも他の項目と突き合わせれば不信点が浮かび上がってくるとか. 9/11の時もそうした後付けで見直せば分かる事項が複数有ったのに, 上に上がってくる間にクリーンアップされて見逃していたってことがあったのが, こうした設計の真の原因じゃないかと思います.
まあ, あと10回や20回ぐらいテロが起きれば, 本当に必要な情報が分かって設計も最適化できるでしょうが.