MySQLが好きな私が、今はPostgreSQLを勧めたい理由
私はMySQLが好きです。長く使ってきましたし、オンプレミスでの運用もやってきました。 しかし現職に来てからは、PostgreSQLを使う機会が増えました。最初は正直かなり抵抗感がありました。ずっとMySQLを使ってきたので、慣れの問題もありますし、PostgreSQLに対して必要以上に構えていたところもあったと思います。 ただ、実際に使っていくうちに、PostgreSQLの良さが少しずつ見えてきました。最近では、新規開発でどちらを選ぶかと聞かれたら、PostgreSQLを選びたいと思うようになっています。 私はMySQLを長く使ってきたので、昔のMySQLの雑さも知っています。ただ同時に、今でも昔の印象だけでMySQLを語るのは不正確だとも思っています。sql_modeをきちんと設定すれば危ない挙動の多くは避けられますし、MySQL 8でかなり多くの機能が入りました。 また、今回はオンプ
ビューとは（データベース）
ビュー（view）データベースのビューとは関係データベースにおけるビュー（英：view）とは、1つ以上の表（テーブル）から必要な要素だけを取り出して作った仮想的な表のことです。 例えば、次のような3つの表があるとします。 「社員テーブル」は社員の情報を管理している表、「部署マスタ」は部署の情報を管理している表、「課マスタ」は課の情報を管理している表です。 データベースの表はデータを効率よく格納するために正規化されています。この正規化された表は、必ずしも使いやすいとは限りません。 例えば、次のような「営業部の社員」だけを管理する表を利用したいとき、「社員テーブル」「部署マスタ」「課マスタ」の表を結合する必要があります。 そこで、用途に応じた仮想的な表を作ることができます。これがビュー（view）です。 上記はビューのイメージ例です。 「社員テーブル」「部署マスタ」「課マスタ」から必要な要素だ
sqlfmt: A free online SQL formatter for writing prettier SQL
This post was originally published in 2018 by former CockroachDB engineer Matt Jibson, who owns goats and makes his own soap. It’s one of the most popular blogs we’ve ever published so we wanted to get it back up on the site for a new crop of blog readers. What is sqlfmt?sqlfmt is an online SQL formatter. It is pronounced sequel fumpt. Its purpose is to beautifully format SQL statements. I built s
JackDB | Modern Database Client
Secure, Collaborative Database Management Platform and SQL Editor JackDB Enterprise is a modern database client for PostgreSQL, MySQL, Oracle, SQL Server, Amazon Redshift, and other cloud databases. Connect Your Databases Easily connect to all your databases and explore your data sources in a modern, browser-based SQL editor. Audit Logging & Reporting Automatically track and consolidate every quer
PugSQL :: SQL is Extremely Good, Actually
PugSQL is a simple Python interface for using parameterized SQL, in files, with any SQLAlchemy-supported database. import pugsql # Create a module of database functions from a set of sql files on disk. queries = pugsql.module('resources/sql') # Point the module at your database. queries.connect('sqlite:///foo.db') # Invoke parameterized queries, receive dicts! user = queries.find_user(user_id=42)
YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
Django の発行する ORM のクエリでリレーションによってはサブクエリを使っている件と、QuerySet を評価するときのパフォーマンスについて - 憧れ駆動開発
サブクエリの件 Blog:1 Entry:n みたいなモデルのリレーションがあるとする。ちょっと違うけど。 print(Hoge.objects.filter(entry__in=blog.entry_set.all()).query) 擬似的なクエリはこんな感じ。 SELECT `entry`.`id`, `entry`.`ctime`, `entry`.`utime`, `entry`.`name`, FROM `entry` WHERE (`entry`.`blog_id` IN (SELECT U0.`id` FROM `blog` U0 WHERE U0.`blog_id` = 313 ) ) いや、単純に __in だと SELECT * FROM hoge WHERE moge IN (a, b, c) だと思うけど、Django の ORM が発行しているリレーションをまた
【MySQL】SQL発行時に日時計算（加算・減算）する方法 | WEBマスターの知恵ブログ
PHP+MySQLを利用していて、DATETIME型のカラムに対して、直接、加算・減算をしたSQLの条件を指定したい場合の方法について覚書しておきます。 もちろん、PHPで日時計算をして、変数に代入してからSQLに組み込むなどしても日時の加算・減算の条件付けはできるのですが、SQLの発行時点で加算・減算した方が楽に操作できます。 MySQLの公式マニュアルにも記述があるのですが、MySQLのマニュアルは読みづらいと思うので要点をまとめてみました。 （参考）公式マニュアル http://dev.mysql.com/doc/refman/5.1/ja/date-and-time-functions.html 該当するのはDATE_ADD DATE_SUBの箇所です。 分かりづらいので、具体的なSQLを組んでみます。 "SELECT count(id) as cnt FROM table WHE
新著が出ます：『SQL実践入門』 - ミックのブログ
4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。
開発者のためのSQLパフォーマンスの全て
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
SQLデータベースに正しインデックスを作るのは 誰の役割？
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
大量のテストデータを快適に作る７つのコツ - 負荷テストのためにExcel＆VBAをうまく使う - 主に言語とシステム開発に関して
Webアプリケーションが実運用に耐えうるかどうかテストするためには， 大量のテストデータが必要になる。 規模にもよるが，場合によっては１テーブルあたり，数十万〜数百万レコードを要求されるだろう。 システムの負荷テストを実施する際には， （１）： 「システムの内部に保有する負荷」つまり「DBの重さ」をまず作り出し， SQL実行性能を現実の運用状態に合わせてチューニングする。 （２）： その後で，「システムの外部で発生する負荷」つまり同時アクセスをかける。これがサーバーの重さとなる。 そして各機能ページのパフォーマンスを測定する。 後者は，jmeterなどの便利なツールが存在する。 が，前者の「データ生成」に関しては，方法がそれほど確立していないように思える。 下記は，そういった大量のデータをうまく作るためのメモ。 (１) Excelでデータを作るべし (２) できれば Excelは 2007
scheman diff - ✘╹◡╹✘
https://github.com/r7kamura/scheman 旅行を兼ねて沖縄に開発合宿に来ているので、1日目の成果を書き出しておく。 目的 Webアプリの開発フローで次のような状態を実現したい。 DBの変更のたびに変更用のSQLやMigrationファイルを人間が書かなくて良い migrationファイルを書く代わりに人間はスキーマを編集する スキーマはSQLで記述できる (DSLの使用を強制されない) SQL以外の言語でも記述できる (DSLを使用しても良い) 方針 次のような実装を試みた。 SQLを構文解析してスキーマデータに変換する (解析器は事前に実装済み) 適用すべきSQLを2つのスキーマデータの差分から自動で計算する SQL以外の解析器も作成可能に scheman diff scheman diffというコマンドを実装した。 これは変更前後の二つのスキーマの差分を標
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Client Challenge
分析関数の衝撃一覧
マジックビーンズ
あなたが知らない リレーショナルモデル
SQLの観点から「Oracle Database」「PostgreSQL」 「MySQL」の特徴を整理しよう！
Where狙いのキー、order by狙いのキー
ふつうのWeb開発者のためのクエリチューニング
