NOT IN (NULL) に苦しめられる昼下がり sql文のnot inとnull | アララグループの技術者ブログ 上記リンクの方々のように NULLを含むサブクエリの結果などをNOT INに渡した場合、 期待していたクエリの結果が得られないことがある。 検証 postgresql(9.6.1)で確認 以下のテーブルを準備する --日本で作ってるフルーツ一覧 CREATE TABLE japan_fruits (name VARCHAR(10)); INSERT INTO japan_fruits VALUES ('りんご'),('ぶどう'),('みかん'); --フィリピンで作ってるフルーツ一覧 CREATE TABLE Philippines_fruits(name VARCHAR(10)); INSERT INTO Philippines_fruits VALUES ('バナナ'
概要 全般 推奨 非推奨 命名規則 通則 表 列 別名、相関名 ストアド・プロシージャ 統一的接尾辞 問合せ文 予約語 空白類 インデント 望ましい形式 Create文 データ型の選択 デフォルト値の指定 制約とキー 非推奨設計 付録 予約語リファレンス SQLスタイルガイド（日本語訳） 日本語訳について 日本語訳は誤訳や原文の最新版に追随していない恐れがあります。誤訳や改善点があれば、GitHubのissueまたはpull requestを使用するか、Twitterでお知らせください。 翻訳: 久利史之 @nkuritw 概要 このガイドラインは利用の他、forkしたり、自分自身のものに改変したりすることができます。ここで大事なのはスタイルを選択しそれを踏襲することです。変更の提案やバグの修正にはGitHubのissueまたはpull requestを使用してください。 このガイドライン
こんにちは、エンジニアリングGの池田(@progrhyme)です。 エムスリーではこれまでエンジニアの集団研修を実施しておりませんでしたが、昨年度に続き新卒採用のエンジニアが若干名入社したことをきっかけに、新人研修を企画して実施しました。 手探りではありましたが、最終的に5〜7月にかけて12本の講義を実施し、のべ250以上の受講数*1を達成することができました。 本記事では、その内容の一部を紹介し、簡単に振り返ってみます。 コンセプト 最初の企画段階で、新卒エンジニアメンター陣とミーティングを行った際に、以下のような大まかな方針が決まりました。 新卒入社者だけでなく、中途入社者でも希望者は誰でも参加できるようにする。 以下のようなコンテンツを用意する: Webエンジニアとして幅広い人に必要な基礎知識 → 「Webエンジニア基礎編」 エムスリーエンジニアとして必要な社内知識 → 「エムスリー
今回は、あまり見かけないようで意外と必要になる「複数のテーブルに対して多対一で紐づくテーブル」の設計について、4つのアプローチをご紹介します。 どのようなケース？あるテーブルが複数のテーブルのいずれかに対して、自身が多、紐付き先が一で関連する場合のテーブル設計です。 例えば、「記事」と「画像」を投稿できるようなSNSを想定します。 この時、閲覧者が投稿された「記事」と「画像」のどちらにも「コメント」をつけることができる機能があったとします。 このような場合に、どのようなテーブルの設計方法があるのか、以下から説明していきます。 1.ポリモーフィック関連SQLアンチパターンにも登場するこの設計方法。「どのテーブルのどのレコード(id)に紐づくのか」という情報をテーブルに持たせてしまうという方法です。具体的には以下のような設計になります。 comments.target_tableに関連する対象
PostgreSQL9.1の仕様変更にて、デフォルト時の設定として、standard_conforming_stringsがonとみなされるようになりました。この仕様変更により、デフォルト設定でのPostgreSQLは、バックスラッシュをエスケープする必要がなくなり、ISO規格のSQLと同様のエスケープルール（シングルクォートを重ねるのみ）となります。 PostgreSQLの文字列リテラルは、元々MySQL同様に、バックスラッシュをエスケープする仕様でした。その後、リリース8.1にて、設定パラメータ standard_conforming_strings が追加され、この値が on の場合、バックスラッシュをエスケープしない（ISO規格と同様の）仕様となりました。従来のリリースでは、standard_conforming_stringsを指定しない場合offとみなされていました。これは、後
2016/08/26 CEDEC 2016
こんにちは！井上です。 EF＆LINQでちょっと複雑なSQLを書きたいときのメモ。 環境 .NET Framework 4.5.1 Entity Framework 6 MySQL 5.6 C# こちらの続きです。 tech.sanwasystem.com 複数テーブルの結合（INNER JOIN） var lists = db.TableA .Join(db.TableB, a => a.id, b => b.id, (a, b) => new { a.id, a.value1, b.value2 }) .Join(db.TableC, ab => ab.id, c => c.id, (ab, c) => new { ab.id, ab.value1, ab.value2, c.value3 }); 結合を先に書くパターン var lists = db.TableA .Join(db.T
YAP(achimon)C::Asia Hachioji 2016midの資料です。
PostgreSQLは寿司ビール問題を解決する（unicode 6問題について）
TwitterでMySQL と寿司ビール問題ってのが話題になりました。 MySQLと寿司ビール問題 結論から言うとMySQLでは指定されてた文字コードによっては あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。 — とみたまさひろ (@tmtms) 2014, 12月 22 ってなる話です。 詳細については前述のブログで触れられていますがMySQLとしてはバグではなく仕様だそうです。 でふーんって思って見てたら MySQLの「寿司とビール」問題、面倒臭いね。「PostgreSQLならそんなことはないよ」って言われたら使うの検討するレベルにイヤな感じ。 — 長谷川智希@とむぞう (@tomzoh) 2015, 3月 23 と長谷川さんが仰ってるのを
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
このエントリでは、Time-based SQLインジェクション、すなわち時間差を利用したSQLインジェクションが意外に実用的だったという報告をします。デモ映像ありです。 はじめに Time-based SQL Injectionという攻撃があります。これはブラインドSQLインジェクションの一種で、ある条件の場合に一定時間（例えば5秒）スリープし、そうでない時との応答時間の差で情報を盗もうというものです。1回のHTTPリクエストで1ビットの情報が得られるので、それを積み重ねることによって、いくらでも情報を盗めるはずです…理論的には。 しかし、「理屈はそうでも、時間が掛かりすぎるよね」ということで、深くは追っかけていませんでした。SQLインジェクションの検査には有効でも、悪用としての実用性はあまりないと考えていたのです。 きっかけ きっかけは、以下のYahoo!知恵袋に以下の質問です。 SQL
7. 通常のWebサーバとの通信 <html> <body> <form action=“register” method=“POST”> 氏名:vultest<BR> メールアドレス:vultest@example.jp<BR> 性別:男<BR> （以下略） </html> POST /confirm.php HTTP/1.1 Host: example.jp （以下略） Cookie: PHPSESSID=xxxxxxxxxx name=vultest&mail=vultest%40example.jp&gender=1 HTTP Response HTTP Request 8. 色々いじってみてどういう応答があるか確認 POST /confirm.php HTTP/1.1 Host: example.jp （以下略） Cookie: PHPSESSID=xxxxxxxxxx name
ISDATE関数の実行例 SELECT ISDATE('2008-12-31') /* → 1 (有効) */ SELECT ISDATE('2008-12-32') /* → 0 (無効) */ 現在時刻(GETDATE、CURRENT_TIMESTAMP、GETUTCDATE等) 現在の日時を取得するには、GETDATE関数、CURRENT_TIMESTAMP関数を使用します。これらの関数はタイムゾーンに設定された時刻(日本時刻)を返します。これに対し、GETUTCDATE関数は協定世界時を返します。 SQL Server 2008からは、SYSDATETIME()、SYSDATETIMEOFFSET()、SYSUTCDATETIME()といった関数を使用して、より精度の高い現在日時を取得することができます。 GETDATE関数、CURRENT_TIMESTAMP関数、GETUTCDA
3. はじめに このセッションではSQL Serverのことを扱います 重要なキーワードは緑字にします 自己紹介 大人の事情で本名と顔をだしていません Microsoft MVP for SQL Server 2011- トラブル対応が主食のデータベースエンジニアです Twitter: elanlilac Blog: http://elan.blog.so-net.ne.jp/ 誰得情報を垂れ流しています 4. はじめに 愚者は経験に学び、賢者は歴史に学ぶ（オットー・フォン・ビスマルク） Nur ein Idiot glaubt, aus den eigenen Erfahrungen zu lernen.Ich ziehe es vor, aus den Erfahrungen anderer zu lernen, um von vorneherein
思いのほか前回のRailsプチ・デザインパターンの紹介に反応があったので、こういう小ネタも出していったほうがいいのかな、ということで第二弾。 ソーシャル系アプリだと、ユーザとユーザを関連付ける多対多のモデルがたくさんでてきます。たとえば、一般的なところではフォローとかブロックとか足あととか。さらにデーティングサイトになると、ウィンクだったり、Secret admirer（こっそりlikeするけど両思いだったらおめでとうって通知がくるってやつ）だったり、いろいろなモデルがこのパターンにあてはまります。 この場合、「AがBをフォローしている」「BがAをフォローしている」「AとBがお互いにフォローしている」という3つの状態があるわけですが、相互フォローの状態は「AがBをフォローし、かつBがAをフォローしている」と読み替えてSQLでも記述可能なので、以下ではシンプルに単方向のグラフで全てを扱うもの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
