[EC-CUBE覚書]郵便番号検索DB(mtb_zip)の構造のみバックアップの勧め
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;
ちなみに合併などで郵便番号が変更される時もありますので、
本来は年毎くらいにデータの更新が必要になってきますね。
それはまた次の機会に。
ディスカッション
コメント一覧
はじめまして、code-xのひびきと申します。
EC-Cubeの補足、ありがとうございます。
私の方からも同記事からリンクを貼らせていただきました。
EC-Cubeは非常に味のあるソフトウェアだと思いますので、普及への一助になればと思います。
現在、私の方は案件がなく、持て余してしまっているのですが、今後何かあれば私も参考にさせていただきますので、今後ともよろしくお願いいたします。
ひびきさん、はじめまして。
その節は大変助かりました!今回文章にまで入れてくださってありがとうございます。
最近は新規はあまりなく、移行案件が多いですが、気が付いたことがあったら、その都度書いていこうと思っております。
こちらこそ、よろしくお願いします(^^)