「うらがみが Java まわりの ORM を知りたい会」 に参加してきた - ひだまりソケットは壊れない
うらがみがJavaまわりのORMを知りたい会 - connpass Java の O/R マッパーまわりの話を知りたかったので、6/14 に行われた勉強会 「うらがみが Java まわりの ORM を知りたい会」 に参加してきました。 会場は和室でした。 Java まわりの O/R マッパー、あんまり詳しくないのでいろいろ知れて良かったです。 メモを残しておきます。 発表内容 Java の ORM、Doma の話 +α (@backpaper0 さん) 発表資料: JavaのORM、Domaの話 +α — JavaのORM、Domaの話 1.0 documentation いろんな O/R マッパーについての簡単な紹介と、Doma の紹介。 紹介された O/R マッパーのうち、使うとしたら JPA か Iciql か Doma かなーという気持ちになった。 (個人の感想です。) ちなみに紹
【SQL入門】複数テーブルから一つの結果を出力する～集合演算子別(union・union all・minus・intersect)に紹介～ - 新卒から文系エンジニア→人材業界に転職した人のブログ
【今回の紹介】 ＳＱＬを勉強中なのでその内容をメモレベルで記載します。 ちなみに今回はこの書籍を使用しながら学習しています。 ＳＱＬに関する本は数冊みましたが、これが具体的でわかりやすかったです（初心者目線です） 現場で使えるSQL―Oracle/SQL Server対応 (DB Magazine SELECTION) 【内容】 複数のテーブルから一つの結果を取得したいときに どんなＳＱＬがあるかというのを紹介します 具体的な用途としてはこんなものがあるかと思います、、 例）4半期の売上を各商品の集計方法でだしときなど ※実際に業務で使用していたＳＱＬです。 集合演算子別に紹介していきます ■重複レコードは除き取得したい select A from Aテーブル union select B from Bテーブル 注意 ①結合テーブルのカラム数は同一にする ②結合カラムの型は同じか変換可能な
【SQL入門】group by,distinctどちらが性能がよいのか - 新卒から文系エンジニア→人材業界に転職した人のブログ
【今回の内容】 前回は基本的なＳＱＬを備忘録で簡単にまとめていたけど、 【SQL入門】基本的なSQLを目的別にまとめてみた - ＦＯＲ ＳＥ その中に気になることがあったので調べたものをメモとして紹介します。 今の自分の現場では、重複行を絞り込む時に、「distinct」と「group by」を使う人それぞれいました。 distinctとgroup byは同じように重複行を消すという意味では どちらでもいいのかなーと思っていたけど、 疑問に思ったので少し調べてみました。 【疑問】distinctとgroup by は重複行を消す目的ならどちらを使ってもよいのか？ 【結論】 結果としてはどちらも重複行を消すという意味では同じらしい。 だが、一般的にgroup byは集合関数（sumとかcountとか）と一緒に使うので、 そもそもの目的用途が違うのではという話があった。 また、どちらが性能が良
O/Rマッパー当たり前な時代だからこそSQLテクニックを磨こう·SQL Fiddle MOONGIFT
SQL FiddleはColdFusion製のソフトウェア（ソースコードは公開されていますがライセンスは明記されていません）です。 開発環境をセットアップするというのは意外に面倒で、せっかく学習しようと思ってもその時点で頓挫してしまいます。もしあなたがSQLを学んでみたいと思うならばSQL Fiddleを使ってみましょう。 こちらがメイン画面です。左に構造、右に実行するSQLを書きます。 実行例。結果はテーブルで下に表示されます。 SQLを変えれば実際に結果も変わります。 対応するデータベースは多様です。 SQL FiddleはJSFiddleに代表されるWebプレイグラウンドサービスで、SQLをWebブラウザ上で実行、確認ができます。最初のテーブルのCreate文からはじまり、任意のSQLを実行してその結果をテーブル表示で確認できます。MySQL/PostgreSQL/MS SQL Se
新著が出ます：ジョー・セルコ『プログラマのためのSQL 第4版』 - ミックのブログ
皆さん、お久しぶりです。長らくブログの更新が止まっていたのは、少し大きな仕事をしていたためです。ジョー・セルコ『プログラマのためのSQL 第4版』の翻訳。これに集中するため、ブログもやらずTwitterもやらず（こっちはちょっとやってしまった）頑張っておりました。 長かった。 本当に長かった。 原著が800ページ以上あるうえ内容も簡単ではないので、もともと楽な仕事とは思っていませんでしたが、いや大変でした。ですが無事今月刊行とあいなりました。すでにAmazonはじめオンラインショップでも予約受付を開始しています。あらかじめ言っておきますが「表紙のおっさん誰？」という質問は私にはしないように。私も答えられないので（笑）。 さて、本書の内容を紹介する代わりに、少し長くなりますが訳者前書きを引用します。購入するか判断の参考にしていただければと思います。なお、実行環境としては前書きでも書いています
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か？
(PgDay2012発表資料) SQLにとって、なぜO/Rマッパーが重要かを説明した資料です。Read less
基幹系システムの基本構成とCloud SQLのCRUD処理
1 連載の概要 1.1 本連載の趣旨と概要 基幹系はソーシャル系などに比べて、誤解を招く言い方かもしれませんが保守的な面があり、先端的な機能などの取り込みも遅れがちです。また、実際問題として基幹系ではソーシャルWebなどに比べて、システム機能の要件のハードルが高くなる部分が多いです。しかしそのような基幹系だからこそ、クラウド他Webの先端機能を利用すればどのように変貌・効率化するかを考えてみるのも意味のあることと筆者は考えます。 本稿では8回程度のやや長期の連載を予定しています。内容としては、GoogleのPaaSクラウド（Google App Engine、以後GAE）上でRDBのMySQLを使用できるようにした「Google Cloud SQL」を中心に取り上げますが、その他にもさまざまなツールやサービスと組み合わせた内容にする予定です。 サービスの組み合わせで取り上げる内容としてはW
ポストグレスSQLチューニング メモ(Hishidama's PostgreSQL7.2.1 SQL tuning Memo)
S-JIS[2003-07-19] PostgreSQL7.2.1 SQL最適化メモ SQL実行の際は、PostgreSQLが実行計画を立て、最も効率のよい方法で実行される。 が、SQLの組み方によっては効率の悪い方法が選ばれることがあるので注意。 VACUUM ANALYZE PostgreSQL（プランナー）が実行計画を立てる際には、統計情報が使われる。 統計情報はVACUUM ANALYZEを実行していないと更新されない。SQLの実行が遅いと思ったら、まず真っ先にVACUUMすべし。 EXPLAIN SQLを実行する際に プランナーがどのような実行計画を立てるかについては、EXPLAINで確認できる。 検索方法の種類 ほとんどの場合はseq-scanよりindex-scanの方が速いが、EXPLAINでcostを見てみないと確かなことは分からない。 どちらを使うかはプランナーが統計情
SQL Power - ポスグレ パワーチューニング
SQL パワー - SQL チューニング SQL はどのように実行されるか SQL は非常に強力ですが、複雑な SQL 文を実行したときに、想像以上に時間がかかったことがあるかと思います。これは、PostgreSQL が、設計者・開発者の意図したとおりに実行されていないかもしれません。いや、もちろん、結果は正しい結果が返ってきていると思いますが（返っていないとしたらたぶん開発したプログラムのバグですよ）、その結果を求めるまでに、最適な道順を通ってないかもしれません。 大抵チューニングが必要なのは、select 文なので、ここでは select 文を中心に話を進めます。 SQL は、実行時に PostgreSQL サーバに渡され、PostgreSQL サーバがどのようにデータにアクセスしたらよいかを考えます。例えば次のような SQL 文があったとしましょう。 select 社員名称 from
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
ACIDからBASE（勝手に後半） - winplusの日記
先日の記事で触れたL'eclat des jours(2008-11-20)の続きを、勝手に試みた。調子を合わせようとしたけれど無理。全然こなれないし、誤訳もいっぱいあると思うが、参考までに公開しておく。 BASE：ACIDの代わりをどうぞ ■Consistency（一貫性）のパターンいくつか ブルーワのいうとおりなら、BASEは、分散と可用性をとるかわりに、どこかで一貫性を諦めるしかない。これは難しい。というのも、ビジネス関係者も開発者も「一貫性がいちばん重要だ」というんだ。一時的な矛盾であってもエンドユーザに見えてしまうので、ビジネス関係者と開発者の両方で、どこで一貫性を諦めるかを決める必要がある。 図2はBASEが考える一貫性を説明するための簡単なスキーマだ。userテーブルは、売上総額と購入総額も含めたユーザ情報をもっている。売上総額と購入総額は現時点での合計額だ。transact
ウノウラボ Unoh Labs: RDBで階層構造を扱うには？
yukiです。ダイエットを始めて3kg減ったと思ったら、風邪を引いて見事に1kg増量。 運動しないと駄目ですね。あと残り20kg、道のりは遠いです。 さて今回は、「RDBで階層構造を扱うには？」です。 あるサイトを構築中に階層構造をもったカテゴリ構造にすることになり、どのようにDBで扱うか悩みました。 DBはMySQLを採用していたので、この時点でぱっと頭に浮かんだ選択肢は以下のようなものでした。 XML-DBを利用する 親カテゴリレコードのプライマリIDを子カテゴリレコードに持たせる 親を含めた『絶対パス』を名称として扱い、取り出した後にパース ファイルシステムに同様のディレクトリ構造を作り、毎回パースする (1)のXMLDBはオープンソースのeXistやXindice、Yggdrasillなど様々な選択肢がありましたが、カテゴリのみの利用な割にメンテナンスコストが高すぎるので見送りま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
初級〜中級者のためのSQL特訓 - 忘れないようにメモっとく
IDEA * IDEA