[EC-CUBE覚書]郵便番号検索DB(mtb_zip)の構造のみバックアップの勧め

2011年8月22日

EC-CUBE移行2回目ですが、ダンプするとこでつっかかりました。
やたらとバックアップファイルが重い(><)
原因は、郵便番号検索データでした。
実際にファイルを見たら、最初に入れるとき時間がかかったわけがわかりました・・・。

対処法としては、先に構造だけダンプして、検索データはあとで管理画面から入れます。
初期設定の時に行う「郵便番号登録」ってやつですね。

EC-Cubeのデータベースをバックアップするときの注意点 | こ~でっくす!!

あれ?そういえば初期設定中に異様に時間のかかる処理があったような気がします。
そう、原因は「郵便番号DB登録」
試しにこの部分(mtb_zip)だけを抜いて再度バックアップを取ると約500KB(圧縮時約90KB)になりました。

つまりバックアップの際、mtb_zipはバックアップするな!ということです。
無駄な容量と時間を減らすことにもつながり、管理が楽になるはずです。

データベースのコピーをする際は「mtb_zip」テーブルは構造部分だけをバックアップしてください。
そして、コピーが終わった後に管理画面より「郵便番号DB登録」を行ってください。
念のためにそのSQL文を書いておきます。

DROP TABLE IF EXISTS `mtb_zip`;
CREATE TABLE `mtb_zip` (  `code` text collate utf8_unicode_ci,
  `old_zipcode` text collate utf8_unicode_ci,
  `zipcode` text collate utf8_unicode_ci,
  `state_kana` text collate utf8_unicode_ci,
  `city_kana` text collate utf8_unicode_ci,
  `town_kana` text collate utf8_unicode_ci,
  `state` text collate utf8_unicode_ci,
  `city` text collate utf8_unicode_ci,
  `town` text collate utf8_unicode_ci,
  `flg1` text collate utf8_unicode_ci,
  `flg2` text collate utf8_unicode_ci,
  `flg3` text collate utf8_unicode_ci,
  `flg4` text collate utf8_unicode_ci,
  `flg5` text collate utf8_unicode_ci,
  `flg6` text collate utf8_unicode_ci
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

上記で紹介されているのは、現在流通している2系の表記になります。
今回の1系だと以下の表記になります。ご参考まで。

DROP TABLE IF EXISTS `mtb_zip`;
CREATE TABLE `mtb_zip` (
  `code` text,
  `old_zipcode` text,
  `zipcode` text,
  `state_kana` text,
  `city_kana` text,
  `town_kana` text,
  `state` text,
  `city` text,
  `town` text,
  `flg1` text,
  `flg2` text,
  `flg3` text,
  `flg4` text,
  `flg5` text,
  `flg6` text
) ENGINE=InnoDB DEFAULT CHARSET=ujis;

ちなみに合併などで郵便番号が変更される時もありますので、
本来は年毎くらいにデータの更新が必要になってきますね。
それはまた次の機会に。