MySQL使いが知るべきPostgreSQLとの違いと変わらない一つのこと
— そーだい＠初代ALF (@soudai1025) 2015, 8月 24 とブーメラン投げて見事に刺さってるので今から記事書く。 両サイドにはかなり厳しい話もするが俺の本音を聴いておけ（関白宣言） まぁ歴史の長いRDBなのでお互いの比較記事は沢山ある。 なのでマルチスレッド(MySQL)とマルチプロセス(PostgreSQL)だとかVACUUMだって話はしない。 むしろ実際に使ってみた際の違いをにフォーカスする。 1. SQLの違い 基本的にMySQLでやっていたことはPostgreSQL出来る。 しかし関数の挙動の違いは幾つかある。 例えば時間から曜日に該当する数字に変換した場合に MySQL → date_format(time,"%w") 0から始まり、日曜日に該当する PostgreSQL → to_char(time,'D') 1から始まり、日曜日に該当する など挙動に互換性
kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物
kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 TL;DR kamipo traditionalですら完全に防ぎきれないアレがあるので、そこを気にするなら出来る限りさっさとMyISAMからInnoDBに引っ越しましょう。 これらの記事を読んだ人向けです。 ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々 Javaでkamipo traditionalを有効にする - その手の平は尻もつかめるさ アプリでミスって不正なデータが入るくらいだった500になったほうがマシ。というのが個人的な考えです。 +激しく同意+ さて、激しく同意したところで、kamipo traditionalでは倒せないMyISAMという名の化け物の話をしたいと思います。 kamipo tr
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？（前編） NTTデータオープンソースDAY2015 － Publickey
NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？（前編） NTTデータオープンソースDAY2015 現在のシステム構築では、オープンソースのソフトウェアを使うことは当たり前になってきています。PostgreSQLはそうした中で主にエンタープライズ向けのデータベースとして着実に事例を増やしてきています。 その中で、PostgreSQLを大規模なミッションクリティカルなシステムの中で使うには、どのようなノウハウが求められるのか。オープンソースの利用に積極的なNTTデータがその事例を、1月26日に開催されたイベント「NTTデータオープンソースDAY 2015」のセッション「NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？」で紹介しています。講演内容をダイジェストにしまし
ORDER BY狙いのキーが何故速いか - 時計を壊せ
どの最適化が効くんや…とググった。 以前も調べた気がしたが思いだせず、ひたすらググる羽目になったので、 反省してブログに残す。ふつーにmysqlのdocumentに書いてあった。 http://dev.mysql.com/doc/refman/5.7/en/limit-optimization.html If you use LIMIT row_count with ORDER BY, MySQL ends the sorting as soon as it has found the first row_count rows of the sorted result, rather than sorting the entire result. If ordering is done by using an index, this is very fast. バージョン古いけど日本語のほ
MySQLでトランザクションの4つの分離レベルを試す - FAT47の底辺インフラ議事録
トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス
エロゲーマーのためのSQL -エロゲーマーのためのSQL-
SQLはデータベースからデータを抽出したりするための言語です。 この文書は、ErogameScapeのデータベースからSELECTを使って自由自在にデータを取得できるようになることを目標にします。 エロゲーをやりはじめる大学生くらいのときに、大学の講義でデータベースを学んで、退屈だなーと思った時に、ErogameScapeでSQLを学ぶことで、少しでもSQLに興味を持って、自身でデータを加工することを学習して頂けると幸いです。 ※私の大学のリレーショナルデータベースの授業では、自分の身の回りの何かをER図に落とし込んで、DBを設計し、PostgreSQLに実装し、実際にデータを入力してSELECTしてみるところまでをやりました。 ER図という概念を学んだとき「ああ、これは面白い」と思いました。 先生はこう言ったのです。 「ER図に落とし込むと、思いもよらなかったことが分かる。」と。 当時、
リレーショナルモデルのドメイン設計についての議論
リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性（≒カラム）に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
紹介：【書籍】SQLアンチパターン
リレーショナルデータベースの父、エドガー・F・コッド氏が論文を発表したのは1970年。私が生まれる前の話である。そしてSQLがANSI標準になったのが1986年。RDBMSを、そしてSQLを使ったシステム開発は常に主流で在り続けたと言っても過言ではない。そんな歴史のあるSQLであるが、未だに多くの人はSQLを使いこなせて居ないように見える。 SQLはとても奥が深い。ソートやトランザクションが使用出来るおかげで、リレーショナルモデルを無視して単なるデータの入れ物として使ってもそれなりに便利だったりする。だが、それが今現在多くの悲劇を生んでいる原因でもある。多くの人が同じようにSQLを理解せず、そのため多くの人が同じ悲劇に見舞われる。そう、それがアンチパターンである！ 今回紹介するSQLアンチパターンは、洋書SQL Antipatternsの邦訳版だ。私は元々英語版のファンでであり、人々が陥り
SQLアンチパターン
本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗（アンチパターン）があります。本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。日本語版では、MySQLのエキスパートとして著名な奥野幹也氏によるアンチパターンを収録。データベースに関わるすべてのエンジニア必携の一冊です。 本書への称賛の声 監訳者まえがき はじめに I部 データベース論
データベースの内部動作を知る
SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基本的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの？ Part 1：SQL文はどのように実行されるのか SQL実行までの
ウノウラボ Unoh Labs: RDBで階層構造を扱うには？
yukiです。ダイエットを始めて3kg減ったと思ったら、風邪を引いて見事に1kg増量。 運動しないと駄目ですね。あと残り20kg、道のりは遠いです。 さて今回は、「RDBで階層構造を扱うには？」です。 あるサイトを構築中に階層構造をもったカテゴリ構造にすることになり、どのようにDBで扱うか悩みました。 DBはMySQLを採用していたので、この時点でぱっと頭に浮かんだ選択肢は以下のようなものでした。 XML-DBを利用する 親カテゴリレコードのプライマリIDを子カテゴリレコードに持たせる 親を含めた『絶対パス』を名称として扱い、取り出した後にパース ファイルシステムに同様のディレクトリ構造を作り、毎回パースする (1)のXMLDBはオープンソースのeXistやXindice、Yggdrasillなど様々な選択肢がありましたが、カテゴリのみの利用な割にメンテナンスコストが高すぎるので見送りま
SQL文をきれいにフォーマットしてくれる『SQL in Form』 | POP*POP
長～いSQL文を見ているとどこがどういう構造になっているのかがわからなくなってきますよね。 そうしたときに使えそうなのが「SQL in Form」です。 一般向けのサービスではないですが、関係ある方には便利なのでは。 以下に簡単にご紹介。 ↑ たとえばこのようなSQL文。コメント分やインデントがわかりにくくなっています。 ↑ SQL in Formを通せばこの通り。構造がすっきりして見やすいですね。 変換する際には改行やインデント、空白の扱いなどの設定をすることもできます。またデスクトップ用のアプリもあるみたいですね。 ご利用は以下からどうぞ。無料で使えます。 » SQL Formatter / SQLFormatter formats SQL Statements
Google、MySQLを強化するパッチを無償リリース：CodeZine
Googleは、同社の製品開発の中から生まれたMySQLを強化するパッチを公開した。GoogleのWebサイトから無償でダウンロードできる。 このパッチはMySQLの扱いやすさと信頼性を向上させる目的で作られており、主にスレーブサーバ（レプリケーションとなるサーバ）の機能を強化させることができる。例として、スレーブサーバが更新通知を受け取らない限りマスタサーバを更新させない機能や、再起動なしでスレーブサーバをマスタサーバに置き換える機能などが備わっている。 他にもアクティブになっているアカウント・テーブルをモニタリングするものや、クライアント/MySQL通信のための高速な圧縮機能なども用意されている。 ちなみに、このパッチはLinux上で動作するInnoDB用に最適化されたものとなっている。その理由としてGoogleは「我々がInnoDBを使っているため」と説明している。また、現在パ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
営業さんまで、社員全員がSQLを使う 「越境型組織」 ができるまでの3+1のポイント | リブセンス
MySQL 5.6新機能解説@dbtechshowcase2012
IDEA * IDEA