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上のデータベースは生き残る(はず)。
そんな仕組みを読んだ覚えがある。
でもまあ、そんなのは自鯖組んでからの話だよな。