メッセージ。 - diary
2011-03-09
# にゃー
なんかイマイチ、DBMSを使ったソフトウェアの実装方法が、よく分からん。やりたいことは座席予約システムみたいな、リソースを取り合うような処理で、まぁよくあるシチュエーション。なおかつ、条件としては、複数のSQLの成功を保証する必要はない。つまりトランザクション不要。こういうとき自分は、insertを発行して成功したら処理を続け、失敗したらユーザに戻すか、失敗時処理を実行するようにしている。で、これでいいのかどうかがよく分からん。いや、あってるはずだとは思うのだが、こういうときの定石みたいのが、ググってもヒットしないのだ。トランザクションの話ばかり引っ掛かって、それ以前の話というか、基本の理屈を説明してくれてるページにたどり着けない。悪くいえば、「こうすればこうなる」的なものが多い。
あと、insertでの一意性保証方式だと、一意性が必要な要素ごとにテーブルを作らなければならなくて、これは不便だ。たとえば列車予約システムだと、ひかり105号、106号、107号と、列車ごとにテーブルを作らなきゃならなくなる。Oh!No!!!
今日はやけにキータッチに失敗する。あと、頭を使う内容を書いてるとき、打ち間違いが多くなってタイピングが遅くなる気がする。
あ、そうか。テーブル制約だっけ。あれを使えばいいのかな?
あと、insertでの一意性保証方式だと、一意性が必要な要素ごとにテーブルを作らなければならなくて、これは不便だ。たとえば列車予約システムだと、ひかり105号、106号、107号と、列車ごとにテーブルを作らなきゃならなくなる。Oh!No!!!
今日はやけにキータッチに失敗する。あと、頭を使う内容を書いてるとき、打ち間違いが多くなってタイピングが遅くなる気がする。
あ、そうか。テーブル制約だっけ。あれを使えばいいのかな?
2011-03-08
# にゃー
番組としては、この意味深なコメントはまぁ無視で、ぼくとしても、コメントの意味が最初よく分からなかった。でも後からゆっくり考えてみて、いまでははっきり彼の言いたかったことが分かる。彼はきっと、エンジニアとして、目の前にある問題を、解きたくて仕方なくなったんじゃないだろうか。目の前に問題があって、困っている人がいて、でも自分の持つ技術でその問題を解く一助になるんじゃないか。日本にいて研究を続け、学生を教えるのと、チベットで農作物をつくり、地元の人と田を耕すのでは、どちらがより生産的だろうか。どちらがより人の助けになるだろうか。そこには確に人助けという考えもあるだろうが、それ以上にエンジニアとしての性のようなものがあったんじゃないかという気がする。