2007-01-03 Wed
横浜駅西口 ダイヤモンド地下街 まん天餃子
考え事して実装して、とやっていたら辺りが暗くなったので、
ご飯を食べて八王子へ戻ることにしました。
まん天餃子というダイヤモンド地下街にある店に入りました。
まん天餃子2人前とご飯とスープを店内でいただきました。
きゅうりのぬか漬けは売り切れていました。残念。
味は美味しかったです。食べようと思えば倍くらい食べれそうです。
でも、ちょっと足りないくらいがよろしかろー、ということでやめました。
すごく小さなカウンターしかなくて持ち帰り中心なんですけど、
店内では餃子とビールで1杯やってる人が3組もいてギューギュー。
また来ようかな。
DBICのリレーションが良くわからないのでメモ - 1対多
[2007-01-08]:追記
[2007-01-07-0]で、DBICのリレーションシップについてのエントリを
書きました。以下は非常にいい加減なので[2007-01-07-1]をどうぞ。
よく分からない1対多のhas_manyと、belongs_toの使い方を理解したい。
引き続き、以下の文献をグルグル読みながら理解してみる。。
101号室より愛をこめて: [DBIx::Class][DBIC][perl] DBIx::Classのリレーション
Perl/DBIC - Nekokak's core dump
DBIx::Class::Manual::Cookbook
DBIx::Class::Relationship
カエルチュウイホウ - DBICで多対多の設定を
カエルチュウイホウ - DBICで多対多
以下に出てくるコードとかは参照先を書いてませんが、
上の参考記事のどこかから持ってきました。ありがとうございます。
Userテーブルと本テーブルがあって、Userが本を各自多数持っている状態を考えると、いい感じかな。
基本的なことは、1対1と同じ。
user_id text primary key,
password text,
....
);
CREATE TABLE Book (
book_id integer primary key,
user_id text,
name text,
author text,
....
);
こんなときに、
や
のように記述できる。
前者は$user->booksで、ユーザが持っている本のリストを得られて、
後者は$book->user_idで、着目している本を持っているユーザのリストを得られるのだ。
うーん、なんか不十分な気がするので、もうちょっと例を探そうかな。
いや、ドキュメント中心にちゃんと読もう。
DBICのリレーションが良くわからないのでメモ - 1対1
[2007-01-08]:追記
[2007-01-07-1]で、DBICのリレーションシップについてのエントリを
書きました。以下は非常にいい加減なので[2007-01-07-1]をどうぞ。
よく分からないというか、has_oneとmight_haveとbelong_toの明確な違い
が分からなくて、どうすれば一生間違いなく理解できるかなと、
これらを見て、理解することから始めた。
101号室より愛をこめて: [DBIx::Class][DBIC][perl] DBIx::Classのリレーション
Perl/DBIC - Nekokak's core dump
DBIx::Class::Manual::Cookbook
DBIx::Class::Relationship
カエルチュウイホウ - DBICで多対多の設定を
カエルチュウイホウ - DBICで多対多
以下に出てくるコードとかは参照先を書いてませんが、
上の参考記事のどこかから持ってきました。ありがとうございます。
リレーションはテーブル間にリファレンスを張るようなもの。
JOINでテーブルをくっつけてくれる。
has_oneとmight_hasとbelongs_toはテーブルAの行とBの行の間に1:1対応の関係
has_one : INNER JOIN(一致する行のみを持ってくる)
might_have : LEFT JOIN(一致しない行には、片側にNULLを付けて持ってくる)
user_id text primary key,
password text,
....
);
CREATE TABLE Profile (
user_id text primary key,
name text,
mail text,
....
);
こういう風に互いに相手のprimary keyがどこかに入っているときには、
has oneでリレーションを記述できる。
や
のようにできる。
こんな風にリレーションを記述しておくと、$user->profileみたいにアクセスできる。
この場合Primary Keyを使ってJoinしてる。
もちろん、相手のPrimary Keyが自分のPrimary Keyじゃなくても良い。
以下のように、Primary Keyが共有じゃないけど、普通のカラムには持っているときには、
user_id text primary key,
profile_id text,
password text,
....
);
CREATE TABLE Profile (
profile_id text primary key,
user_id text,
name text,
mail text,
....
);
や
のようにできる。
つまり、has_oneはINNE RJOINする相手のテーブルが、自分のPrimary Keyを
Primary Keyか普通のカラムのどれかに持っていることをあらわしている。
might_haveはLEFT JOINする以外はhas_oneと同じ。
でも、都合よく相手が自分のPrimary Keyを持っていないときもある。
user_id text primary key,
password text,
....
);
CREATE TABLE Profile (
profile_id text primary key,
user_id text,
name text,
mail text,
....
);
このときUserから見ると、ProfileはUserのPrimary Keyをもっている。
けど、Profileから見ると、UserはProfileのPrimary Keyをもっていない。
なので、
これはできそうだけど、逆は？？？って感じ。
こういうときにbelongs_toを使う。
使い方はこんな感じ。
Profileは、Userのアクセサ名テーブルか、
UserのPrimary Keyに従ってJOINするよ、という解釈ができる。
横浜西口 スターバックス
実装しようとして入ったら店内がとてつもなく混んでいてビックリ。
3分くらい並んだら座れたので、セーフ。
QUOVADIS(クオバディス)のスケジュール帳
小さいスケジュール帳を試したくて、横浜のハンズでメモ帳を購入した。
購入するときに、以下のポイントを意識した。
・何年後かにも、安定して供給されること。
・使っていて気持ちが良いこと。
・小ささと使いやすさのバランスが良さそう
・手帳型
いろいろ見たけど、QUOVADIS(クオバディス)が良さそうなので、
Trip PrestigeのJapanese Editionを購入した。
カバーのバリエーションは少なかったけど、
今年は情熱的になろうということで、まずは形から入ろうと赤を選択。
かなりコンパクトで、見開き1週間なんですよね。
8時から22時までしか書いていないということは、
これくらいの範囲で働くのが効率よろしめであるということかなー。
22時以降も実装してウンウン言ってちゃいかんのかもしれない。
