前書き インデックスの 内部構造 インデックス リーフノード 検索 ツリー(Bツリー) 遅いインデックス パートI where 句 等価 演算子 プライマリキー 複合インデックス 遅いインデックス パートII 関数 - where 大文字・小文字を区別する 検索 ユーザ定義 関数 インデックスの作り過ぎ パラメータ化 クエリ 範囲 検索 大なり、小なり、 BETWEEN LIKEフィルタに 対するインデックス インデックスの結合 部分インデックス OracleにおけるNULL NULLに対する インデックス NOT NULL 制約 部分インデックスを エミュレートする 処理しにくい条件 日付型 数値文字列 列の連結 スマートなロジック 数式 パフォーマンスと スケーラビリティ データ 量 システム 負荷 レスポンス タイムとスループット 結合 処理 入れ子 ループ ハッシュ 結合 ソートマ
この記事は MySQL Casual Advent Calendar 2013 の15日目の記事です。 今、空前の SQL エスケープブームみたいなので、このビッグウェーブに乗っかってみます。 でも面倒なのでセキュリティについての話はしません。カジュアル! 文字列リテラルとエスケープ MySQL では SQL 中の文字列リテラルは次のように表現します。 'abc' -- シングルクォートで括る "abc" -- ダブルクォートで括る 0x616263 -- 16進数 x'616263' -- 16進数 0b011000010110001001100011 -- 2進数 b'011000010110001001100011' -- 2進数 各表記で charset を指定することができます _utf8 'abc' _utf8 "abc" _utf8 0x616263 _utf8 x'6162
「44のアンチパターンに学ぶDBシステム」を読んでみて、とても優れたアーキテクチャ設計のアンチパターン集に思えた。 過去の経験上、あるあると思う箇所がたくさんあった。 感想をラフなメモ書き。 【元ネタ】 44のアンチパターンに学ぶDBシステム - give IT a try あなたの現場にも必ずあるDBシステムの"悪い例"が満載!「44のアンチパターンに学ぶ DBシステム」 | oracletech.jp 『44のアンチパターンに学ぶDBシステム』 - 虎塚 44のアンチパターンに学ぶDBシステム : 賢者の図書館 (Under Construction) : livedoor Blog(ブログ) 【本】SQLをしっかり学習したい人におすすめミック本。 | プラプラ式技術系 Access流! 【本まとめ】44のアンチパターンに学ぶシステム構築時の失敗パターン。もっとはやく言ってよーとな
自前で create table したい Django を使っていて Django の ORM はそのまま使いたいんだけど、create table は自前で行いたい場合があります。 良くあるのは、partition 切りたい場合とか。 MySQL の range partition を使うには Primary Key を 複合Primary Key にする必要があるのですが、Djangoは 複合Primary Key を許可していません。 なので、そのような場合は自前で create table文 を書いて実行する必要があります。 class PartitionExample(models.Model): log = models.TextField(verbose_name=u'ログ') created_at = models.DateTimeField(verbose_name=u'
追記: 最新情報はこちらです。 MongoDBが流行ってきてる風なので、これだけ読んでおけばMongoDBの雰囲気がわかるだろうってところを、日本語訳が終わっているところから集めてみた。 なるべく順に読めるように並べたつもりだけど、前後してるところもあると思うので、とりあえず読み進めるのをお勧め。 まず、何はなくとも、 コレクション (Collections) 次にコレクションを触るためのシェル。MongoDBのシェルというのは、RDBMSでいうとSQLを直接叩くところで、PostgreSQLのpsqlコマンド, MySQLのmysqlコマンドみたいなもの。 実際にMongoDBを使って開発する場合、直接MongoDBを操作するよりも、各言語(PHPとかRubyとかJavaとか)のマッパー経由で使うことが多いとは思う。しかし、SQLを知らないとO/Rマッパーを使いこなすのが難しいように、シ
SQLとNoSQLではどちらが優れているのか? グーグルの担当者がディベート(というより小芝居:-)を行ったセッション「Google I/O 2012 - SQL vs NoSQL: Battle of the Backends - YouTube」が公開されています。 (この記事は「SQL vs NoSQL、グーグルにおける戦い(前編)。Google I/O 2012」の続きです) スケーラビリティについて (NoSQL担当)あらゆる面で、こちらが高いスケーラビリティを提供している。 (SQL担当)そんな訳ないだろ。 (NoSQL担当)そんな訳あるさ。 (SQL担当)じゃあまず、Cloud SQLがどう使われているか紹介しよう。例えば「グーグルorgチャート」。グーグルの3万人の従業員について、組織内のつながりや仕事を示すアプリケーションだ。 社内では誰もがこのWebサイトを開いていて、
SQLとNoSQLではどちらが優れているのか? グーグルの担当者がディベート(というより小芝居:-)を行ったセッション「Google I/O 2012 - SQL vs NoSQL: Battle of the Backends - YouTube」が公開されています。 このセッションは、先々週開催されたGoogle I/O 2012で行われたもの。SQLとNoSQLには機能的にどのような違いがあり、どう使い分けるべきなのか、明確な説明が参考になります。 ハイライトを紹介しましょう。 クラウドにおけるデータベースのメリット グーグルのAlfred Fuller氏(NoSQL担当)。 クラウドはフォルトトレラントでメンテナンス不要、パッチも私たちが適用しており、利用者は運用について心配する必要がない、といったメリットがある。 データのレプリケーションや地域分散でデータも保全され、インターネッ
NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文:NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
eBayが、JavaScriptアプリケーションからSQL文のような形式でデータベースへの問い合わせを記述できるDSL(ドメイン固有言語)のql.ioを発表。オープンソースとして公開しました。 現在、多くのWebアプリケーションが、バックエンドとのデータのやりとりにHTTPをベースにしたAPIを用いています。しかし、WebベースのAPIによってデータを取り出すのは、プログラマにとって実は手間のかかることです。 例えば、キーワードを入力すると関連する商品の名前、詳細、購入者の評価をユーザーに表示する、というWebアプリケーションでは、まずキーワードでデータベースを検索して商品IDを取得し、今度はその商品IDをキーにして名前や概要、評価の情報を取得する、といったように、APIを繰り返し呼び出す必要があります。 ql.ioはこうした内容をSQLのように分かりやすい記述で実現するだけでなく、複数の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く