UPC+EAN13+EAN8=GTINコード
ちょいと趣味的かつ専門的?な話をば。
北米圏では商品流通管理に12桁のUPCコードを使ってる。ヨーロッパ圏+日本では13桁のEAN(日本ではJANだけど事実上同じ)を使ってる。出版業界はすでにEAN圏に吸収された。(JAN8なんて鬼子もいるが、まあ一応こいつも統合されたし)
そしてUPCとEANは、GTINコードとして世界的に統合された。
まあ、そのこと自体は(そこはかとない理想主義的な香りが気になりつつも)データオタクたる俺としては諸手を挙げて歓迎すべきことなんであーだこーだは言わないのだが(てかもう移行してるし)。
EANコードやUPCコードをどうやってGTINコードに変換するのかを調べてみた。
結論としては、どれでも桁数が14になるまで頭に0を追加し続けることでオーケーのようだ。JAN8でさえもそうなのだ。
逆に行うと、先頭の0の数でそれがEANかUPCかJAN8かなどが判別できると言う訳だ。
※EAN14は元々がGTINらしい……先頭の数字で、EAN13の商品がいくつ入っている商品なのかを設定できるそうだ。先頭の数字が何の時にいくつ入りになるかは、業者毎に勝手に決められるので、その辺のデータをどうやって取得するかだよなあ。
まあ、なんでこんな話をしたのかと言うと、持っているアイテムのリストをデータベース化しようと思ったら、なんと俺の部屋にはUPCの商品すらも転がっていたりして、さてこれはどうやって登録すべきかと悩んで調べてみたのですよ。
ちなみにUPCの商品は、北米版ランブルローズと北米版「もけもけ大正電動娘ARISA」だったりする。
今作ってるデータベースにgtinカラムとupcカラムを追加して、プログラムにも変更を加えることにする。
古いセッションの削除
セッションデータの削除 - 永字八法の改良版。つーか、こっちのが全然いい。
PerlからCGI::Sessionを通じてPostgreSQLを使ってセッション管理をしている場合、古いセッションを自動で削除していく方法を考える。
1・セッション情報テーブルにカラムを一つ追加する。
idとa_sessionカラムに加え、セッションの最終更新日を登録するlast_updateを追加する。このlast_updateはtimestamp型で、初期値はnow()とする。
ALTER TABLE sessions ADD last_update TIMESTAMP WITHOUT TIME ZONE DEFAULT now() NOT NULL
2・関数を一つ作成する。
その時、現在のnow()を取得する関数を作る。
CREATE FUNCTION set_last_update() RETURNS opaque AS ' begin new.last_update := 'now'; return new; end; ' LANGUAGE 'plpgsql';
3・テーブルにトリガーを結びつける。
関数とテーブルをトリガーで結びつける。
CREATE TRIGGER before_flush BEFORE UPDATE ON sessions FOR EACH ROW EXECUTE PROCEDURE set_last_update()
4・まとめ
こうすることで、sessionが更新される度に自動的に最終更新日付も更新される。
あとは、日付で3日前とかを削除するDELETE文を定期的に発行するだけで古いセッションが削除される。
DELETE FROM sessions WHERE last_update+interval '1 week' < now();
上記は一週間前から更新されていないセッションを削除する例。
古いセッションの削除
セッションデータの削除 - 永字八法の改良版。つーか、こっちのが全然いい。
PerlからCGI::Sessionを通じてPostgreSQLを使ってセッション管理をしている場合、古いセッションを自動で削除していく方法を考える。
1・セッション情報テーブルにカラムを一つ追加する。
idとa_sessionカラムに加え、セッションの最終更新日を登録するlast_updateを追加する。このlast_updateはtimestamp型で、初期値はnow()とする。
ALTER TABLE sessions ADD last_update TIMESTAMP WITHOUT TIME ZONE DEFAULT now() NOT NULL
2・関数を一つ作成する。
その時、現在のnow()を取得する関数を作る。
CREATE FUNCTION set_last_update() RETURNS opaque AS ' begin new.last_update := 'now'; return new; end; ' LANGUAGE 'plpgsql';
3・テーブルにトリガーを結びつける。
関数とテーブルをトリガーで結びつける。
CREATE TRIGGER before_flush BEFORE UPDATE ON sessions FOR EACH ROW EXECUTE PROCEDURE set_last_update()
4・まとめ
こうすることで、sessionが更新される度に自動的に最終更新日付も更新される。
あとは、日付で3日前とかを削除するDELETE文を定期的に発行するだけで古いセッションが削除される。
DELETE FROM sessions WHERE last_update+interval '1 week' < now();
上記は一週間前から更新されていないセッションを削除する例。
古いセッションの削除
セッションデータの削除 - 永字八法の改良版。つーか、こっちのが全然いい。
PerlからCGI::Sessionを通じてPostgreSQLを使ってセッション管理をしている場合、古いセッションを自動で削除していく方法を考える。
1・セッション情報テーブルにカラムを一つ追加する。
idとa_sessionカラムに加え、セッションの最終更新日を登録するlast_updateを追加する。このlast_updateはtimestamp型で、初期値はnow()とする。
ALTER TABLE sessions ADD last_update TIMESTAMP WITHOUT TIME ZONE DEFAULT now() NOT NULL
2・関数を一つ作成する。
その時、現在のnow()を取得する関数を作る。
CREATE FUNCTION set_last_update() RETURNS opaque AS ' begin new.last_update := 'now'; return new; end; ' LANGUAGE 'plpgsql';
3・テーブルにトリガーを結びつける。
関数とテーブルをトリガーで結びつける。
CREATE TRIGGER before_flush BEFORE UPDATE ON sessions FOR EACH ROW EXECUTE PROCEDURE set_last_update()
4・まとめ
こうすることで、sessionが更新される度に自動的に最終更新日付も更新される。
あとは、日付で3日前とかを削除するDELETE文を定期的に発行するだけで古いセッションが削除される。
DELETE FROM sessions WHERE last_update+interval '1 week' < now();
上記は一週間前から更新されていないセッションを削除する例。
そう言えば。
http://www.13hz.jp/2006/09/post_678c.html
どっかで高速な遣り方ってのを読んだなあ。
同じデータベースをHDDとメモリーに構築する。(正確には、HDD上のデータベースをメモリーにコピーする)。
SELECT系は全て高速なメモリー上のデータベースに投げる。その他のINSERT,UPDATE,DELETE系は両方に同じSQL文を投げる。メモリー上は高速に処理され、HDD上は低速だがゆっくり処理される。
マシンがこけた時、メモリー上のデータベースはぶっとぶが、HDD上のデータベースは生き残る(はず)。
そんな仕組みを読んだ覚えがある。
でもまあ、そんなのは自鯖組んでからの話だよな。
そう言えば。
http://www.13hz.jp/2006/09/post_678c.html
どっかで高速な遣り方ってのを読んだなあ。
同じデータベースをHDDとメモリーに構築する。(正確には、HDD上のデータベースをメモリーにコピーする)。
SELECT系は全て高速なメモリー上のデータベースに投げる。その他のINSERT,UPDATE,DELETE系は両方に同じSQL文を投げる。メモリー上は高速に処理され、HDD上は低速だがゆっくり処理される。
マシンがこけた時、メモリー上のデータベースはぶっとぶが、HDD上のデータベースは生き残る(はず)。
そんな仕組みを読んだ覚えがある。
でもまあ、そんなのは自鯖組んでからの話だよな。
そう言えば。
http://www.13hz.jp/2006/09/post_678c.html
どっかで高速な遣り方ってのを読んだなあ。
同じデータベースをHDDとメモリーに構築する。(正確には、HDD上のデータベースをメモリーにコピーする)。
SELECT系は全て高速なメモリー上のデータベースに投げる。その他のINSERT,UPDATE,DELETE系は両方に同じSQL文を投げる。メモリー上は高速に処理され、HDD上は低速だがゆっくり処理される。
マシンがこけた時、メモリー上のデータベースはぶっとぶが、HDD上のデータベースは生き残る(はず)。
そんな仕組みを読んだ覚えがある。
でもまあ、そんなのは自鯖組んでからの話だよな。