例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, data TEXT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First
SQLにおいて、サブクエリは可読性下がるからWITH句を使えという話をしばしば聞く。 ただ、最近あえてサブクエリで記述している人がいたので WITH句とサブクエリで何が違うか について考えてみた。 同じ抽出内容だが片方はWITH句、片方はサブクエリで書いた以下のSQLをベースに話す。 WITH句 WITH sub1 AS ( SELECT aaa ,bbb FROM tbl1 ) ,sub2 AS ( SELECT xxx ,yyy FROM tbl2 ) SELECT sub1.aaa ,sub1.bbb ,sub2.xxx ,sub2.yyy FROM sub1 INNER JOIN sub2 ON sub1.aaa = sub2.xxx ; サブクエリ SELECT sub1.aaa ,sub1.bbb ,sub2.xxx ,sub2.yyy FROM (SELECT aaa ,bb
はじめに 最近エンジニア界隈では「リーダブルコード」が話題なっていますね。 リーダブルコードでは、このような定理が紹介されています。 「コードは他の人が最短時間で理解できるように書かなければいけない。」 Dustin Boswell リーダブルコード P.3 より引用 皆さん、クソSQL1を読んだことがありますね？ クソSQLを書いたことがありますね？ 僕は、あります。 そこで、本記事ではどうしたらリーダブルなSQLが書けるかというアイデアを紹介します。 処理の流れの順に上から読めるようにする サブクエリを多用したSQLは複雑に絡み合った大きな複雑な塊になってしまいます。サブクエリを使ったSQLでは、処理の流れは上から下ではなく、ネストされた内側から始まります。しかも、必ず内側から読んでいけば理解できるかというとそうでもなくて、内側のクエリが外側のクエリの影響を受けていて、内側のクエリだけ
Although SQL is reasonably consistent in its implementations, there are several different dialects available with variations of syntax and grammar. SQLFluff currently supports the following SQL dialects (though perhaps not in full): ANSI SQL - this is the base version and on occasion may not strictly follow the ANSI/ISO SQL definition Athena BigQuery ClickHouse Databricks (note: this extends the s
📜 The SQL Linter for Humans¶ Bored of not having a good SQL linter that works with whichever dialect you’re working with? Fluff is an extensible and modular linter designed to help you write good SQL and catch errors and bad SQL before it hits your database. Notable releases: 1.0.x: First stable release, no major changes to take advantage of a point of relative stability. 2.0.x: Recode of rules,
最近、この説明を複数回したので記事にする。 要約 普段は 今北産業 派なのだが、3行考えるのが面倒なため、今後は大人の表現を使う。 「今北産業」をスタートアップ語にすると「マジ価値サマリー」になるらしい ちなみにここだけの話ですが、大人語にすると「要約」になります pic.twitter.com/Q8SflvBX7c— ところてん (@tokoroten) 2022年1月24日 画面に表示したい順(以下、表示順）は振る舞いの属性なので分ける 似たような振る舞いに関わる属性は別テーブルにわけると良い 普通に正規化しましょうって話。 表示順をカラムを追加して表現する よくあるテーブルは画面情報と合わせて表示順カラムがあるパターン。 こういうテーブルを作って SELECT * FROM items ORDER BY display_order_number; で表示順に取り出すパターン。 表示順
Configuring sql.DB for Better Performance という記事を知りました。 コネクションプールの大きさを制御する3つの設定を丁寧に解説されたとても良い記事です。 しかし、この記事で推奨されている設定については同意することができません。私が推奨する設定とその理由を解説していきたいと思います。 Limit ConnMaxLifetime instead of MaxIdleConns Allowing just 1 idle connection to be retained and reused makes a massive difference to this particular benchmark — it cuts the average runtime by about 8 times and reduces memory usage by ab
一般的にOracleなりRDBMSのパフォーマンスは、メモリでさばける量を超えると突然悪化すると言われる。その理由は、メモリで処理しきれていたものが、ディスクIOを必要とするようになるから、ということになる。よって、実際のところどの程度悪化するものなのか、を見てみる。また、コレが原因で痛い目を見たケースについても見ていく。 環境 Oracle Database Express Edition 11g Release 2をCentOS 6.4 x86_64上で動作 Oracle SQL Developer 3.2 準備 テスト用のテーブルを用意する。 drop table hoge purge; create table hoge ( hoge_id integer not null, hoge_value varchar2(16), constraint hoge_pk primary k
本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗（アンチパターン）があります。本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。日本語版では、MySQLのエキスパートとして著名な奥野幹也氏によるアンチパターンを収録。データベースに関わるすべてのエンジニア必携の一冊です。 本書への称賛の声 監訳者まえがき はじめに I部 データベース論
というのを作ってみた。(結構前に) https://github.com/nekokak/p5-SQL-Object コンセプトは 生のSQL（基本where句）をプログラマブルに結合出来るようにすることです。 （namespaceが微妙という説もあるけどSQL::Stringとかもにたようなもんだよね！） 使い方： use SQL::Object qw/sql/; my $sql = sql('foo.id=?',1); $sql->as_sql; # 'foo.id=?' $sql->bind; # qw/1/ $sql->and('foo.name=?','nekokak'); $sql->as_sql; # 'foo.id=? AND foo.name=?' $sql->bind; # qw/1 nekokak/ $sql->as_sql; # 'foo.id=? AND foo
DBIの泣き所 いわゆるLAMPないしそれに似た環境でウェブサービスばかり書いている方にはあまり実感がないかもしれませんが、あちらの現場ではOracleを、こちらの現場ではMicrosoft SQL Serverを、はたまた別の現場では組み込みのSQLiteを、といった受託系の仕事をしている人にとって、SQLの方言問題は避けては通れないもののひとつです。 典型的なところでは、たとえばSELECTで取得するデータの件数を制限したい場合、PostgreSQLなどでは「LIMIT ... OFFSET ...」のように書きますが、OracleではROWNUMを使いますし、MS SQL serverならSET ROWCOUNTやTOPを使います。また、いまでこそPostgreSQLとの互換性を確保するため「LIMIT ... OFFSET ...」と書けるようになっているMySQLにしたところで、
ある人材紹介会社に登録されている就業希望者と、その仕事のスキルの組み合わせを表現したものです。本当は、スキルコードも「01102」とかコードで表すのがよりリアリティがありますが、わかりやすさのためスキルの名前をそのまま使うことにします。このテーブルによれば、たとえば100番の人は会計、在庫整理、製造という3つの分野の技術を持っており、300番の人は製造のみの技術を持つ、ということになります。 さて、この会社にはいつもひっきりなしにクライアント企業から人材についての問い合わせが入ります。みなさん、この会社の対応オペレータになったつもりで、クライアントからの問い合わせ条件に合致する人材がいるかどうか、検索してみてください。 ①クライアントAからの問い合わせ 次のような条件であるとします。 条件：「製造」スキルを持っている人材 これは簡単ですね。スキルが1つだけであれば、WHERE句で条件を記述
まずは、各行について過去の直近の行を求めてみましょう。OLAP関数を使える実装ならば、リスト1のような簡潔な書き方で実現できます（実行結果は図1：注2）。 リスト1 過去の直近を求める（OLAP関数：現在のところ実装依存） SELECT sample_date AS cur_date, MIN(sample_date) OVER (ORDER BY sample_date ASC ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING) AS latest FROM LoadSample; 図1 リスト1の実行結果 cur_date latest -------- -------- 08-02-01 08-02-02 08-02-01 08-02-05 08-02-02 08-02-07 08-02-05 08-02-08 08-02-07 08-02-12
はじめに 私たちが通常、C言語やPerl、Javaなどの手続き型言語（またそれに基礎を持つ言語）を使ってプログラミングを行う場合、最も多用する基本的な制御構造が分岐とループです。この2つを使わずにプログラミングしろ、と言われたら、それはかなりきつい制約になるでしょう。腕試しや暇つぶしに試すにはおもしろいかもしれませんが、およそ実務的なコーディングは不可能になるに違いありません。 話は、SQLとデータベースの場合でも同じです。SQLにおいても、やはり分岐とループは非常に重要な役割を果たす機能であり、SQLプログラミングの際にこの2つの機能を欠かすことはできません。しかしながら、手続き型言語を使いこなすプログラマの多くが、なぜかSQLを使う段になると思い通りの制御構造を記述できないことに苛立ちを感じ、結果、非効率的なSQL文が多く生み出されています。これはなぜでしょう？ SQLで分岐とループを
2008年02月03日04:00 カテゴリ書評/画評/品評Lightweight Languages 書評x3 - SQL本三大対決 404 Blog Not Found:この発想はなかった - 書評 - 逆算式SQL教科書を書いたら、「いや、うちも」とばかりにどっさりSQL本が来た。 まずオライリー・ジャパンの矢野様からは、「STATISTICS HACKS(和訳)」と一緒に「SQLクックブック」と「SQL Hacks 」を、そしてC&R研究所の吉成様からは「SQL実践活用大事典 」を献本いただいた。 これだけ頂くと、まとめないわけには行かないだろうということで、まとめてみた。 まず、「SQLクックブック」。こちらは申し訳ないのだけど、かなり期待はずれ。確かに「逆算式SQL教科書」よりは用例も多かったのだけど、Cookbookを特徴づけていた綿密なDiscussionがスカスカ。他ならと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く