ユーザとユーザを多対多で関連付けるモデルを共通化する - Hidden in Plain Sight
思いのほか前回のRailsプチ・デザインパターンの紹介に反応があったので、こういう小ネタも出していったほうがいいのかな、ということで第二弾。 ソーシャル系アプリだと、ユーザとユーザを関連付ける多対多のモデルがたくさんでてきます。たとえば、一般的なところではフォローとかブロックとか足あととか。さらにデーティングサイトになると、ウィンクだったり、Secret admirer（こっそりlikeするけど両思いだったらおめでとうって通知がくるってやつ）だったり、いろいろなモデルがこのパターンにあてはまります。 この場合、「AがBをフォローしている」「BがAをフォローしている」「AとBがお互いにフォローしている」という3つの状態があるわけですが、相互フォローの状態は「AがBをフォローし、かつBがAをフォローしている」と読み替えてSQLでも記述可能なので、以下ではシンプルに単方向のグラフで全てを扱うもの
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
人月計算とExcelとスーツの世界より
俺の住む世界はアイティーとやらに支えられているらしい。 アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。 そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。 昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。 だから自分はシステム会社に向いていると思った。 実際、資格取得を勧められて始めた勉強は楽しかった。 浮動小数点数、オートマトン、SQL、スタック、木、論理式。 パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。 楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。 研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。 現場に出て、本番機に触った。 ３０年間親会社を支え続ける偉大なシステムの中身を、わくわくし
SQL vs NoSQL、グーグルにおける戦い（前編）。Google I/O 2012
SQLとNoSQLではどちらが優れているのか？ グーグルの担当者がディベート（というより小芝居：-）を行ったセッション「Google I/O 2012 - SQL vs NoSQL: Battle of the Backends - YouTube」が公開されています。 このセッションは、先々週開催されたGoogle I/O 2012で行われたもの。SQLとNoSQLには機能的にどのような違いがあり、どう使い分けるべきなのか、明確な説明が参考になります。 ハイライトを紹介しましょう。 クラウドにおけるデータベースのメリット グーグルのAlfred Fuller氏（NoSQL担当）。 クラウドはフォルトトレラントでメンテナンス不要、パッチも私たちが適用しており、利用者は運用について心配する必要がない、といったメリットがある。 データのレプリケーションや地域分散でデータも保全され、インターネッ
KH Coder
************************************************************ THIS PROJECT IS MOVED. See http://khcoder.net/en for the latest & greatest. You can download this tool from the new home. See you there! ************************************************************
SQLアタマ養成講座 記事一覧 | gihyo.jp
第6回SQL流行間比較（2） 直近、直近の1つ前、そのまた1つ前… ミック 2009-05-19
パフォーマンス向上の最短コースを知る
パフォーマンス・チューニングにおけるSQLチューニング それでは実際に、パフォーマンス・チューニングでのSQLチューニングの位置付けを見てみます。 論理設計や物理設計の変更、Oracleインスタンスの初期化パラメータの変更などOracleデータベースのパフォーマンス・チューニング方法の中で、SQLチューニングは、最も効果が期待できる手段です。場合によっては、索引の使用の有無など、SQL文を最適化することによって、数倍から数百倍のパフォーマンス向上といった、そのほかの手段では実現不可能な結果をもたらすこともできます。 SQLチューニングの処理は、Oracleインスタンスやハードウェア・リソースなどに密接にかかわっていて、パフォーマンス・チューニングの観点から見ると、これらのかかわり合いは、図3のような関係で表せます。この図の中で、SQLチューニングは最も下位に位置しています。下位の階層は、よ
やさしくわかるデータベース・チューニング
データベースを利用したシステムのパフォーマンスは、『チューニング』という作業によって大幅に改善されます。 プログラムを変更せずに、いきなり処理時間が５００～１０００分の１に短縮されることもマレではありません。データベース・チューニングって魔法みたいだと思いませんか？ このテキストは、Ｏｒａｃｌｅデータベースを使用したシステムのチューニング方法について詳しく説明していきます。 データベース・チューニングすなわちシステムの調整は、『設計』、『開発』、『運用』のフェーズにて行います。(システム構築とは『分析』→『選定』→『計画』→『設計』→『開発』→『導入』→『保守』→｢分析｣と、各フェーズが循環している) それぞれのフェーズ別に解説していますので、それぞれの担当者が、その段階にて各項目の内容を１つずつチェックして下さい。 チューニング方法について、２２章６８項目にまとめましたので、Oracle
「相関サブクエリ」とは何かを理解して，複雑なSQLでも読めるようになろう - 主に言語とシステム開発に関して
SQLの「相関サブクエリ」がわかれば・・・ 巨大なSQLが，迷わずに読めるようになる。 「関数」のような，便利なサブクエリを書けるようになる。 以下では， 「相関サブクエリ」とは何か？ 普通のサブクエリ（非相関サブクエリ）やJOIN操作とは何が違うのか？ 多重にネストされた，巨大なSQLの読み方は？ という点を論じる。 サンプルデータ，および全体の方針 （１）サブクエリ無しでJOIN （２）INで非相関サブクエリ （２）の補足：サブクエリを「関数」と考えてみよう （３）EXISTSで相関サブクエリ 他のサンプル 巨大SQLの読み方 サンプルデータ，および全体の方針 まず，相関サブクエリの説明のために，以下のようなテーブルを例として取り上げる。 table1が，普通のデータ table2が，マスタデータ（ホワイトリスト） 「マスタに一致しないレコードをはじく」という操作をしたい。 方法は３パ
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RとSQLを対応付けてみた - あらびき日記
TECHSCORE - Java,SQLプログラミング技術解説
リレーショナル・データベースの世界