タグ

SQLに関するroirrawedocのブックマーク (9)

  • 波ダッシュをいい感じにする Wavedash という gem を作ってます - takatoshiono's blog

    これは何か? 波ダッシュのような文字を変換するための ruby 用ライブラリです。 takatoshiono/wavedash · GitHub 対象ユーザー アプリケーションの文字コードは utf-8 だが、MySQL の文字コードが ujis, eucjp-ms, cp932, sjis である アプリケーションの外部と通信するために、ujis, eucjp-ms, cp932, sjis など異なる文字コードへの変換を必要としている いるのかな…(もしいたら教えてください) 問題 たとえば文字コードが ujis の MySQL データベースを使用する Rails アプリケーションにおいて、〜 (U+301C WAVE DASH) をデータベースに保存しようとすると Mysql2::Error: Incorrect string value というエラーになる。 何が起きているか My

    波ダッシュをいい感じにする Wavedash という gem を作ってます - takatoshiono's blog
  • ルーク!MySQLではkamipo TRADITIONALを使え! | おそらくはそれさえも平凡な日々

    よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI

    ルーク!MySQLではkamipo TRADITIONALを使え! | おそらくはそれさえも平凡な日々
  • MySQLの自動変換を丁重にお断りするためのたった1種類の呪文 - sakaikの日々雑感~(T)編

    先日の『これだけは覚えておきたい!!MySQL の6つの自動変換』 http://d.hatena.ne.jp/sakaik/20100225/mysqlautochange にはたくさんの反響をいただいた。 時にこちらの意図と違っちゃうこともあるけれどもケナゲに気を使ってくれる MySQL が、これほどに皆さんにも愛されていることが判り、MySQLファンの一人として嬉しい限りである。 さて、そのエントリの最後に、 なお、「SQLモード」を指定するとこれらの動作を変更することができる。SQLモードについては気が向いたらいつか紹介してみたい。 と書いたところ、速攻でキムラデービーの木村明治氏が補足エントリーを書いてくださった。 ○キムラデービーブログ [勝手に補足]これだけは覚えておきたい!!MySQL の6つの自動変換 http://blog.kimuradb.com/?eid=83851

    MySQLの自動変換を丁重にお断りするためのたった1種類の呪文 - sakaikの日々雑感~(T)編
    roirrawedoc
    roirrawedoc 2018/05/19
    大分古い記事なんだけど今でもこうなんだろうか
  • MySQL で utf8 と utf8mb4 の混在で起きること - tmtms のメモ

    MySQLUTF-8 で使おうと思ってハマりがちなのは charset utf8 を指定してしまうことです。 MySQLUTF-8 には歴史的事情により utf8 と utf8mb4 の二つあります。 UTF-8 は1バイト〜4バイトで1文字が構成される文字コードですが、MySQL の utf8 は4バイト文字を扱うことができません。ハマりたくなければ utf8mb4 を使いましょう。 utf8 を使ってしまった場合に4バイト文字がどのように扱われるか、自分でもうろ覚えだったのでメモしておきます。 登録 接続が utf8mb4 でカラムが utf8mb4 あたりまえですが、そのまま登録されます。 mysql> insert into utf8mb4 (c) values ('美味しい🍣と🍺'); mysql> select * from utf8mb4; +--------

    MySQL で utf8 と utf8mb4 の混在で起きること - tmtms のメモ
    roirrawedoc
    roirrawedoc 2018/05/19
    ありがてー
  • kamipo TRADITIONALでは防げないINSERT IGNOREという名の化け物 | おそらくはそれさえも平凡な日々

    インスパイア元→kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 タイトルが全てです。ピンときた方は読み進む必要はありません。 データがなかったらINSERTして欲しいけど既に入っている場合には何もして欲しくないみたいな処理をするときに、 INSERT IGNORE を使ってしまうことがありますが、 INSERT IGNORE はユニークキー制約違反だけじゃなくて、あらゆるエラーをIGNOREしてしまいます。つまりkamipo TRADITIONALすらIGNOREしてしまうのです。なので使わないほうが安全です。 様子です。 mysql> SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'; Query OK, 0

    kamipo TRADITIONALでは防げないINSERT IGNOREという名の化け物 | おそらくはそれさえも平凡な日々
  • [MySQL] INSERTしたデータのIDを取得したい

    結構需要があると思うんですが、MySQLでINSERTした時、挿入されたデータのID(Auto IncrementなPrimary Key)が取りたいことってよくあると思います。INSERTが1つだけならLAST_INSERT_ID()を用いて取得することができるのですが、バルクインサート(1つのクエリで複数のデータを挿入)では取得出来ません。今回はそれを取得するための方法をまとめたいと思います。MySQLのバージョンは5.1なので、それ以降のMySQLでは苦労しなくてもうまくいくかもしれません。 問題となるのはどこか おおまかに以下の様なことをやりたいわけです。 バルクインサートしたデータのIDを取得したい(AI+PK) ON DUPLICATE KEY UPDATEで変更されたデータのIDも取得したい こんな感じです。まず1つめの条件を外して、単一のINSERT ... ON DUPL

    roirrawedoc
    roirrawedoc 2018/05/19
    こんな単純な処理のためにここまで複雑な事しないといけないなんて
  • MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳

    結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:

    MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳
  • PostgreSQLとMySQL、使うならどっち? データベース専門家が8つの視点で徹底比較! - エンジニアHub|Webエンジニアのキャリアを考える!

    PostgreSQLMySQL、使うならどっち? データベース専門家が8つの視点で徹底比較! オープンソースのデータベースとしてよく比較されるPostgreSQLMySQL。どんな長所・短所があるのでしょう? それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース(以下、RDB)を選ぶのが最善なのか?」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ

    PostgreSQLとMySQL、使うならどっち? データベース専門家が8つの視点で徹底比較! - エンジニアHub|Webエンジニアのキャリアを考える!
  • なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub|Webエンジニアのキャリアを考える!

    なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか? そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人(まつうら・はやと/@dblmkt)さんに8つ

    なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub|Webエンジニアのキャリアを考える!
  • 1