分析SQLのコーディングスタイル - クックパッド開発者ブログ
SQL、書いてますか？ こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、 分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。 そこでちょっと気になるのが、 SQLのコーディングスタイルってどうするのが一般的なんだっけ……？ という点です。 イマドキはSQLなんてO/R mapperに吐かせることが多いからなのか、 それともコードを広い範囲で共有することがそもそもないからか、 SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、 いまいち決定版と言えるスタイルがないなと感じています。 そんなわけで本日は、SQLのコーディングスタイルについての意識を活発化させるべく、 クックパッドでわたし（青木）が使っているコーディングスタイルから特徴的な点を紹介したいと思います。 特に、分析
PostgreSQLのアンチパターン : 何でもかんでもjsonに入れる | Yakst
PostgreSQL 9.2より追加されたJSON型だが、特徴を理解して適切に使わないと色々な副作用に悩まされることになる。その問題点を挙げると共に、どのような場合に使うべきかの指針を示す。 PostgreSQLは、データ型としてjsonをサポートしています。しかし、やりたいことがある時に何でもかんでもjson型を使ってしまうというのはやめるべきです。これは、hstoreや新しく登場したjsonb型にも同じことが言えます。これらの型は必要な時には便利なツールになりますが、PostgreSQLでデータのモデリングを行う際に最初に検討すべきものではありません。 なぜなら、データを呼び出したり操作したりするのが難しくなってしまうためです。 何もかも同じところに入れてしまおうとすることによるアンチパターンをご存知の読者もいるでしょう。EAVアンチパターンは、長らくデータベーススキーマにおける必要悪
SQLインジェクションは本当に避けられないのか - ドクジリアン柔術少女 すから☆ぱいそん - ワルブリックス株式会社
ありもしない完全な代替品を求めるよりも、より現実的な選択肢を改善することについて。 SQLからなるべく乖離しないでDRYを実現するっていうScalikeJDBCの落としどころが素晴らしい。「結局のところSQLは書かなきゃいけんねん」「SQLよりつぶしの効くRDB操作用言語は存在しえないねん」っていうORMの教訓を経てきた人類はここに到達したって感じで。 — 嶋田大貴 (@shimariso) 2014, 11月 21 というツイートをしたところ、 何をいうか。必ずORMを使うべきだ SQLは根本的にSQLインジェクションを回避できない問題がある みたいな趣旨の反応があったのだけれど、前者についてはWikipediaのここ を一読いただくとして、後者についてはプログラミング言語のほうが発達してて状況が違ってきてるよという話をしたい。 誤解しないでいただきたいのは、別にSQLが良いものであると
僕はSQLをこう学んだ | mah365
いくらRDBの操作を抽象化してくれる便利なライブラリ（ORマッパーとか）を使っていても、それでもRDBを使う限りは、テーブル設計の考え方にしろ抽出ロジックの考え方にしろ、SQLを知っていないとやりづらいと思うのです。 でも正直、「SQLこう学べば一発でわかるようになるよ」と言えるほど教えるノウハウはない。なので、僕がどうSQLを勉強したか書いておこうと思います。 正直、情報処理の試験で問われるまでSQLを使う用事がなかった プログラミングの歴だけは長いのですが、SQLを勉強する必要が出たのは、新卒で入社した会社で「ソフトウェア開発技術者（現・応用情報処理技術者）を取りなさい」と言われてからです。 いきなりお勉強的なムードからSQLを学ぶ必要が出てしまったので、最初は全くやる気にならなかった・・・ので、これはいかんと思って、何とか手を動かそうと思って、手にとったのがSQL書き方ドリルという本
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
nabokov7; rehash : O/Rマッパーはなぜ悪か
December 07, 201208:49 カテゴリプログラミングmysql O/Rマッパーはなぜ悪か タイムラインで「SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か？」ってのを見かけて居ても立ってもいられなくなったので、既出を承知で反論しておきたい。 スライドだけから話の内容を推測すると、 -- 販売成績上位10個を抽出 select * from sales where deleted = false order by amount desc limit 10 といったSQLを Sales.active().top(10).all() のように、細かく分解した部品を組み合わせて表現できた方が便利だし構造的でしょ？という話のようだ。 これは確かに一見美しいのだが、これこそが「敷居を下げすぎて、dbの性質を分かってない人まで気軽にSQLをいじるようになった結
INをEXISTSに書き換えると速くなるサンプルSQLを作るのは難しい - 極北データモデリング
「INをEXISTSに書き換えると速くなる」という話が、DBMSやそのバージョンを限定せずにSQL一般の話として語られることがあるけど、実感としてそれはないだろうと。 そこでどういう場合に速くなるのか確認しようと思ったけどうまくいかなかったので、どういう場合に速くならないかを書いてみます。 速くならない(1) - 同一の実行計画になる SQL Server 2005で以下のSQLを流すと、IN/EXISTSで同一の実行計画が出てきた。 IN select count(*) from 受注 t where 商品CD in (select 商品CD from 商品) EXISTS select count(*) from 受注 t where exists (select * from 商品 where 商品CD=t.商品CD) 実行計画 |--Compute Scalar(DEFINE:([
fkino diary(2007-05-27)
_ Seasar Conference 2007 Spring Seasar Conferenceに行ってきました。というか、参加したセッションはほとんどスタロジカンファレンス(?)でした。(^_^;) Seasar Conferenceへの参加は今回で3回目(皆出席)ですが、過去2回に比べても今回は非常に有意義でした。 Web2.0時代のDB設計 〜RDB meets URL〜 RDBMSによる閉塞感 ベンダーにロックインされる Javaによる閉塞感 気が重い レンタルサーバーで動かない Next COBOL < J2EEはメインフレームのリプレースのための規格 システム要件による閉塞感 DBは経営資源というけれど、活用できていない そこでREST RESTfulDao S2DaoをREST化 リソース系テーブルに価値がでてくる id:t-wadaさんがDHHにインスパイアされた(去年の
SQL書き方ドリルに「反復学習ソフト」が付きました！｜gihyo.jp
編集部注） 紹介書籍『改訂新版 反復学習ソフト付き SQL書き方ドリル』は，5月18日発売予定です。 『改訂新版 反復学習ソフト付き SQL書き方ドリル』は，SQLを開発の現場ですらすらと書けるようになるための学習書です。SQLの書き方をわかりやすく解説し，さらに豊富な練習問題を収録しているので，書く力を自分のものにするまで繰り返し学習することができます。今回，改訂にあたって反復学習ソフト「SQUAT」を付録としてCD-ROMに収録し，SQLマスターのための必読書としてますますパワーアップしました。 SQLマスターのポイントその1：「書き順」 本書では，基本的かつ実践的な35の例題を厳選して紹介し，どんなふうにSQLを書けばよいのか，考え方と書き順をわかりやすく解説しています。 考え方だけでなく，書き方を「書き順」として説明しているのがポイントです。データベースはコンピュータですから，SQ
suVeneのあれ: 俺的コーディングルール SQL編
2007年01月19日 俺的コーディングルール SQL編 プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。 原則キーワード小文字オブジェクト名大文字カンマは後ろインデントは半角スペースで 2一つの SQL 文でキーワード毎にインデントしない(副問合せ除く) まず、1.2. に付いてなのだが、昔は「キーワード＝大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押す
HAVING句の力：CodeZine
はじめに SQLというのは変わった言語です。こういう印象は人によって差があると思いますが、おそらく最初に手続き型言語を学んだ正統派のプログラマやSEほど強くそう感じると思います。 SQLに違和感を感じる理由は、いくつか考えられます。第一に、SQLが「集合指向」という発想に基づいて設計された言語で、この設計方針を持つ言語が少ないことです。そして第二に、それに劣らず大きいのが、最初に学んだ言語のスキーマ（概念の枠組み）が心理的モデルとして固定され、それを通して世界を見るようになるため、異なるスキーマを持つ言語の理解が妨げられることです。 本稿では、HAVING句のさまざまな応用方法を紹介していきますが、その際、手続き型言語とSQLの考え方を比較します。それによって、私たちが手続き型言語で身に付けた無意識の心理的モデルを自覚し、集合指向という発想に感じる違和感を軽減したいと考えています。 今回は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
O/Rマッパーによるトラブルを未然に防ぐ
Post by @objectclub
サービス終了のお知らせ
6月のはぶにっき