データベース化する前にやること

データ構造を練らないとダメです。

　

<Empty>
|集合　　　　　　|
|・属性/項目等.|
|・　　　　　　　　.|
|・　　　　　　　　.|

<Relation>
---　１：１
-0-　１：１(もしくは０)
--<　１：ｎ
-0<　１：ｎ(もしくは０)
>-<　ｎ：ｍ
-n- リレーションに属性等補足を必要とする場合。(nは補足番号)

|個人情報　　　　　　 .|
|・HN等固有情報　　 .|　 　 |世間体　　　　 .|
|・人としての格　　　　|----|・人としての格 |
|・ちゃねらとしての格.|┐　 |・社会適応度　|----┐
　　　　　　　　　　　　　 .|　　　　　　　　　　　　　　　.|　　|今を生きる 　　 .|
　　　　　　　　　　　　　 .| .|2ch　　　　　　　　　　|　.├1-|・社会適応度幅.|
　　　　　　　　　　　　　.└|・ちゃねらとしての格|　 .|　　|・分析結果　　　 |
　　　　　　　　　　　　　　 .|・社会適応度　 　 　 |-.┘

1：｢世間体｣から｢２ｃｈ｣を減算した結果が｢今を生きる｣ﾚﾝｼﾞをもってJoinする。

※｢世間体｣と｢２ｃｈ｣は､母の苦情により｢格｣より２つのEmptyに分離。

<個人情報>
某ｽﾚの1，ヒッキー，DB厨
固定Ａ，中堅サラリー，ガノタ
某ｽﾚの99，ヒッキー，神

<世間体>
社長，１５
中堅サラリー，１０
ヒッキー，０

<２ｃｈ>
神，２０
ＤＢ厨，１０
職人，１０
ガノタ，５
一見さん，０

<今を生きる>
０以下，カウンセリング要
１〜５，休養が必要
６〜１０，特に問題なし
１１以上，家族を省みよう

極めて難しそうな内容なので
取りあえず気が向くまで逃げ。

いきなり書いても第三者にはわからんでしょ。

ERモデル
http://www.kogures.com/hitoshi/webtext/db-ermodel/
データの正規化
http://www.kogures.com/hitoshi/webtext/db-seikika/

Ｗｅｂ教材：データベース
http://www.kogures.com/hitoshi/webtext/db-intro/index.html

|スレッド　　　　 |
|・名称　　　　　 |　　　　　　　　　　　　　　|個人情報　　　　|
|・趣旨　　　　　 |　　|スレッド特性　 .|　　|・HN等固有情報|
|・レスの難易度|---|・レスの難易度|　　|・気力　　　　　　.|
|・嗜好ﾊﾟﾀﾝ　　 |┐ .|・DB熟練度　　.|---|・DB熟練度 　　 |
　　　　　　　　　　.|　.|・AA熟練度　　.|---|・AA熟練度 　　 |
　　　　　　　　　　.|　.|・詳細　　　　　 |　　.|・嗜好ﾊﾟﾀﾝ　　　.|>0┐
　　　　　　　　　 .└----------------------------------┘
建てた本人が言うのは何だけども
以上のような関係で運用は難しいかなと？
（勉強したいコが使えば役に立つとは思うけど）

hoge

アイテムテーブルと属性テーブルがあって、
あるアイテムには自由に任意の属性（0〜10）を設定できます。
属性の持ち方は、属性テーブルの主キーである属性コード
をリストで持ちたいと考えています。
ただ、属性コードからその属性に属するアイテムを
頻繁に検索するため、属性コードにはインデックスを
設定したいです。
この結果、アイテムテーブルに、attribute_id1〜10
という感じで、10個の属性用のフィールドを設定し、
全てにインデックスを張っています。
もっと良い方法ないですか？

アイテム明細テーブル(アイテムテーブルのプライマリキー・属性番号(0〜10)・属性コード)を作って
アイテムテーブルから属性に関する情報を消す。

メリット：
属性コードでの検索SQLが短くなる
1アイテムが保持する属性が可変になる（20個でも100個でも増やせる）
デメリット：
既存のプログラム等の変更が大変。
アイテム明細テーブルのレコード数が増えやすい。
容量が増える。

ってのも出来ますね。

XML DBって、いう手もあります。
それなりに考えないといけないこと、あるけど、
基本的な構造についてのみ注力できる。
どうでもいい、枝葉末節なフィールドについては、あいまいな
まま、スタートできる。

時代かわったなーという感じ。

問題は、
・X-Queryの標準化がおくれている。
・システムが重い

　

ドラゴンボール板http://cgi32.plala.or.jp/mg916/dragon/
２ちゃんねるｐ http://www11.plala.or.jp/mg916/
こっちにも来てください！　　

ちょっぺちょめちょめ

DB新人の設計は無駄に正規化しすぎて速度を落としてるのが多い。

>>16
確かに。
無駄なinner join重ねられても困るよね。
特にPerformanceを追求するようなときとか。

ＤＢの仕事してた頃は
マスタテーブル類には２つぐらい予備のカラム作ってた。
仕様変更ｱﾀｯｸに対処するため。
あとレコード数が数個しか発生しない情報は
雑類テーブルに適当に投げこんでいた。ﾋﾃﾞｪ

>>18
私はど素人ですが
某SIの製品で同様のテーブル見ました。
最初なんじゃコリャ!!DQN決定と思ったけど、
よく考えた後、ある意味これもProの仕事だろうかと、
と思うようになりました。

あぼーん

うちの先輩の設計は無駄に非正規化しすぎて保守性を落としてるのが多い。

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

死ね！山崎　

EmptyじゃなくてEntityだと思うんですが・・・

>>12
＞問題は、
＞・X-Queryの標準化がおくれている。

問い合わせ専用のX-Queryだけでなく、更新系I/F仕様も遅れている(いまだにクソ重いDOMが主流)
W3C手動だとXML-Schemaのときのように、もめるだけもめて先に進まない傾向あるから
XML-DB関連の仕様検討はISOあたりに任せたほうがいいんじゃないの？

＞・システムが重い

これは同様の業務データを扱わせた場合を言っているのだと思うけど、
XMLデータはRDBでも設計しだいでやってしまいがちなデータの重複
（正規化されていない状態）が大量に発生してしまうので、
いろいろなXML-DBでうたっている高速処理のうち、参照は
なんとかしようと躍起になっているが、更新系はめためた。

また、データアクセスの効率化をなるべくメモリに頼らずに
最適化するために物理格納構造を工夫してきた各社RDBMSにくらべ、
オンメモリ処理とノード分散にたよりすぎ、せっかく某大手キャリアに
採用されたのにその評判を落としてしまったため、
他社に買収され製品名まで変わってしまい、２度と「XML-DB」だという
ことを口にしなくなった某製品のユーザさまご愁傷様でした(^^;)
＃メモリは昔に比べたら安くなった(容量当りの単価)というが、
＃処理すべきデータ量は格段に増えた(テラ・ペタバイト)ため、
＃相対的に変わっていないのが現実

いまだにネイティブXML-DBと全面に押しているのはTaminoぐらいだな。
ほかのやつらは検索専用(データ統合というキーワード)、B2B Messaging/EAI
など特定ジャンルに特化しちゃった。

○racleのそれはめんどっちいからパス。