SQLで羃等にDBスキーマ管理ができるツール「sqldef」を作った - k0kubun's blog
sqldefのリポジトリ github.com これは何か Ridgepoleというツールをご存じでしょうか。 これはRubyのDSLでcreate_tableやadd_index等を書いてスキーマ定義をしておくとそれと実際のスキーマの差異を埋めるために必要なDDLを自動で生成・適用できる便利なツールです。一方、 で言われているように、Ridgepoleを動作させるためにはRubyやActiveRecordといった依存をインストールする必要があり、Railsアプリケーション以外で使う場合には少々面倒なことになります。*1 *2 そこで、Pure Goで書くことでワンバイナリにし、また別言語圏の人でも使いやすいよう、RubyのDSLのかわりに、誰でも知ってるSQLでCREATE TABLEやALTER TABLEを書いて同じことができるようにしたのがsqldefです。 使用例 現時点ではMy
State of SQL Antipatterns in 2017
2017/07/10 SQLアンチパターンNight Part2 https://connpass.com/event/59946/
SQL実践入門──高速でわかりやすいクエリの書き方 - kagamihogeの日記
俺は実務経験をある程度こなしたあと、RDBの知識不足を認識したクチである。改めてRDBを勉強し始めて困ったことの一つは、実行計画の読み方がよくわからないことだった。もちろん、ぐぐればNESTED LOOP JOINが何かとかは出てくるし、公式のマニュアルも参考になる。ただ、webの文献は体系だって解説があるとは限らないし、個人のブログなどは粒度がバラバラで、まとまった量の知識を得るには向いていない。マニュアルも膨大な量があるので慣れていないと目的の文書が書いてあるかどうかすら分からないし、あったとしても必要なレベルの解説があるかどうは分からない。 そこで本書の出番である。既存の書籍にもSQLとパフォーマンスを論じたものはあるにはあるのだが、それに特化した本の存在は、少なくとも俺は知らない。一冊だけ、データベースパフォーマンスアップの教科書 基本原理編 - kagamihogeの日記という極
Time-based SQL Injectionは意外に実用的だった
このエントリでは、Time-based SQLインジェクション、すなわち時間差を利用したSQLインジェクションが意外に実用的だったという報告をします。デモ映像ありです。 はじめに Time-based SQL Injectionという攻撃があります。これはブラインドSQLインジェクションの一種で、ある条件の場合に一定時間（例えば5秒）スリープし、そうでない時との応答時間の差で情報を盗もうというものです。1回のHTTPリクエストで1ビットの情報が得られるので、それを積み重ねることによって、いくらでも情報を盗めるはずです…理論的には。 しかし、「理屈はそうでも、時間が掛かりすぎるよね」ということで、深くは追っかけていませんでした。SQLインジェクションの検査には有効でも、悪用としての実用性はあまりないと考えていたのです。 きっかけ きっかけは、以下のYahoo!知恵袋に以下の質問です。 SQL
「SQLパフォーマンス詳解」という本を翻訳しました | b.l0g.jp
「SQLパフォーマンス詳解」という本を翻訳しました 2015-04-07 題の通り、「SQLパフォーマンス詳解」(原文タイトルSQL Performance Explained)という本を翻訳しました。PDF版と印刷版が上記サイトから購入できます。 (追記 2017年9月から、渋谷のBOOK LAB TOKYOさんでも印刷版を販売していただいています。輸送コストの関係で、サイトから購入するより若干安くなっています) リレーショナルデータベースにおいて、SQLとインデックスがどのように関連し、どのようにすればSQLのパフォーマンスを良くできるのかを解説した本です。特定のデータベース製品に焦点を当てた本は多数ありますが、この本ではOracle Database、PostgreSQL、MySQL、SQL Serverの4つのメジャーなリレーショナルデータベース製品を同時に扱っていて、それぞれのク
SQLデータベースに正しインデックスを作るのは 誰の役割？
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
SQLインジェクション対策に正解はない
最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ
SQLのエスケープ
(Last Updated On: )SQLにエスケープなんて必要ないと考えている方も居るとは思いますが、現実にはエスケープを知っておくことは必須と言っても構わないと思います。 既にSQL識別子のエスケープについては書きましたが、今回はSQLエスケープというよりは安全にSQLデータベース利用する話です。先ずはエスケープの話を全て終わらせよう、と思っているのですがSQLエスケープのエントリが無いので作りました。私のブログを読んでいる方はエスケープ処理、プリペアードクエリの利用方法などはよくご存知だと思うのでここの部分は省略しています。 現在広く利用されているSQLデータベースのほとんどがプリペアードクエリをサポートしています。プリペアードクエリを利用すれば、SQL文とパラメーターを分離できるため、パラメーターがSQL文の一部として解釈されてしまう問題を回避できます。 プリペアードクエリを使う
sqlのwhere in って、複数条件(カラム)を指定できるんですね - end0tknr's kipple - web写経開発
http://blog.fusic.co.jp/archives/1765 ↑postgresの記事ですが、mysqlでも同様に実行できました。 SELECT * FROM test_table WHERE (col,co2) IN -- 複数のカラムを指定 (SELECT subcol1,subcol2 -- 副問いの戻り値も複数のカラムを指定 FROM subtable WHERE id > 10 ) 知らなかったなんて、お恥ずかしい ※手元にあるmysqlはv.5.1.61ですが、v.4.1から使えるらしい sqlの仕様として、mysqlのdocでは分かりませんでしたが、sql99から利用可らしい http://dev.mysql.com/doc/refman/5.1/ja/comparison-operators.html ↑では、分かりませんでしたが、次のurlよれば、sql99
Norikra: Stream processing with SQL for everybody
Schema-less Stream Processing with SQL Norikra is a open source server software provides "Stream Processing" with SQL, written in JRuby, runs on JVM, licensed under GPLv2. Schema-less event streams (called as 'target') Input/Output event streams as JSON objects, which can contain any fields with a target name. SQL processing Norikra's query is SQL with window specifier support (It's actually Esper
SQLアンチパターン - ナイーブツリー
社内勉強会資料 追記: 2013-10-31 ついったで指摘( https://twitter.com/akuraru/status/395822183777202176 )を受けたので入れ子集合のノード追加の説明の所を修正しました。
JOIN禁止と固定長カラムについて - SQLer 生島勘富 のブログ
あまりに気になったので「山本大＠クロノスの日記」にチャチャを入れてみる。 http://d.hatena.ne.jp/iad_otomamay/20110808/1312805917 http://d.hatena.ne.jp/iad_otomamay/20100906/1283786846 まあ、政治的にはどのみち勝てなかったでしょう。私も同じ条件であれば、一応は説得を試みるけれど返り討ちに遭うと思う。いずれにしても結果は同じですが、教えられたと思っているなら間違いです。 結論はいつものとおり「下手糞が居るから」に行き着くのですが……。 JOIN禁止について 「JOIN禁止」が正しい場合がある。 それはJOINされるデータがアプリケーションサーバにキャッシュされていて、その一貫性が何らかの形で保証されている場合。 そもそも、せっかくキャッシュしているのに、それを使わずにJOINして取り直
qpstudyで発表したスライドをアップロードしました。
本日、qpstudyで「データベースとは」という内容について、そして「リレーショナルモデルとは」という内容について話す機会を頂いた。リレーショナルモデルという硬い内容であったにも関わらず、出席者の皆さんには最後まで良い反応をして頂けたように思う。実はリレーショナルモデルについて誤解している、あるいは知らない人が本当に多い、そして良い解説書がないということを普段問題として感じており、そういった背景から今回qpstudyの話を引き受けさせて貰った。今回発表した内容が皆さんのお役に立てば幸いである。 発表の内容はほぼ現在WEB+DB PRESSで連載している「理論で学ぶSQL再入門」のいくつかの回のものを要約したものになっている。連載ではさらに詳しい内容について説明しているので、興味のある人はぜひWEB+DB PRESSのバックナンバー（連載はVol.68〜）を購入して頂きたい。 本日発表したス
The annotated table of contents
Preface — Why is indexing a development task? Anatomy of an Index — What does an index look like? The Leaf Nodes — A doubly linked list The B-Tree — It’s a balanced tree Slow Indexes, Part I — Two ingredients make the index slow The Where Clause — Indexing to improve search performance The Equals Operator — Exact key lookup Primary Keys — Verifying index usage Concatenated Keys — Multi-column inde
新著が出ます：ジョー・セルコ『プログラマのためのSQL 第4版』 - ミックのブログ
皆さん、お久しぶりです。長らくブログの更新が止まっていたのは、少し大きな仕事をしていたためです。ジョー・セルコ『プログラマのためのSQL 第4版』の翻訳。これに集中するため、ブログもやらずTwitterもやらず（こっちはちょっとやってしまった）頑張っておりました。 長かった。 本当に長かった。 原著が800ページ以上あるうえ内容も簡単ではないので、もともと楽な仕事とは思っていませんでしたが、いや大変でした。ですが無事今月刊行とあいなりました。すでにAmazonはじめオンラインショップでも予約受付を開始しています。あらかじめ言っておきますが「表紙のおっさん誰？」という質問は私にはしないように。私も答えられないので（笑）。 さて、本書の内容を紹介する代わりに、少し長くなりますが訳者前書きを引用します。購入するか判断の参考にしていただければと思います。なお、実行環境としては前書きでも書いています
RDBMSに関する典型的な誤解が絶えないという現実
新入社員必読、データベースの基本を理解しよう - データベースはなぜ必要なの？：ITproという記事に対するブクマで次のようなIDコールが来た。（現在はコメント返しへのお礼が入っているので、文字数制限のためオリジナルのコメントは少し切り詰められている。） "リレーショナルデータベースはすべてのデータを2次元の表形式で表現"こういうのもリレーションが2次元構造という誤解の一種なんだろうか。id:nippondanjiさんが書いてたような。 さて、この疑問に対する正解は如何なるものだろうか？ つい先日「7つのデータベース 7つの世界」の書評で書いたばかりだが・・・ 言うまでもなくその通りである。 リレーションが2次元的な構造を持っているというのは典型的な誤解だ。（ちなみにリレーションの次元は属性の数に等しい。n個の属性があるリレーションはn次元。）リレーショナルモデルについてちゃんと学習してい
introduction_to_only_SQL
当日の中継も以下でご覧いただけます。 http://www.ustream.tv/recorded/8146586
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQL and Relational Theory, 2nd Edition
Osquery
リレーショナル・データベースの世界