git.postgresql.org Git - postgresql.git/commit
Doc: use "an SQL" instead of "a SQL" Although which is correct depends entirely on whether you pronounce SQL as "ess-que-ell" or "sequel", we have standardized on the former in our user-facing documentation, so use the correct article according to that pronunciation. Discussion: https://postgr.es/m/CAApHDvp3osQwQam+wNTp9BdhP+QfWO6aY6ZTixQQMfM-UArKCw@mail.gmail.com
オラクル、MongoDB互換API「Oracle Database API for MongoDB」をAutonomous JSON Databaseで提供開始
オラクル、MongoDB互換API「Oracle Database API for MongoDB」をAutonomous JSON Databaseで提供開始 オラクルは、MongoDB互換APIである「Oracle Database API for MongoDB」を、Oracle Cloudで提供しているAutonomous JSON Databaseで提供開始したと発表しました。 これによりMongoDB対応のアプリケーションやツールがAutonomous JSON Databaseでも使えるようになります。 Run your @MongoDB applications on @OracleCloud. With @OracleDatabase API for MongoDB, you can continue to develop #JSON-centric applicatio
SQLアンチパターン：ENUMは使わない方がいいよ | Shiro's secret base
どうも、シローです。 今回は、特定の文字列に限定した列を定義する方法について、アンチパターン「サーティワンフレーバー」も一緒に紹介します。 特定の値を持ちうる列とは 例えばユーザ(Users)の権限（管理者かメンバーか）を表したい場合、Usersテーブルにメンバーの権限を表すuser_roleという列を定義するとします。 このuser_roleには管理者の場合はadmin、メンバーの場合はmemberという値を持ちそれ以外の値は格納しない（できない）ようにするにはどうすれば良いのか アンチパターン「サーティワンフレーバー」について 先にアンチパターンについて紹介します。 サーティワンフレーバーと呼ばれる設計方法では特定の値を入れるために 列にCHECK制約を入れる(MySQL8.0以降) 列をENUM型にする という手法を取りうることです。 僕の環境はMySQL5.7なのでENUM型のカラ
ジョー・セルコ著、ミック訳『プログラマのためのSQL 第4版 すべてを知り尽くしたいあなたに』(翔泳社)を読んだ - nekoTheShadow’s diary
honto.jp 前々から気にはなっていたものの、かなりの大ボリューム(大型本で全816ページ)ということで、なかなか手を出せないでいたのですが、このたび何とか読み終えることができました。読んでいた期間はだいたい2か月ぐらいでしょうか。といっても2か月間ずっと読んでいたのではなく、気が向いたときにだらだら読み進めていた感じなので、毎日ちゃんと読めば1か月弱ぐらいで読み切れたとは思います。 自分は電車での移動中に本を読むことが多いのですが、コロナウィルスの影響で外出を自粛していた結果、電車に乗る機会が激減。とくにリモートワークになって、電車通勤がなくなったことが一番大きく、それが本書を読み切るのに時間がかかってしまった最大の要因のような気がします。 それはさておき、本書の内容をひとことでいうならば「SQLの一般教養」。かなり大部の本なので、ニッチな機能や細かなテクニックが紹介されているのかと
ぐるぐるSQLという用語は止めてくださいという話 - Qiita
はじめに @abe_masanori さんが ぐるぐるSQLは止めてくださいという話 https://qiita.com/abe_masanori/items/1a2b9c1f1069c43237f8 という記事を書かれたのですが、そこで「ぐるぐるSQL」なる見慣れない用語が使われていて、それは「N+1問題」というのだとコメントを書いたところ、妙に反発を受けてしまったので改めて記事にしたいと思います。 用語としてどちらが古いか？ さしあたり「ぐるぐるSQL」と「N+1問題」の用語のどちらが正しいかの議論は後回しとして、それぞれの用語の初出を調べてみましょう。例えばtwitterで検索すると、「ぐるぐるSQL」の最古のツイートはこちらのようです。 それだけしか使用してないなら、NP_Listとかでサブプラグインを作成するのがいいんだろうとは思ってるですが、これってやっぱりスマートなSQLはな
ぐるぐるSQLは止めてくださいという話 - Qiita
1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが（決してメインの仕事ではないですが）、その中でよく出くわす問題の１つに「ぐるぐるSQL」（もしくは「ぐるぐる系」）といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%：ぐるぐる SQL 20%：SQL 文の書き方が不適切 15%：索引がない or 不適切 15%：パーズが遅い 10%：データモデルがおかしい 10%：その他 （大昔は２番目 / ３番目がほとんどだったのですが、最近はなぜがぐるぐる SQL が多い…） ぐるぐる SQL の実装では、ネットワーク通信や、アプリ側のクエリ生成 / 結果データ構築、DB 側のクエリ受信 / 結果送信といった、処理の本質的で
PHP: SQL から Mongo への対応表 - Manual
Getting Started Introduction A simple tutorial Language Reference Basic syntax Types Variables Constants Expressions Operators Control Structures Functions Classes and Objects Namespaces Errors Exceptions Generators Attributes References Explained Predefined Variables Predefined Exceptions Predefined Interfaces and Classes Context options and parameters Supported Protocols and Wrappers Security In
2020年現在のNewSQLについて - Qiita
Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海
SQL はチューリング完全 - Qiita
前置き これは京大マイコンクラブの10/20の例会講座で発表されたものです 自己紹介 @utgwkk 工学部情報学科計算機科学コース2回生 第39代副広報 root アンケートです SQL を知ってる SQL を書いたことがある 毎日 SQL を書いてる SQL とは SQL（エスキューエル[ˈɛs kjuː ˈɛl]、シークェル[ˈsiːkwəl]、シーケル）は、関係データベース管理システム (RDBMS) において、データの操作や定義を行うためのデータベース言語（問い合わせ言語）である。 要するに、データベースからデータを所望の形で取ってくるときに使う言語 プログラミング言語ではないとされている
O/Rマッピングは百害あって一利なし！ - Qiita
O/Rマッピング(Object-relational mapping)について、Wikipediaには以下のように書かれています。 データベースとオブジェクト指向プログラミング言語の間の非互換なデータを変換するプログラミング技法である。 O/Rマッピングを実現する仕組みを、O/Rマッパーと言います。（両者を区別しなくても私が言いたいことは伝わると思いますので、ORMと統一して記述します）（また、個人的な理由で、プログラミング初学者向けに語りかける口調にしていますが、初心者向けの記事というわけではありません） 最近はWEBアプリ開発をするにあたって、WEBフレームワークに標準で何らかのORMが組み込まれていることが多いため、その存在を知らない人はまずいないでしょう。 私も何度かORMと向き合ってきましたが、そうこうしているうちに気がつきました。 ORMはめんどうくさい！ …ってことに。 みん
MySQLテーブルをそのままコピーする - Qiita
こんにちは @kako_351です。 テスト用のテーブルを用意したいときなど、テーブル構造も中のデータもそのままで名前だけ_testとかつけてまるっとコピーする方法。 検索すればすぐ出てきますが、毎回忘れがちなので備忘録です。 また、こういう風に書けば記憶にも残るかなと思って。 2つのSQLを実行するだけ ①構造が同じテーブルを作成 LIKE演算子を使えば簡単にできます。
[PostgreSQL] 知らないと損！コメントに関するtips３つ · DQNEO日記
テーブルやカラムにコメントを設定する CREATE TABLEするときに、一緒にコメントを設定しておくとハッピーになれます。 COMMENT ON TABLE members IS '会員テーブル'; COMMENT ON COLUMN members.id IS '会員ID'; コメントでは改行コードを含めることができます。 これを使うと、説明的な長いコメントを書くことができます。 ドキュメントをエクセルで残すよりも実用的なのでオススメです。 COMMENT ON TABLE members IS E'会員テーブル\n会員情報を格納するテーブルです。\n使い方はほげほげで、ふがふがに注意してください'; テーブルやカラムのコメントを見る 設定したコメントは、phpPgAdminやpgAdmin等で閲覧できます。 psqlで見るときは下記のようにします。 カラムのコメントを見る mydb=
![[PostgreSQL] 知らないと損！コメントに関するtips３つ · DQNEO日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/8f7de7c0278993661a11fbc3637f96292ba773aa/height=288;version=1;width=512/http%3A%2F%2Fdqn.sakusakutto.jp%2Fimages%2Fkali.jpg)
ケースA 落とした斧の種類を尋ねた際に攻撃を受けた事例 - 脆弱性を攻撃される童話事例集（鶴見トイ） - カクヨム
むかしむかし、ある森のそばに木こりが住んでいました。貧しいくらしをしていましたが、毎日いっしょうけんめい働いていました。 その日も、木こりは湖のそばで木を切っていました。森のなかには木こりが斧を木に打ち込む、カーンカーンという音が響いていました。 あとひとふりで木が倒れそうになったところで、木こりは力を込めて斧を振りました。しかしどうしたわけか、斧はすぽんと木こりの手から抜けてしまいました。斧はひゅーんと空を飛び、湖にボチャーンと落ちてしまいました。湖は底が見えないほど深く、斧はすぐに沈んでいってしまいました。 「ああ、どうしよう。斧はあの一本きりしかないのに。あれがなくちゃあ仕事ができなくて、俺は餓え死にしてしまう」 木こりが頭をかかえていると、湖の水面がだんだん盛り上がってくるではありませんか。木こりがぽかんとそれを見ている間に、水はどんどん高く盛り上がり、ついにはその中から人の形をし
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub｜Webエンジニアのキャリアを考える！
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
分析SQLのコーディングスタイル - クックパッド開発者ブログ
SQL、書いてますか？ こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、 分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。 そこでちょっと気になるのが、 SQLのコーディングスタイルってどうするのが一般的なんだっけ……？ という点です。 イマドキはSQLなんてO/R mapperに吐かせることが多いからなのか、 それともコードを広い範囲で共有することがそもそもないからか、 SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、 いまいち決定版と言えるスタイルがないなと感じています。 そんなわけで本日は、SQLのコーディングスタイルについての意識を活発化させるべく、 クックパッドでわたし（青木）が使っているコーディングスタイルから特徴的な点を紹介したいと思います。 特に、分析
tree-tips: mysqldumpでロックせずオンラインバックアップする | MySQL
mysqldumpのオンラインバックアップ mysqldumpのオプション mysqldump時にロックをかけないオプションは「--single-transaction」です。 --single-transaction このオプションはサーバからデータをダンプする前にBEGIN SQLステートメントを発行します。InnoDBといったトランザクションテーブルに対してのみ便利です。なぜなら、アプリケーションをブロックせずに、BEGINが発行された当時のデータベースの状態をダンプするからです。 このオプションを使用しているときは、一定の状態でダンプされるのはInnoDBテーブルのみだということを留意してください。例えば、このオプションを使用中にダンプされたMyISAMやMEMORYテーブルは状態が変化する可能性があります。 mysqldump — データベースバックアッププログラム リファレンス
MySQLではIN句とサブクエリの組み合わせはインデックスが効かない！？
な、なんと person_diaryはインデックスが適用されずにフルスキャンされ（１行目のkeyがNULL） 逆にpersonはid列に設定してあるプライマリキーが適用される(2行目のkeyがPRIMARY) という二つの謎な現象が発生しました。 そもそもpersonはnameカラムに対してLIKE検索しているのに、id列のプライマリキーが効いちゃうのは全く納得いきません。なぜ、どうしてこんなことが起こるのでしょう？ 原因 私がMySQLに期待していた動きとしては ①サブクエリを実行してperson.idのリストをメモリ中に作成 ②person.person_idに張られているインデックスを使って検索 というところでした。 期待通りに動いてくれなかったのには二つのMySQLの特性が関係していました。 特性① サブクエリを含むSQLは外側から先に実行される MySQLの場合、サブクエリを含む
更新系SQLを手で打つときに気をつけていること
WHERE条件をつけまくる UPDATE user SET age = 35 WHERE id = 1 AND name = 'Songmu' AND age = 34 idだけで絞れるけど name も付けてレビュワーフレンドリー 変更前の値も条件に含める 34 -> 35になることがわかる 間違えていた時も戻せる ユーザー操作とのコンフリクトを検知 万が一履歴から誤爆しても更新されない(可能性が高い) SETとWHEREを一行にまとめてるのは変なところで小指が滑るのが怖いため WHERE条件応用編 UPDATE user SET weapon_id = (SELECT id FROM weapon WHERE id = 100 AND name = '村正') WHERE id = 1 AND name = 'Songmu' AND weapon_id = (SELECT id FRO
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQL to MongoDB Mapping Chart — MongoDB Manual
【MySQL】重複しているレコードを最古のものを残しすべて削除するSQL。
