はじめにCSV/TSVなどのテキストファイルをSQLライクに参照できる「q」というツールがあります。本ブログでも紹介したことがあります。CSV/TSVに対してSQL発行できるツール「q」 今回はこのqでS3に保存されているELBのログを分析してみたので、その手順を紹介いたします。 手順 まず、qを実行するためのEC2インスタンスを起動します。 リージョンはログが保存されているS3バケットと揃えた方が良いでしょう。 S3からログをダウンロードする必要があるので、起動の際にAmazonS3ReadOnlyAccess権限を持ったIAM Roleを付与してください。 インスタンスタイプやEBSサイズは分析するログの量に合わせて調整してください。 一時利用なので大きめのSpotインスタンスでも良いかもしれません。 インスタンスが立ち上がったらqをインストールします。 $sudo rpm -

Bill Karwin “SQL Antipatterns: Avoiding the Pitfalls ofDatabaseProgramming” の読書メモ。 Jaywalking 目的 ある属性について、複数の値を持たせる。 アンチパターン : カンマ区切りリスト カンマ区切りで複数の値を 1 つの列に納める。 例では、特定の製品についての担当者を複数設定するのにカンマ区切りで、担当者のアカウントIDを記述している。create table products ( product_id integer, product_name varchar(1000), acount_id varchar(100), -- comma separated list -- ... ); insert into products (product_id, product_name, accou
リレーショナルモデルを実践するには、ドメイン(≒データ型)を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性(≒カラム)に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その

どうしようもない僕に献本が降りてきた!SQLアンチパターン 作者: Bill Karwin,和田卓人(監訳),和田省二(監訳),児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 5人 クリック: 624回この商品を含むブログ (12件) を見る ありがとうございます。 結論を先に述べると、すごく読みやすくてためになる本です。RDB使ったシステムを作っている人、特に長年やって人ならば必ず遭遇したことがあるアンチパターンのカタログです。アンチパターンが発生しやすい状況、悪影響や解決方法なども述べています。若い人は現実のシステムで失敗する前に予習できるので、絶対買ったほうがよいでしょう。「この問題!進研ゼミでやったところだ! 」 自分は論理設計のアンチパターンのあたりがお気に入りです。アンチパターン「ポリモーフィック関連」や「エンティティ・ア

監訳の一人である @t_wada に献本頂きました。 ありがとうございます!!! でだ、いきなりだけどコレ、タイトルで損してると思うんだよね…… だって、SQL のアンチパターンてタイトルだったら、join した結果の方で where で絞るよりも on 句で先に絞れ 的なのが書いてあると思うじゃん!! 問い合わせ言語の事だと思うじゃん!!! 違った…… ほとんど書いてあるのはDB 設計についてだった…… まぁ、副題は「Avoiding the Pitfalls ofDatabaseProgramming」のだし、まぁいいか。 んで、読んでみた感想とか もうね、何年かDB 絡んだ開発したことのある人なら(・∀・)ニヤニヤ出来ると思う。 「”マルチカラムアトリビュート”とか 10 年前に通ったわー」 とか 「あーはいはい”インデックスショットガン”乙」 みたいな。 Explain
DB2 Express-C v9.7.2のWindows版で使えていたLIMIT/OFFSETが同Linux版で使えなくて、プラットフォームによって違うのかと思ってしまい、同等のことができる構文をいろいろと調べた挙句、インストール直後の設定が違っていただけという。 で、せっかくなので、調べたいろいろをまとめてみようということで。 ただDBごとに並べても面白くないので(謎)、構文ごとにまとめてみるというアプローチで(更謎)。 前提として、次のようなテーブルを作っておく。CREATE TABLE hoge(str VARCHAR(8)) INSERT INTO hoge(str) VALUES('bbb') INSERT INTO hoge(str) VALUES('ddd') INSERT INTO hoge(str) VALUES('fff') INSERT INTO hoge(str)
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNERJOIN →JOIN LEFT OUTERJOIN → LEFTJOIN RIGHT OUTERJOIN → RIGHTJOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSSJOIN。 こんなの使いません。 ブクマ用画像。

1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く