DB設計時のサイズ見積もり - よねのはてな
ここのところ、javaccとawsに魅了されている米林です。 よく使うDB(Oracle/MySQL/PostgreSQL/SQLServer)における設計時のサイズ見積もりで使うサイトの備忘録。 あとは、OracleからのPython情報。 Oracle Oracle 物理設計 http://www.oracle.com/technology/global/jp/columns/skillup/oracle9i/index.html 領域サイズ見積もり http://otn.oracle.co.jp/document/estimate/index.html OTNにログインする必要ありますがオンラインで見積もりが出来ます。 アカウント持っていない人は、この見積もりツールを使う目的でアカウントを作ってみてはいかがでしょうか。 OLTP系とDWH系においてブロックサイズを考慮し、DWH系はブ
「DBを正規化すると遅くなる」は誤解，実証実験の結果が公開に
データ・モデリングの普及団体，DOA+コンソーシアムはこのほど，リレーショナル・データベース管理システム（RDBMS）の処理性能に関する実証試験を行い，調査結果を公開した。「データを正規化してデータベースに実装すると，処理性能が低下する」という“誤解”を正すため，実証実験を行ったという。 データを正規化して実装したときと，非正規化して実装したときの処理性能の違いを調べた結果，「正規化して実装したデータベースの方が処理性能が高い」，「非正規化して実装したデータベースを操作する際，テーブル結合（JOIN）が発生する処理を行うと，処理性能が低くなる」と結論付けた。 実証実験では，自動車の受注業務を想定したWebシステムを構築して，処理性能を測定した。このWebシステムは，データベース上に格納された受注データを基に，製品データや部品データ，部品メーカのデータなどを検索する。 データベース実装の違い
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
