最後に映画館に入ったのはもう５年以上前だけど、久しぶりにこの映画を見てみようかな？
http://black-genkai.asmik-ace.co.jp/
ブラック度検定では、0%だったんだけどね。
2009年11月1日日曜日
DB設計その２
その昔、大量の件数が入っているテーブルデータのものに、別のデータを載せなきゃいけないことがありました。でもそのデータっていうのは元データの生成/消滅タイミングが違っていて、生成確率も違うものだったんです。
例えば架空の図書館システムだと、以下のテーブルに、
所有図書(所有図書ID,状態,.....)
貸出状態をつけちゃったようなもの。
所有図書(所有図書ID,状態,...,貸出日時,貸出会員ID)
実際には、図書の貸出なんて所有図書の1%以下となるので、こう作るべきだったような気がします。
所有図書(所有図書ID,状態,...,)
現在貸出(所有図書ID,貸出日時,会員ID,貸出時状態,貸出時備考)
もし、履歴が必要なら追加でこんなテーブルかな？
貸出履歴(所有図書ID,貸出日時,会員ID,貸出時状態,貸出時備考,返却日時,返却時状態,返却時備考)
。。。やっぱり、自分の所為（せい）にして、記事を書くモチベーションを保てるほど、できてないや。元ねたが他人と絡む技術情報についての記事件数が少なくなっちゃうんだろうなぁ。
2009年10月26日月曜日
ドロップダウンリストのAutoPostBackにした後の対策
ASP.NET Webサイトで、AutoPostBack をtrueにしたドロップダウンリストで、マウスホイールを転がすと、PostBackが大量に走り、ついには同時処理数をオーバーしたというエラーが発生することがある。
この対応として、ドキュメントのReadyStateの値で制御した。
asp:DropDownListタグで、onchangeプロパティ内で、ReadyStateを書いた。そうすると、htmlに展開されたとき、asp:DropDownListは、selectタグに変わって、onchangeで、ポストバックのメソッド呼び出しをしている部分の前の部分にReadyStateに関する処理となるようになった。
この対応として、ドキュメントのReadyStateの値で制御した。
asp:DropDownListタグで、onchangeプロパティ内で、ReadyStateを書いた。そうすると、htmlに展開されたとき、asp:DropDownListは、selectタグに変わって、onchangeで、ポストバックのメソッド呼び出しをしている部分の前の部分にReadyStateに関する処理となるようになった。
2009年10月25日日曜日
テーブル設計について
DBの話。
かなり昔、テーブル設計を出したときに先輩に、テーブル名が短くて列名が長いんですね、って言われてしまった。
具体的な例を挙げると、私が、Author(AuthorId,AuthorName,...)と作ったらところ、TechnicalAuthor(Id,Name)にするような感じで指摘受けたような感じ。
「そんな構造体みたいな考え方はだめに決まっているじゃん」と思ったけど、議論しても疲れそうなので、そのときは、「そうですね。でもつくっちゃったからこれでいきましょう」といっちゃいました。
構造体と違って、テーブルは、複数のテーブルを連結して利用することをするので、同じ意味のものは同じ列名にして、違う意味のものは違う列名にしなきゃいけないと思っています。
そこで、列名がId。これってBook.IdとAuthor.Idをリンクしてしまうと大変なことになってしまうし、SQLにおける自然結合は、列名の一致が前提条件になっています。この点から問題だと思うのですが。
（自然結合を実装したDBMSを見たことはありませんが、書き方は、「Table1 natural join Table2 on AuthorId」）
また、連結した時点でテーブル名の別名をつけることはよくある話で、テーブル名が分らなくなるとデータの意味が分らないのであれば、あんまりよくないテーブル設計と思うんだけど。
最後に、テーブルを連結して取得した値の列名(Name)に意味ある名前にするために、別名を使うより最初から意味ある名前にしておけばいい話だと思う。
最近も、外部キーは避けたいなんていっている人が居る。外部キー制約が気になるときには外部キー制約を無効にして、終わったら外部キー制約を有効にしたほうが、ずっと便利なのに。（たとえ投入データに制約違反がでて制約の有効化に時間がかかっても不整合データが居残るよりよっぽどまし。）
ま、なかなか思うようにはならないですね。
かなり昔、テーブル設計を出したときに先輩に、テーブル名が短くて列名が長いんですね、って言われてしまった。
具体的な例を挙げると、私が、Author(AuthorId,AuthorName,...)と作ったらところ、TechnicalAuthor(Id,Name)にするような感じで指摘受けたような感じ。
「そんな構造体みたいな考え方はだめに決まっているじゃん」と思ったけど、議論しても疲れそうなので、そのときは、「そうですね。でもつくっちゃったからこれでいきましょう」といっちゃいました。
構造体と違って、テーブルは、複数のテーブルを連結して利用することをするので、同じ意味のものは同じ列名にして、違う意味のものは違う列名にしなきゃいけないと思っています。
そこで、列名がId。これってBook.IdとAuthor.Idをリンクしてしまうと大変なことになってしまうし、SQLにおける自然結合は、列名の一致が前提条件になっています。この点から問題だと思うのですが。
（自然結合を実装したDBMSを見たことはありませんが、書き方は、「Table1 natural join Table2 on AuthorId」）
また、連結した時点でテーブル名の別名をつけることはよくある話で、テーブル名が分らなくなるとデータの意味が分らないのであれば、あんまりよくないテーブル設計と思うんだけど。
最後に、テーブルを連結して取得した値の列名(Name)に意味ある名前にするために、別名を使うより最初から意味ある名前にしておけばいい話だと思う。
最近も、外部キーは避けたいなんていっている人が居る。外部キー制約が気になるときには外部キー制約を無効にして、終わったら外部キー制約を有効にしたほうが、ずっと便利なのに。（たとえ投入データに制約違反がでて制約の有効化に時間がかかっても不整合データが居残るよりよっぽどまし。）
ま、なかなか思うようにはならないですね。
ページディレクティブ
前のプロジェクトで作ったASP.NETのページ、ポストバック時に、前回のブラウザ位置を覚えて再現するために、javascriptを使っていたっけ。
でも、ページディレクティブのMaintainScrollPositionOnPostbackを使えばよかったんじゃなかろうか？
でも、ページディレクティブのMaintainScrollPositionOnPostbackを使えばよかったんじゃなかろうか？
登録:
投稿 (Atom)