サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
回答 (3件中の1件目) ハイプサイクルという概念をGartnerグループが提唱してまして、様々な流行りスタリのサイクルを分析する標準的な方法となっています。 ハイプとは過度な期待や熱狂を意味する言葉です。一発屋芸人の人気のカーブみたいなもので、テツandトモみたいに安定する場合と、消えていくものがあります。芸人ではありませんがDA PUMPは一茶の人間性もありまして、次は厳しいけど定着すると思っています。 なんだかのトリガーで評価が上がり始め、ピークを迎える。その後評価が下がっていき、底を打つと少し上がって定着するという経過をたどるとしています。これと同じモデルで、流行りのハイテク...
データベーステーブル設計の基礎の基礎～エンティティの抽出・定義から正規化まで 適切な形でデータベースのテーブルを設計し、運用するには？テーブル設計に必要な初歩を日本MySQLユーザ会副代表の坂井恵さんが丁寧に解説します。 金融系アプリ、ゲーム、人工知能などなど……。どんな種類のシステムを開発する上でも、避けて通れない領域があります。データベースです。データを適切な形式で格納し、取り出す。単純明快ながらも奥深いこの仕組みは、多くのシステムの根幹を支えています。 しかし、適切な形でデータベースのテーブルを設計し、運用するのは簡単なことではありません。「良いテーブル設計」のためには知識と経験が不可欠です。今回は日本MySQLユーザ会の副代表である坂井恵さんに、これからテーブル設計に着手する方に向け、設計に必要な技術と、良い設計を作るための考え方を教えていただきました。 坂井恵（さかい・けい） @
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1MySQL ::MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
ちょっと古い記事だけど、「Selecting Rows Randomly from a Large Table」をざっくり意訳しました。 多くの行数がある巨大なテーブルから、ランダムにサンプリングしてデータを取得したいことがあります。 ランダムにサンプリングするために、テーブルからTOP Nで選択することがあります。しかし、このサンプルではランダムではなく、必ずしも再現性はないですがテーブルの最初のN行を取得します。 小さなテーブルからランダムに行数を取得する場合には、一般的には次のようなクエリを使用します。 SELECTTOP 10 PERCENT * FROM test ORDER BY NEWID()ポイントは、「NEWID()」関数を使用していることです。 NEWID関数は、グローバルに一意な識別子GUIDをメモリ上の各行に生成します。GUIDでORDER BYによるソートをす
SQL、書いてますか？ こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、 分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。 そこでちょっと気になるのが、SQLのコーディングスタイルってどうするのが一般的なんだっけ……？ という点です。 イマドキはSQLなんてO/Rmapperに吐かせることが多いからなのか、 それともコードを広い範囲で共有することがそもそもないからか、SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、 いまいち決定版と言えるスタイルがないなと感じています。 そんなわけで本日は、SQLのコーディングスタイルについての意識を活発化させるべく、クックパッドでわたし（青木）が使っているコーディングスタイルから特徴的な点を紹介したいと思います。 特に、分析
大量レコードのjoinは遅い 遅くなるのはMySQLだけなの？ そんなことはありません。MySQLもPostgresもOracleもSQLServerも遅くなります。Oracleのオプティマイザは賢いですが、基本的に大量レコードのjoinは避けるべきです。 何故遅くなるの？ データ量が多すぎてテンポラリ領域を使う（バッファに乗り気らない）から、です。 何件くらいからjoinが遅くなるの？ スキーマ構造によるので一概には言えませんが、大体1000件辺りから微妙に遅くなり、1万件を超えると一気に遅くなります。 1万件程度なら割と力技（マシンパワー）で何とかなるので、1万件を超えた辺りから注意してみて下さい。 よくある例では、ログを元にしたアクセスレポートの生成時に、大量レコードのjoinが必要になり易いかもしれませんね。 解決策 データ量を減らしてからjoinする。 データ量が多いならデータ
Stack Overflow for Teams is now called Stack Internal. Bring the best of human thought andAI automation together at your work. Try for free Learn more
BigQueryはカラム型データストアの一種で、テラバイトクラスの大規模データに対して大量の並列処理を行うことで高速に結果を得ることが可能。グーグル 佐藤一憲氏の発言によると、 OLAP/DWH/Data Miningで行われるようなread onlyのad hocクエリをきわめて高速（数秒〜数十秒）に実行します。 とのこと。SQLによる問い合わせが可能 この高速性に加え、BigQueryではSQLを問い合わせ言語に使えるという点にも大きな特徴があります。数秒程度のレスポンスとSQL文による記述は、大規模データに対するアドホックな処理を行うのに適したサービスだといえるでしょう。 BigQueryのSQLの構文は「Query Reference」で解説されていますが、SELECT文にFROM、WHERE、JOIN、HAVING、GROUP BY、ORDER BY、LIMITなどが使えるため
eBayが、JavaScriptアプリケーションからSQL文のような形式でデータベースへの問い合わせを記述できるDSL（ドメイン固有言語）のql.ioを発表。オープンソースとして公開しました。 現在、多くのWebアプリケーションが、バックエンドとのデータのやりとりにHTTPをベースにしたAPIを用いています。しかし、WebベースのAPIによってデータを取り出すのは、プログラマにとって実は手間のかかることです。 例えば、キーワードを入力すると関連する商品の名前、詳細、購入者の評価をユーザーに表示する、というWebアプリケーションでは、まずキーワードでデータベースを検索して商品IDを取得し、今度はその商品IDをキーにして名前や概要、評価の情報を取得する、といったように、APIを繰り返し呼び出す必要があります。 ql.ioはこうした内容をSQLのように分かりやすい記述で実現するだけでなく、複数の
SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基本的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの？ Part 1：SQL文はどのように実行されるのかSQL実行までの
Ringとは、リクルートグループ会社従業員を対象にした新規事業提案制度です。 『ゼクシィ』『R25』『スタディサプリ』など数多くの事業を生み出してきた新規事業制度は、 1982年に「RING」としてスタートし、1990年「New RING」と改定、そして2018年「Ring」にリニューアルしました。 リクルートグループの従業員は誰でも自由に参加することができ、 テーマはリクルートの既存領域に限らず、ありとあらゆる領域が対象です。 リクルートにとって、Ringとは「新しい価値の創造」というグループ経営理念を体現する場であり、 従業員が自分の意思で新規事業を提案・実現できる機会です。 Ringフロー その後の事業開発手法 Ringを通過した案件は、事業化を検討する権利を得て、事業開発を行います。 さまざまな事業開発の手法がありますが、例えば既存領域での事業開発の場合は、 担当事業会社内で予算や
MySQLで INSERT時に重複する KEYが既に存在する場合の動作のオプション► 2018 (1) ► 1月 (1) ► 2017 (4) ► 6月 (3) ► 5月 (1) ► 2016 (15) ► 12月 (4) ► 11月 (1) ► 10月 (2) ► 7月 (3) ► 6月 (1) ► 5月 (3) ► 1月 (1) ► 2015 (13) ► 12月 (1) ► 10月 (1) ► 9月 (1) ► 6月 (1) ► 5月 (1) ► 3月 (2) ► 2月 (3) ► 1月 (3) ► 2014 (11) ► 12月 (1) ► 9月 (2) ► 8月 (2) ► 6月 (1) ► 4月 (4) ► 2月 (1) ► 2013 (15) ► 12月 (3) ► 11月 (3) ► 8月 (2) ► 7月 (4) ► 5月 (1) ► 4月 (2) ► 2012 (7) ► 10月 (1) ► 7月 (1) ► 4月 (3) ► 1月 (2) ► 20
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年7月1日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わりPHPのデータベース・アクセス・ライブラリPDOは、DB接続時の文字エンコーディング指定ができないため、文字エンコーディングの選択によっては、プレースホルダを使っていてもSQLインジェクション脆弱性が発生します。 追記(2011/06/19) ここに来て急にブクマが追加されはじめていますが、このエントリを書いてから状況が改善しています。PHP5.3.6(2011/03/17)にて、PDOでもデータベース接続の文字エンコーディングを指定できるようになりました。この版で、UNIX版のPHPでは解決しましたが、Win
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNERJOIN →JOIN LEFT OUTERJOIN → LEFTJOIN RIGHT OUTERJOIN → RIGHTJOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSSJOIN。 こんなの使いません。 ブクマ用画像。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: SQLアンチパターン: ビル・カ-ウィン, 和田卓人, 和田省二: 本
