OracleとMysqlの「length関数仕様」に見る差別化
ヨシダです。
length関数の仕様違いに怒り心頭ですので、不満をブチまけます。
また、データ移行というニッチ分野の苦労話を少しします。
1.その前にDBMSシェアについて
これを見て思うことは、私が社会人１年生だった頃、MySQLは２位ではなかったし、DB２はこんなに順位は低くなかった印象です。MySQL躍進の理由はAWS AuroraがMySQLベースだからでしょう。
2.今日の本題「length関数」
DBにも様々な便利機能を持った関数が準備されています。このような便利機能をアピールして、製品の差別化を行っている訳です。
DBの問い合わせ言語SQLの中で、length関数は例えば「length(文字列X)」と使うと文字列Xの長さを返してくれます。
？？？な皆様、事例を提示します。
----------------
length('サクラサク');
Oracle：=5(文字数)
MySQL：=15(バイト数)
----------------
...あれ？結果が違いますね。
2.何故困るのか
私はEC導入が生業で、専門はデータ移行だからです。現在動いているシステムで動いているDBと、これから動かそうとする新システムDBのデータ移行が役割です。
このデータ移行ですが、現在システムと新システムとの構造を変えたい思惑が絡むことが多く、またDBMSの変更など茶飯事です。
3.length関数で何をして困るのか
現システムのDBに入っているデータが、対応する新システムのデータ項目にすっぽり入るか、長さを測定しているのです。
先程説明したように現新でデータ構造を変えたがるので、たまに無理がかかります。
メモ欄のような項目が良く面倒になります。
ECシステムですので、ロジスと商品担当とのやり取り内容などをナレッジする為にメモ欄が使われ、その中には対応内容がたまにびっしり書かれているケースも見られます。
ケース１）「注文メモ」「配送メモ」という２つの項目を合わせて「メモ」に文字列結合して移行したことがあります。
この場合、以下の公式にはまらない場合、別途対応になるじゃないですか。
メモAのカラム長 >= 注文メモの最大長 + 配送メモの最大長
データ移行時には細かくチェックしています。
4.どんなひどい目にあうのか。
length関数を使うシーンはテスト済、品質が保たれたモジュール内だけではない訳です。上流で調査する際も、C/O当日のその場対応でも使います。
データ移行担当者は瞬発力が求められます。移行中にアラートが上がれば速攻で調べて、即刻リカバリなんとかC/Oに間に合わす、という対応が求められます。
話は逸れますが「お前下手くそやなー」と上から目線の同業の皆様、データ移行では以下の理由から当日不足の事態が起きやすいです。
1.データ移行は他の作業と比べて下に見られやすく、PRJ内で検討が甘くなりやすい。
2.現行システム凍結期間をお客様が短くする傾向が強まり、短時間で素早く移行するニーズがほとんど。スケジュールに無理がかかる。
3.顧客情報は凍結直前まで、何が入ってくるか分からない。
ケース１だと、512文字の定義がされているメモ欄データ移行でエラー発生。
その際に間違ってMysqlに移行途中だった「注文メモ」と「配送メモ」情報に対してlength関数を発行、ゲッ！合計1,500文字も入るわけ無いじゃん..と慌てる訳です。
よく考えればMySQLはバイト返し、全て日本語なら1500バイト＝500文字なんですよね。ちゃんと該当データを取り出し、別の機能で文字数をチェックしなければ問題の真相がわかりません。頭の中がOracle基準で判断をした悪い例です。
同じ関数が環境によって機能が異なることは、判断ミスを招きやすい。
寿命の無駄縮み、大損という訳です。
こういうことで最前線のIT技術者は、日々頑張っているという事例でした。
以上です。ありがとうございました。
