MySQLの自動変換を丁重にお断りするためのたった１種類の呪文 - sakaikの日々雑感～(T)編
先日の『これだけは覚えておきたい!!MySQL の６つの自動変換』 http://d.hatena.ne.jp/sakaik/20100225/mysqlautochange にはたくさんの反響をいただいた。 時にこちらの意図と違っちゃうこともあるけれどもケナゲに気を使ってくれる MySQL が、これほどに皆さんにも愛されていることが判り、MySQLファンの一人として嬉しい限りである。 さて、そのエントリの最後に、 なお、「SQLモード」を指定するとこれらの動作を変更することができる。SQLモードについては気が向いたらいつか紹介してみたい。 と書いたところ、速攻でキムラデービーの木村明治氏が補足エントリーを書いてくださった。 ○キムラデービーブログ [勝手に補足]これだけは覚えておきたい!!MySQL の６つの自動変換 http://blog.kimuradb.com/?eid=83851
JOIN禁止と固定長カラムについて - SQLer 生島勘富 のブログ
あまりに気になったので「山本大＠クロノスの日記」にチャチャを入れてみる。 http://d.hatena.ne.jp/iad_otomamay/20110808/1312805917 http://d.hatena.ne.jp/iad_otomamay/20100906/1283786846 まあ、政治的にはどのみち勝てなかったでしょう。私も同じ条件であれば、一応は説得を試みるけれど返り討ちに遭うと思う。いずれにしても結果は同じですが、教えられたと思っているなら間違いです。 結論はいつものとおり「下手糞が居るから」に行き着くのですが……。 JOIN禁止について 「JOIN禁止」が正しい場合がある。 それはJOINされるデータがアプリケーションサーバにキャッシュされていて、その一貫性が何らかの形で保証されている場合。 そもそも、せっかくキャッシュしているのに、それを使わずにJOINして取り直
地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。
INとEXISTSの違い - SQLer 生島勘富 のブログ
INとEXISTSは違います。 BETWEENと、不等号の組合わせなど、等価になる記述法はあるのですけれど、INとEXISTSは基本的に同じ結果を返すことが可能ですが、意味は違います。 この違いが分かるにはインデックスを理解する必要がありますので、まずは、インデックスのイメージをつけてください。 まずはイメージ ここでも、まずはイメージで考えましょうね。 あなたは先輩の結婚式の司会を頼まれましたとします。イロイロと準備がありますが、余興で歌を歌う人がいるとき、予めカラオケの番号を調べておくでしょう。 食事の間のBGMについては、ラブソングの入ったiPodをつないでランダムで流すことにしましょう。しかし、新郎新婦にとって（過去の恋愛経験上）都合の悪い曲があり、チェックしてはじいておくことにしました（なかなか、そつがない司会ですな）。 これらの処理をSQLにするならば……。 ■カラオケの番号を
動的SQLによる数独の超高速解法
Pinskiさんの記事は、「SQLで数独を解ける」ことを示したという点で評価できます。しかしながら、そのためのコードと実行時間が共に長大であるため、「SQLは面倒で遅い」という誤解を読者に与えかねません。本稿で紹介する方法で、誤解が払拭されることを期待します。 第1、2部と第3部の手法を簡単にまとめておきましょう。 第1、2部では、手続き的な記述、つまり、どうすれば数独の解が得られるかの具体的な記述によって数独を解いています。手続き的とは言っても、せっかく宣言型言語であるSQLを使うので、手順の各ステップはなるべく宣言的に記述するように心がけています。 第3部（本稿）の方法の本質はたった1行のSELECT文です。このSELECT文には「数独の解とはどういうものか」だけが記述してあり、その解を得るための具体的な方法はコンピュータが考えます。ただし、このSELECT文は人間が手で簡単に書けるよ
続:SQLのバインド機構は「エスケープ処理された値」をはめ込むのか - ockeghem's blog
前回のエントリSQLのバインド機構は「エスケープ処理された値」をはめ込むのか - ockeghem(徳丸浩)の日記に対応して、mi1kmanさんのブクマ経由で、訂正が出ていることを知った。 訂正内容 1ページ目を下記のように変更いたしました（2個所）。 バインド値はエスケープ処理した後にプレースホルダにはめ込むので、悪意あるSQL文が挿入されても、その実行を阻止することができる（図1-2）。 ↓ SQL文のひな型とバインド値は個別にデータベースに送られ、構文解析されるので、バインド値に悪意あるSQL文が挿入されても、その実行を阻止することができる（図1-2）。 http://www.impressit.co.jp/inside/?p=791 なんとなく私のエントリの断片が散りばめられているのを別にしても、『悪意あるSQL文…の実行を阻止することができる』というあたりに、サニタイズ的発想が依
女優とSQL
http://www.simple-talk.com/author/robyn-page/ イギリスの昼ドラにでている女優((もっともセクシーな新人にノミネートされたこともあるそうな))がSQL絡みの専門的な記事を書いていてgeekが小躍りしているようだ。 http://www.reddit.com/r/programming/comments/7hvn8/is_this_real_a_hot_tv_actress_that_writes_sql/ ソーシャルブックマークでは「マジかよ!ホットなTV女優がSQL Serverの記事を書いたぜ!」という記事が。 Not real. There are no girls on the Internet. (マジじゃないよ。インターネットに女の子なんていねーし。) So who shops at victoriasecret.com? (じゃあヴ
Index of /SQL
Index of /SQL NameLast modifiedSizeDescription Parent Directory - sql-2003-2-railroad-..>2024-02-04 17:51 5.3M sql-2003-2.ebnf 2024-02-04 17:51 172K sql-2003-2.ebnf.readme 2024-02-04 17:51 757 sql-2016-railroad-di..>2024-02-04 17:51 6.8M sql-2016.ebnf 2024-02-04 17:51 214K sql-2016.ebnf.readme 2024-02-04 17:51 663
オープンソースのデータウェアハウスシステム「CloudBase」 | OSDN Magazine
企業ディレクトリサービスの米Business.com（米R.H. Donnelley Interactive傘下）は10月24日（米国時間）、「Hadoop」ベースのオープンソース・データウェアハウスシステム「CloudBase」を公開した。ANSI SQLを利用して、フラットログファイルにクエリを実行できる。SourceForge.net経由でダウンロードできる。 オープンソースの分散コンピューティング技術であるHadoopのMap-Reduce実装を利用して、フラットログファイル上にデータベース抽出層を構築した。これにより、ANSI SQLを利用して、Webサイトなどのフラットログファイルに直接クエリを実行できる。複雑なリレーショナルデータベースクラスタなしにログデータを分析できるという。 当初、Business.comなど自社サイトのWebログ分析を高速化するツールとして社内開発した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Sql Antipatterns Strike Back
http://japan.internet.com/column/developer/20081111/26.html