タグ

sqlに関するyukungのブックマーク (31)

  • 「理論から学ぶデータベース実践入門」を読破するための参考資料 - 周回遅れのブルース

    先日来、ずっと「理論から学ぶデータベース実践入門」を読んで勉強中です。 私はどちらかと言えば下流メインで DB設計に関しては意見できる程度ですが、それでもSQLは割と書く方だしDB関連書籍もいくつか読んでたので、それなりに判ってたつもりでした。だけに、読めば読むほど、今まで RDBDB設計についてどれだけ勘違いしてたのか、つくづく身につまされる思いです。むかし「1ページに1度、あなたは激しくうなずく」とかいって宣伝してるありましたが、この読んでると、5ページに1度は、「おお、そうだったのかー!」と仰け反るような記述が出てくるので、当に驚かされますね。 理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus) 作者: 奥野幹也出版社/メーカー: 技術評論社発売日: 2015/03/10メディア: 単行(ソフトカバー)こ

    「理論から学ぶデータベース実践入門」を読破するための参考資料 - 周回遅れのブルース
  • 理論から学ぶデータベース実践入門(第二章) - 周回遅れのブルース

    ※前日のエントリの続きです。 引き続き、第二章を読んでみた。第二章は「述語論理とリレーショナルモデル」だそうですが、早速こんなこと書いてある・・・ 論理学に触れない正規化の解説は、でたらめだと言っても過言でありません どんだけー!そこまで言って委員会っ!! 理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus) 作者: 奥野幹也出版社/メーカー: 技術評論社発売日: 2015/03/10メディア: 単行(ソフトカバー)この商品を含むブログ (20件) を見る 以後、命題論理、述語論理、集合論と、学校で学んでないことばかり出て来るため*1、頭がくらくらしてきましたが、たまたま先月ペゾルトの CODE 読んでたので*2、理解とまではいかないけど辛うじて振り落とされずにニュアンスだけでも感じとることが出来ました。ペゾルトさんありがと

    理論から学ぶデータベース実践入門(第二章) - 周回遅れのブルース
  • 書籍出版のお知らせ:理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL

    来る2月27日、データベースの新書籍を発売させて頂くことになった。タイトルは「理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL」となっている。単に「データベース」と書いてあるが、RDBがメインのテーマの書籍である。 多くの人が未だにRDBを使いこなせていないのではないか。RDBの使い方をマスターするには何が必要なのか。それがここ数年私が追ってきたテーマであり、この書籍を出すことになった動機である。 あまりにも酷いDB設計、あまりにもスパゲティなクエリ、あまりにも希薄なデータモデルへの理解。そういった問題はどこから生み出されるのか。そのひとつの結論としてたどり着いたのが、「そもそもRDBの使い方があまり理解されていないのではないか」ということだった。名著、SQLアンチパターンでは「やってはいけないケース」について学ぶことができるが、その反対のテーマ、つまり来どの

    書籍出版のお知らせ:理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL
  • 新著が出ます:『SQL実践入門』 - ミックのブログ

    4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にしたで、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、当は実行計画などという手続レベルの世界をユーザが覗き見るのは、末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。

    新著が出ます:『SQL実践入門』 - ミックのブログ
    yukung
    yukung 2015/03/30
    RDB周り最近たくさん本出て追いつくの大変だけどちゃんと読もう。
  • SQLのUPDATE文と履歴系テーブル - mike-neckのブログ

    大したことは書いてありません。 気付いたことのメモ程度です。 『理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus) 』を少し屋で立ち読みしました。(ノットワーキングプアにあえいでいるので立ち読みしかできない(´・ω・`)) このの中で履歴系テーブルの扱い方というのに丸々一章が割り当てられていました。 だいたいこんなことが書かれてたと思う。 「時間軸と直交していない」という点は、履歴テーブルは過去の事実の集合で、データを取得する条件が変われば結果が異なるのは当たり前だと思うんだけども。— enum (@enum) 2015, 3月 16 たしかに、RDBMSでは履歴データというのは相性が悪い。 僕は陸上競技を見るのが好きなので、これのデータモデルをたまに考えたりしています。で、選手の氏名が変わることあるよなーと考えると、こ

    SQLのUPDATE文と履歴系テーブル - mike-neckのブログ
  • SQLアンチパターン「健忘症的サロゲートキー」の提案 - 極北データモデリング

    SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る書の著者はサロゲートキーに対して消極的なのだから、「サロゲートキーの使い方がおかしい」とか言うのはお門違いなのかもしれないが... 健忘症的サロゲートキー 「SQLアンチパターン」第3章の記述を総合すると、著者はサロゲートキーについて以下のように考えていると思う。 自然キーの一意性・不変性が当てにならない場合に「自然キーの変更の影響を受けないようにする」という目的でサロゲートキーを導入する。 自然キーの重複を防ぐために、自然キーにUNIQUEインデックスを振ることを推奨する。 自然キーの代わりにサロゲートキーを外部キーにする。自然キーは他のテーブルに転

    SQLアンチパターン「健忘症的サロゲートキー」の提案 - 極北データモデリング
  • SQL Fiddle - Online SQL Compiler for learning & practice

    During Phase 1, only users who are logged in can access the AI chat feature. SQL Fiddle is free to use and ad-free! Want to help us? It takes 10 seconds Step 1: Like & Share our EFE Bulk Extensions videos Step 2: Like & Share our EFE Bulk Insert videos Thank During Phase 1, only users who are logged in can access the AI Editor feature. SQL Fiddle is free to use and ad-free! Want to help us? It tak

  • http://blog.1000k.net/2010/11/15/mysql5-1%E3%81%AEboolean%E5%9E%8B%E3%82%92%E6%A4%9C%E8%A8%BC/

  • SQL の命名規約とフォーマット - ぐるぐる~

    ときどきの雑記帖さん経由で、私のSQLフォーマットをみて、自分の規約もさらしてみる*1 *2。 命名規約 テーブルやビュー、共通表式は Pascal 記法で、複数形とする*3。例えば、Employees とか Works とか ただし、リレーションテーブルはその限りではない。例えば、EmployeeWork とか カラム名はアンダーバー区切りで、単数形を基とする。例えば、name とか 人工キーを使用する場合、 自身の人工キーは id とする 外部キーはテーブルの頭文字の小文字 _id を付けたものとする。例えば、e_id とか 重複する場合は・・・決めてない (ぉ テーブルに別名を付ける場合、テーブル名の単数形を使用する 自己結合等でテーブルの区別が必要な場合、子テーブル側に C と付ける 孫には GC、GGC と付けていく (実際、そんなに深い自己結合なんてしないけど) フォーマット

    SQL の命名規約とフォーマット - ぐるぐる~
  • Querydslを触ってみる - Challenge Engineer Life !

    今のJava EE開発では、JPQLを書く際 動的クエリ(Dynamic Query) 名前付きクエリ(Named Query) を使うようにしていて、来、型のことなど考えるとCriteriaで書くべきだなんだろうな…と思いつつ、可読性や簡易性を優先して上記選択にしています。 ただ、どうしても動的クエリはStringBuilderなどでクエリをダラダラと連結することになって、わりとイケてないらしい…ですね。 ということで、前に@megascusさんがブログで紹介されていたQuerydslを思い出し、これから少し触っていこうかなと。 QuerydslでJPAが思ったよりも捗る 上記ブログ記事の中にあるサンプルコードや、公式サイトのチュートリアルに接頭辞「Q」が付いたEntityクラスみたいなものが出てくるので、なんなんだろあれ?と思ってたのですが、定義したEntityクラスをベースにQue

    Querydslを触ってみる - Challenge Engineer Life !
  • JPA with Spring 〜Developer's Note - タツノオトシゴのブログ

    ここ「QuerydslでJPAが思ったよりも捗る - 水まんじゅう2」の記事を読んで、Querydslなんぞや、Spring Dataって何?と思い、調査を始めたのがきっかけでした。 もともと、SeasarプロジェクトのS2JDBC、S2Daoの使い勝手のライブラリを探してたところ巡り会いました。 Querydsl JPAは、S2JDBCのように、流れるようなインタフェースで、Criteria APIよりも使い勝手、可読性が遙かによいものです。 もともとS2JDBC自体がのJPAの膨大な機能を最小限にとどめて、使い勝手をよくしたものなので、似てて当たり前ですが。 Spring Data JPAは、S2Daoのようにインタフェース定義を用いて、簡単にDBに対する操作用クラスが作れるのがよいです。 結果、Querydsl + Spring Data = 結構いいんじゃない!?と判断しました。

    JPA with Spring 〜Developer's Note - タツノオトシゴのブログ
  • QueryDsl-SQL概要

    querydsl-sql.md QueryDsl-SQL はじめに QueryDslは、Open Sourceのライブラリ。クエリを型安全で流れるようなインタフェースなDSL (Java内部DSL)で記述することができるライブラリで、JPAのCriteria APIに変換するDSLと、直接SQLに変換するDSLとがある。 JPAの方については、QueryDslのBlog記事を見れば他にいうことはほとんどないので、この記事ではSQLの方について書く。 この記事の執筆時点のバージョンはQueryDsl 2.7.2 基的な使い方 QueryDsl-SQLが提供する antタスク com.mysema.query.sql.ant.AntMetaDataExporter を用いると、データベーススキーマから Java Beanとメタクラスを生成してくれる。今回は下記のようなリレーションをもつBea

    QueryDsl-SQL概要
  • QuerydslでJPAが思ったよりも捗る - 水まんじゅう2

    先日、 [twitter:@seratch]さんから教えていただいたQuerydslがすごい良かったので記事として書きます。 http://www.querydsl.com/ JPAにおける課題 JPAではJPQLとCriteriaという二つのクエリ記述言語があります。 しかしながら、それぞれ使い勝手という意味では難のあるものでした。 JPQL JPQLは以下のような、SQLライクなクエリ記述言語です。 select new com.github.megascus.EmployeeBean(e.code, e.name, e.age) from Employee as e where name like 's%'SQLライクに記述することができるため、SQLが理解できる人にとっては理解しやすいという利点があります。 しかしながら、JPQL自体はただの文字列で定義する必要があります。 そのた

    QuerydslでJPAが思ったよりも捗る - 水まんじゅう2
  • Querydsl - Unified Queries for Java

    JPA The popular choice for SQL persistence with a focus on CRUD and simple queries for object loading. more... SQL The alternative SQL abstraction with a focus on SQL operations and the full expressivity of the SQL standard. more...

  • #clubdb2 「Javaプログラマーに贈る:Groovyで楽にSQLを実行してみよう」の資料を公開しました | Unofficial DB2 BLOG

    久し振りに講師を務めたDB2の勉強会 CLUB DB2 第158回 「Javaプログラマーに贈る:Groovyで楽にSQLを実行してみよう」終了後の懇親会から帰ってきました。 勉強会も懇親会もとても楽しかったです。渋谷で、もしくはUSTREAM中継でご参加いただいたみなさま、当にありがとうございました。(USTがうまく中継できてれば良いのですが) 話の内容はあまりDB2には関係なく、ほとんど自分の趣味でGroovyについて話をさせていただきました。GroovyのパワーとJavaとの親和性について、興味を持っていただけたらとても幸いです。 資料をSldeShareで公開しています。 講義中に気づいた誤字を直した版でアップロードしています。スライドだけでは分かりにくい部分もあるかと思いますが、あまり高度な事は説明していませんので、ご興味のある方はぜひご覧ください。 さて次回のCLUB DB2

  • HadoopのSQL対応分散クエリエンジン「Cloudera Impala」。Clouderaがオープンソースで公開

    HadoopのSQL対応分散クエリエンジン「Cloudera Impala」。Clouderaがオープンソースで公開 Hadoopのディストリビューションベンダとして知られるClouderaは10月25日、SQLに対応し、データの分析速度はMapReduceよりも何倍も高速だという新しい分散クエリエンジン「Cloudera Impala」(製品名「Cloudera Enterprise RTQ」)をオープンソースで公開しました。 これまでHadoopでは内部でMapReduceと呼ばれる処理が用いられていましたが、ImpalaではMapReduceを使わず、Clouderaが2年かけて開発した独自の分散クエリエンジンを用いて処理を行います。Hiveの上位互換のSQLが利用でき、Hive/MapReduceで数分かかっていた応答時間を数秒に短縮すると説明されています。 グーグルのDremel

    HadoopのSQL対応分散クエリエンジン「Cloudera Impala」。Clouderaがオープンソースで公開
  • [SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - *「ふっかつのじゅもんがちがいます。」withぬこ

    SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。 単にプリペアドステートメントを使え 絶対に文字列結合でSQLを構築しようとしてはいけない IPAの「安全なSQLの呼び出し方」を読むこと なんでこんなことを書くかというと、同僚が献されてた「プロになるためのWeb技術入門」なるSQLインジェクションの項で、SQLインジェクションの対策として以下のように書いてあったからです*1。 a) 値をバリデーションする b) プリペアドステートメントを使う ダメです。間違っています。単に間違っているだけでなく救いがたく間違っています。正しいSQLインジェクション対策はこう書くべきです。 単にプリペアドステートメントを使え 文字列結合でSQLを構築するな イケてないを書く人はなんで値のバリデーションをプリペアドステートメントよりも先に書くんですか?値のバリデーション

    [SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - *「ふっかつのじゅもんがちがいます。」withぬこ
  • 「SQLインジェクション対策」でGoogle検索して上位15記事を検証した - ockeghem's blog

    このエントリでは、ネット上で「SQLインジェクション対策」でGoogle検索した結果の上位15エントリを検証した結果を報告します。 SQLインジェクション脆弱性の対策は、既に「安全なSQLの呼び出し方」にファイナルアンサー(後述)を示していますが、まだこの文書を知らない人が多いだろうことと、やや上級者向けの文書であることから、まだ十分に実践されてはいないと思います。 この状況で、セキュリティのことをよく知らない人がSQLインジェクション対策しようとした場合の行動を予測してみると、かなりの割合の人がGoogle等で検索して対処方法を調べると思われます。そこで、以下のURLでSQLインジェクション対策方法を検索した結果の上位のエントリを検証してみようと思い立ちました。 http://www.google.co.jp/search?q=SQLインジェクション対策 どこまで調べるかですが、以前NH

    「SQLインジェクション対策」でGoogle検索して上位15記事を検証した - ockeghem's blog
  • NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ/秒を実現

    モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか? それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範(まつのぶよしのり)氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」(英語)をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で

    NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ/秒を実現
  • Ring

    Ringとは、リクルートグループ会社従業員を対象にした新規事業提案制度です。 『ゼクシィ』『R25』『スタディサプリ』など数多くの事業を生み出してきた新規事業制度は、 1982年に「RING」としてスタートし、1990年「New RING」と改定、そして2018年「Ring」にリニューアルしました。 リクルートグループの従業員は誰でも自由に参加することができ、 テーマはリクルートの既存領域に限らず、ありとあらゆる領域が対象です。 リクルートにとって、Ringとは「新しい価値の創造」というグループ経営理念を体現する場であり、 従業員が自分の意思で新規事業を提案・実現できる機会です。 Ringフロー その後の事業開発手法 Ringを通過した案件は、事業化を検討する権利を得て、事業開発を行います。 さまざまな事業開発の手法がありますが、例えば既存領域での事業開発の場合は、 担当事業会社内で予算や