「SQLアンチパターン」。監訳者 和田卓人氏自身による書籍紹介
アンチパターンに名前を付けることで、コンテキストを共有できて議論がしやすくなる。2月14日、15日に都内で開催されたイベント「Developers Summit 2013」、通称デブサミにおいて、書籍「SQLアンチパターン」の監訳をした和田卓人氏は本書の意義をこう強調しました。 「SQLアンチパターン」は、データベースにおける設計からアプリケーションに関わるレイヤまで、開発者が陥りやすいミスや誤解に名前を付けたうえで原因と解決策を詳しく解説しています。 和田氏が指摘するように、これまでデータベースに関するデータ設計などのミスを指摘したり議論するには、その背景を共有するための面倒な説明が必要でした。SQLアンチパターンの登場は、そうした背景を暗黙のうちに共有する手段を与えてくれることになります。本書はデータベース分野の古典になる資格を十分に備えているのではないでしょうか。 書籍の監訳者自身が
DBの世界に起こる変革 | エンタープライズエンジニアの独り言
エンタープライズシステムのエンジニアをやって１０年以上。思うところを書いていきます。その他趣味を少々。。。 DBの世界に起きた大きな波 現在、どの製品を使ったとしてもRDBの性能問題は必ずといっていいほど発生する。理由は簡単で、CPU、ネットワークが高速化（CPUはマルチコア化、ネットワークは10G-Ethernetの一般化やInfiniBandなど）するのにディスク（ストレージ）が高速化に追いついていないからだ。その差を埋める役割として、RDBが担っているケースが多く、性能問題になるケースが散見される。 だが、そういう時代の流れに対して大きな変革が起きようとしている。SSDはかなりコモディティ化してきたので言うに及ばずといった感じだが、個人的には速いもののディスクの置き換えにすぎないと思っている。つまり、SSDは速いがDBのアーキテクチャに大きな変革をもたらすものではない。が、ここにきて
作るプログラムの機能や性能で勝負したい。そうだ、データベースを勉強しよう - きしだのはてな
さて、アルゴリズムの勉強のしかたと、ラムダ計算の勉強のしかたの目星をつけました。 アルゴリズムの勉強のしかた - きしだのはてな ラムダ計算の勉強のしかた、プログラム意味論 - きしだのはてな これでここで書いたプログラムの理論の基礎は勉強できたことになるんじゃないかと思います。 プログラムの理論とはなにか - きしだのはてな ところで、プログラムの勉強地図としてこういう図を書きました。 で、ハードウェアまわりについても、プロセッサを支える技術やネットワークはなぜつながるのかでひととおり勉強したとしましょう。 じゃあ次は、アジャイルか？テストか？UIデザインか？となるわけですが、やはりプログラマなら、プログラムの作り方や使いやすさの前に、作るプログラムの機能や性能で勝負したいじゃないですか。 いい感じに関数が分割できるよとか、読みやすい名前がつけれるよとか、効率よく仕事して定時に帰れるよと
信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
Windows Azure Storage Service を用いた在庫管理の設計
注文テーブルを定義とします。1回の注文で複数の商品の注文があったときはそれぞれを1行に分けて挿入します。ここでも基本はRDBの第1正規化です。注文コードをPartitionKeyとすれば、各注文明細はRowKeyにして同一の物理サーバに配置されるので、同一の注文が別の物理サーバに配置されないようにしておくのがいいでしょう。また、同一PartitonKeyを使うことで明細を構成する複数の行を一括して挿入するEntity Groupトランザクションが利用でき性能が向上します（1操作100行まで）。一方、注文の集計用としては、この注文テーブルをそのまま使うよりは、別に集計用に注文テーブルを用意するのがいいでしょう（後述のCommand and Query Responsibility Segregationの一種）。集計用の注文テーブルではPartitionKeyを会員の分類毎、在庫エリアコード
地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。
楽観的同時実行制御 | ALT
tsが更新列。不思議な関数tseuqalが呼び出されていますが、これはタイムスタンプ値が異なるとエラーにするSQL Server固有の関数です（更新されないでエラーになる）。＝で判定してしまうと、「成功。0行更新しました」とご機嫌に言われてしまうから。IDが間違っていたのか、タイムスタンプ列が違っていたのかが区別できないことになってしまうので。 しかし.NETではSqlTypesにrowversion型はないのだ どうやら、Microsoftとしては使ってほしくはないらしい。MSDNからも、版が上がるたびに徐々に記述が減っていく。更新したい列全部をWHERE句に入れろ、というアプローチを推しているらしい。ADOや、ADO.NETのDataAdapterはこのアプローチです。しかしBLOBがあったらどうするんだ？！ NULLは？ もうめちゃくちゃ大変だし、UPDATEのトレースを取ると、ほと
トランザクション同時実行時の問題とトランザクション分離レベル - Bug Catharsis
データベースの同時実行性の定義データベースにおける同時実行性は、同時に共有データにアクセスしたり、 共有データを変更したりする複数プロセスの機能性として定義することができる。 互いにブロックすることなく同時に実行できるユーザプロセス数が多いほど、 データベースシステムの同時実行性は高いといい、データの変更プロセスによって、 他のプロセスがその変更データを読み取りできなかったり、 データの読み取りプロセスによって、他のプロセスがそのデータを更新できない場合、 同時実行性が低いという。また、複数プロセスが同じデータを同時に変更しようとすると 常にデータの整合性が損なわれるような場合も、同時実行性が低いと言える。 同時実行性が低くなる状況に対処する方法データベース システムで同時実行性が低くなる状況に対処する方法は、 使用している同時実行制御がオプティミスティック(楽観的)*1かペシミスティック
techbank.jp - このウェブサイトは販売用です！ - techbank リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
techbank.jp - このウェブサイトは販売用です！ - techbank リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ
データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基本原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 Oracle、SQLServer、MySQLと色々なDBのチューニングをしてきましたが、
データベースが遅くなった原因を自動的にスキャンして分析するフリーソフト「Trace Analyzer for SQL Server」
Windows XP SP1/VistaとWindows Server 2003/2008の32ビットおよび64ビット版で動作し、SQL Server 2005/2008のデータベースを分析することで速度が遅くなってしまった原因を見つけてくれるのがこのフリーソフト「Trace Analyzer for SQL Server」です。インストールして起動させるには他に「.Net Framework 3.5 SP1」と「Microsoft SQL Server Compact 3.5 SP1」も必要です。 数百あるいは数千もあるファイルイベントをトレースしたり、サーバに過負荷をかけているバッチがどれが特定したりするわずらわしさから解放してくれるはずです。 ダウンロードは以下から。 DBSophic | Trace Analyzer for SQL Server http://www.dbsoph
システム開発実践講座
システム開発でデータベースを使う時には、売上伝票のようにデータを鑑部と明細に分けることがよくあります。 前回までに、鑑部を表形式にして、その後にテーブルの正規化を行いました。 次は明細部分の正規化が必要ですが、 その前に、今回は明細を表形式にするところから始めましょう。 これまでに行っている部分の復習です。 売上伝票を鑑部と明細部に切り分け、 関連付けるために、 明細部に「伝票No」の項目(列)を加え、 明細部の各行を、一意に識別するため、主キーとして「明細No」を加えた状態がこれです。 ・明細部 ＊一意とは、同じデータが他に無く、重複しないことです。 ＊主キー(primary key)とは、レコードを「一意」に識別するためのフィールドです。 ＊明細部での 伝票No は主キーではなく、外部キーなので、重複してもOKです。 思い出しましたか？ やっと準備が整いましたｗ リレーショナルデータベ
データベースを用いたセッションデータ管理について - LukeSilvia’s diary
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
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系はブ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.senmonshinbun.or.jp/list.php
業界紙・専門紙リンク集（業界雑誌・業界ニュース）
ソーシャルゲームのためのデータベース設計
社会実情データ図録 Honkawa Data Tribune