なぜＲＤＢはあんなに難しいのか？
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGＲＤＢを使ったプログラムを開発してます。
テーブルの設計者がおかしなテーブルを作ってくれたせいで大変です。
たとえば
テーブルＡに二つの外部キーがあり
それぞれさしているものはテーブルＢの同じレコードです。
本人いわくどちらを使ってもいいようにと気を使ってくれたようです。
だからテーブルＡのレコードを更新するときは
二つの外部キーの同期を考えてプログラムを作っています。
ほかにも
テーブルＡのレコードを更新したら
テーブルＢのレコードも更新しないと整合性が保たれない
というのもあります。
作り直してくれと頼んだのですが
論理的に間違いはないと一点張りです。
かく言うわたしもＲＤＢの分析設計（正規化）は
素人同然です。（がこのテーブル設計者よりはマシです）
こいつに理にかなった説明をして作り直させるため
分析設計正規化について勉強したいのですが
よい参考書としてどのようなものがあるのでしょうか？
当方、 「なぜＣ＋＋はあんなに難しいのか？ 」立てたものです。
0002デフォルトの名無しさん
NGNGテーブルＡに二つの外部キーがあり
それぞれさしているものはテーブルＢの同じレコードです。
本人いわくどちらを使ってもいいようにと気を使ってくれたようです。
だからテーブルＡのレコードを更新するときは
二つの外部キーの同期を考えてプログラムを作っています。
【補足】
テーブルＢの主キーは２つあります。
0003バイト
NGNG0004デフォルトの名無しさん
NGNG>当方、 「なぜＣ＋＋はあんなに難しいのか？ 」立てたものです。
君んとこの職場って・・・楽しそうだね。
0005デフォルトの名無しさん
NGNGああ。たのしいよ。
インプットとアウトプットさえ合ってればよしとする体制でとりくんでるよ。
はじめてソフト開発学ぶやつはこれが普通だと思っている。
だから何も考えずに
もっと給料の高い（徹夜必死）のソフト開発会社に転職する。
そこでホントの厳しさをしりこの業界を去っていくのがおおいよ。
0006デフォルトの名無しさん
NGNG正規化つってもよっぽど複雑じゃなければ
そう直感に反するわけでもなし。
むしろ RDB(の製品) は管理が面倒、複雑だと思うがどうか。
0007デフォルトの名無しさん
NGNGユニークなインデックスは幾つでも付けれたと思うが、
主キーは１つしか付けれないと思うぞ。
候補キーか？
>論理的に間違いはないと一点張りです。
その論理とやらをきいてみれ。
１対１じゃそれが一人よがりな論理だと認めたがらんだろうから
プロジェクトメンバー全員の前でレビューさせてみれ。
それからそいつは通産省のＤＢスペ試験でも受験させた方が
いいな。
0008デフォルトの名無しさん
NGNG優れた設計のテーブル群を実際に扱いながら勉強したので
どんな本が世の中にあるのか知りません。実際に稼働している
きれいなテーブルを見るのが一番早いのだけど、そんなのには
なかなか出会えないですね。
私も、その後腐ったテーブル設計を山ほど見てきて、一番最初に
出会った設計者がどれだけ優れていたか実感したわけですが。
てなわけで、運の悪い人は自分で勉強するしかないわけだけど
「正規化」とかのキーワードで探せば、山ほど情報はあるはず。
私も、ＤＢスペシャリスト試験はいいと思うよ。
0009デフォルトの名無しさん
NGNGOracleシステム 構築・運用ガイド 3200円
がなかなかいい本と思われ。読んでみて。
でも、１のような正規化オンリーを勉強したい場合はちょっと違うかも。
RDB自体は難しくも何とも無いだろ。きちんと設計すれば、あれほど楽な
ものは無いぞ。
でも設計者がバカだとプログラマが泣くんだよな。
あとシステムのパフォーマンスを決めるのは、最終的にはテーブル設計。
SQLでどんなすさまじいコードを書こうが、テーブルがタコだとダメですな。
数万件くらいだと、ハードでごまかせるけどね。
0010１です
NGNG参考文献の紹介もありがとう。
学生の時に少々ソフトウェア工学全般を学んだときに
本質的なところ捕らえているなと興味をもっていました。
でも現実はかなりいいかげんなものだということをしりました。
いい設計者に出会いたいな。
そしてそこから学べるものを学びたいな。
0011１です
NGNGＲＤＢとは関係ないがＣでプログラムを組んでいたとき
変な決まりがあった。その一部を紹介。
・else if はマシンに負荷がかかり他人の迷惑になるので使用禁止。
・再帰処理は使用禁止。
ソースを見せたときこんな書き方はない。と一喝されて以来。
いまは２社目なんですが友人もへんなコードを
書かされているという話しかきかないような。
0012デフォルトの名無しさん
NGNG第三正規化が全てに掛かってる＆挿入の関係でインデックスは全く
使用しない、という仕様なんだが、参照の速度が足りないって
困ってたな…
アホばっかしだ、みかかの連中。
0013デフォルトの名無しさん
NGNGみかかにもエースはいるようですよ。
一部に集められて、通常運用業務にはかすばっかりらしいですが
0014デフォルトの名無しさん
NGNG> テーブルＡに二つの外部キーがあり
> それぞれさしているものはテーブルＢの同じレコードです。
「親表/子表」という表現を使うとすれば、
A: 子表
B: 親表
です。よって、
> ほかにも
> テーブルＡのレコードを更新したら
> テーブルＢのレコードも更新しないと整合性が保たれない
> というのもあります。
というのは、概念上正しくありません。
0015デフォルトの名無しさん
NGNG> 本人いわくどちらを使ってもいいようにと気を使ってくれたようです。
というようなものではありません。「使う」って何のことでしょうか？
> だからテーブルＡのレコードを更新するときは
> 二つの外部キーの同期を考えてプログラムを作っています。
外部キーはその性質上、親キーとの整合性があっていれば良いわけで、
いくつあろうが、外部キー同士の同期などというものは、考慮する必要は
ないはずです。
> 論理的に間違いはないと一点張りです。
まぁ、なんというか、お互いわかっていないような気がします。
0016デフォルトの名無しさん
NGNGDDLを、問題が無いように一般的な項目名に変更し、関係無いカラムの
定義を殺ぎ落としたものを、ここに書いてくれれば、それが論理的には
どうなのか、という議論になるかもしれません。
0017名無し
NGNGどこで正規化を止めるか、どう非正規化できるかです。
正規化は機械的に誰でもできます。
0018デフォルトの名無しさん
NGNG正規化よりも、エンティティと属性の抽出の方が大事。
特に、目に見えないもののエンティティの抽出。
これが、言うは簡単、行うは難しなんだよね。知識と
経験がものを言うね。
OOのクラス設計と通じるものがあるね。
0019デフォルトの名無しさん
NGNGオブジェクト指向言語のクラスとRDBの表という概念に
親和性が低すぎる気がしません？
たまに頭の中が混乱することがある。
OODB使えば解決するんだろうけど。
0020デフォルトの名無しさん
NGNGインピーダンスミスマッチと呼ばれる、昔からある
開発者の悩みの種。
でも、いますでに出来上がってるベンダ製RDBMS並の
スケーラビリティだのを持っている他のデータ永続化
手段がないから、いわばみんな仕方なく使ってるのよん。
OracleDBを一から作るには数百億ドル掛かるとか
どこかに書いてあったが、ほんと？
誰か作ってくれんか？ちゃんと動くOODBMS。
Javaなら比較的簡単じゃないか？他言語と共用
するつもりがなければ、Serializableだけで逝く
事にできるし。
0021那菜紙餐
NGNG> 設計者のスキルは、正規化ができるかではなくて、
> どこで正規化を止めるか、どう非正規化できるかです。
> 正規化は機械的に誰でもできます。
正論かもしれませんけれど、それすらまともに出来ない人がいるから
問題になるんじゃないかと思いますけど。
0022１です
NGNGとりあえずこんなテーブルでプログラム組まされています。
■ GROUP_TABLE
GID GID2 GNAME PARENT_GID
---------------------------------
G94001 01 A NULL
G95088 0101 A/A G94001
G98001 0102 A/B G94001
G98004 010201 A/B/A G98001
G99022 010202 A/B/B G98001
G94011 0103 A/C G94001
G00023 02 B NULL
G00007 0201 B/A G00023
■ USER_TABLE
UID UNAME GID GID2
------------------------------
U93121 SUZUKI G98001 0102
U97101 SATOU G99022 010202
階層構造になっている GROUP_TABLE と
それに関連する USER_TABLE があります。
キーは GID と GID2 どちらでもアクセスできるように２つ。
GID はユニークに振り分けたコードです。
GID2 は階層的なをコードです。
もし PARENT_ID を更新したとき、GID2 を更新する。
下位の階層のレコードがあればそれも更新する。
関連する USER_TABLE のレコードも更新する。
このテーブル設計っていかがなものでしょうか？
またこういう階層構造をテーブル化するにはどのようにしたらよいか？
このテーブル設計者は絶対の自信を持っています。
でもインデックスとは何かを知りません。
なので NULL チェックや ユニークチェックなどの定義はしてくれません。
テーブル名とカラム名前と長さ（すべて固定長文字列２５６バイト）を
定義したにすぎません。
キーと言っているのはそいつがキーだと言っているだけです。
0023１です
NGNG２２の補足
ディレクトリの移動という感じです。
親ディレクトリを変更したら階層的につけられている GID2 を
再設定する仕様です。
テーブル設計者いわく
GID2 の存在理由はそのレコード階層が一目で分かるからだそうです。
0024デフォルトの名無しさん
NGNG十分ですね。で、親が変わった時にすべての子孫レコードを更新
しなければいけない設計は絶対におかしいです。GID2がなんのために
使うフィールドか不明ですが、階層関係をあらわすためだけなら不要
でしょう。親子関係は別テーブルにするという手もあります。
002524
NGNG名前のデータにそんなもん保存してもしょうがないですよね...
この調子だとあちこちに冗長なフィールドをつくってそうですね。
002624
NGNG0027１です
NGNGテーブル設計者のプライドがめちゃくちゃ高いので
直してくれそうにありません。
プログラマはみんな泣いています。
GID2 は親レコードから子レコードへの
関係ともおっしゃっておられます。
PARENT_GID は子レコードから親レコードへの
関係ともおっしゃっておられます。
いま挙げた例はごく一部です。
実際のテーブルはもっと関係が絡み合ってて劣悪です。
マスタテーブルと更新テーブルを２つ作るべきなところも
１つのテーブルでやりくりしています。
これはマスタレコードだよ。とか。これは更新レコードだよ。とかの
カラムをもうけたり。
レコードに日付カラムをつけてレコードを挿入したけれど
処理日付に達するまで予約レコードとして扱うので処理対象外とかね。
0028デフォルトの名無しさん
NGNGPARENT_GID ---PK,REF
GID2
■ GROUP_TABLE
GID ---PK,REF
GNAME
PARENT_GID ---FOR
■ USER_TABLE
UID ---PK
UNAME
GID ---FOR
PK:主キー
REF:親キー
FOR:外部キー
ちょっと考えてみましたがこういうことですか？
0029１です
NGNG>>28
そうなんですが、、、
GROUP_TABLE のレコードは階層的で深さは可変です。
再帰的に？なっています。
0030デフォルトの名無しさん
NGNG再帰的に？なっています。
すみません。意味がよくわからないんですけど、もう少し説明下さい。
(物分り悪くてゴメンナサイ(藁)
003130
NGNGすみません。この部分ですか？
よく見るとデータが
PARENT_GID:GID2=1:1
ではないんですね(汗
でも、そーするとこのGID2って．．．？
0032デフォルトの名無しさん
NGNGプログラマはGIDこそキーだと思ってクエリー書いて一週間に一回GID2を
更新するバッチ書くってのはどう？
003330
NGNG0034１です
NGNGGID をキーとするアプリと
GID2 をキーとするアプリがあります。
これから開発するアプリは GID2 をキーにすることを推奨しています。
GID は既存のアプリで使われているので残してあります。
GID2 は そのフィールド値だけで自分のレコードの階層位置がわかる
絶対パスみたいなものです。
テーブル設計者この仕組みを考え出したことに誇りを感じているので
ねじ伏せるのは用意ではありません。
0035１です
NGNG＞これから開発するアプリは GID2 をキーにすることを推奨しています。
推奨というか GID2 をキーにしろといわれています。
GID2 は値が変動するキーです。この考え自体がへん。
ソースコードはエライ複雑になってます。
わかりにくい。
0036デフォルトの名無しさん
NGNG早速すべてのアプリをGID2をキーにして作り始めましょう。
ただGID2は値が変わることがあるので、その場合には既存のすべての
テーブルやBCPファイルででGID2を参照してるものを調べて更新する必要
があります。欠点と言えばそれくらいでしょうか。
003730
NGNG■ GROUP_TABLE
GID ---PK,REF
GID2
GNAME
PARENT_GID
■ USER_TABLE
UID ---PK
UNAME
GID ---FOR
GROUP_TABLE.GID2を変更してもUSER_TABLEに影響がないように。
USER_TABLE.GID2を参照してるPGMは修正が必要ですけど。
0038デフォルトの名無しさん
NGNG0039名無しさんi486
NGNG説得できないのであれば、自分も賛同したということ。ＰＧならＰＧなりに
プライドを持ってがんばれ。設計した奴がえらいとは限らん。
0040デフォルトの名無しさん
NGNG0041１です
NGNG１です。
転職２回目です。
前の会社も今の会社も結構外面はよく
確かな技術力と信頼性で評価されてきた会社です。
名前もみんなが知っています。
でも実際の仕事を見ているとどちらも丁寧ではありませんでした。
店頭なんかで見るソフトなども携わったが設計はひどかった。
簡単にシステムを停止できるようなものまでいろいろと。
0042くどいが
NGNG0044デフォルトの名無しさん
NGNGFKがある（設定する）のはテーブルBですね。参照される側の
テーブルAの方にFKがあるとは言いません。
>二つの外部キーの同期を考えてプログラムを作っています。
同期させるのは、あるFK（外部キー）とあるFKの間ではないですね。
*
テーブル設計としては、USER_TABLEにGID2があるのが冗長という
点を除けば、全くおかしくありません。（計算値であるGID2を
GROUP_TABLEに入れるべきではない、という視点もありますが）
再帰構造の実現は、GROUP_TABLEのようなやり方が普通です。
GID2をUSER_TABLEに入れたのは、アプリケーションのアクセス
状況や、レコード数などを見なければなんとも言えませんね。
ただ、Join無しにGID2を条件として、USER_TABLEを検索できるよう
設計しているのだ、と言えば、誰もそれが誤りであるとは言えないでしょう。
*
では、USER_TABLE.GID2をどうやってGROUP_TABLE.GID2と同期
させればいいのか。
トリガーがあるRDBMSであれば、GROUP_TABLEのトリガーとして、
USER_TABLEを更新するようにします。
# これ試してないので、何かの制限にひっかかるかも
あるいは、USER_TABLEに対するアクセスをストアードプロシージャ
化します(add_user_table()とか）。
どのようなクライアントアプリケーションからのデータ変更に対しても、
データベース全体の整合性が自動的に保たれ状態に出来るという
意味では、トリガーで実装するのが一番キレイだと思います。
0045デフォルトの名無しさん
NGNGを借りれば、以下のようになります（外部キーはFKとしてあります）。
■ GROUP_TABLE
GID ---PK,REF
GNAME
PARENT_GID
■ USER_TABLE
UID ---PK
UNAME
GID ---FK
計算値（導出項目）であるGID2がGROUP_TABLEにあってはなりません。
ただし、データベースへのアクセスを容易にするために、計算値を
テーブルの項目にキャッシュしておくのは非正規化同様良くやる
手法です。
0046デフォルトの名無しさん
NGNGGID2の整合性ととるのもトリガ用意するかストアド経由で
更新するようにすれば手間じゃない気が。
004746
NGNG0048いつでもどこでも名無しさん
NGNGテーブルやフィールドに名前を付けるのを
英語で記述して行こうと思っているのですが
辞書等で調べてもなかなかマッチしません
何か良い書籍やサイトが有れば教えていただけませんか？
0049デフォルトの名無しさん
NGNG0050デフォルトの名無しさん
NGNGという問題はおいときます。
私が良くやる方法は、まず対象カテゴリで頻出の英単語（その
カテゴリ名ズバリが分かればそのほうがなお良い）で、英語圏
のサイトをいくつか検索します。
で、そのカテゴリや概念の説明ページを探し、そのカテゴリに
対する正しい英単語を調べます。
ただし、最初に言ったように、正しい英単語を使ったからと言って、
それを見る人が理解できなければなにもなりません。
カッコ悪いですが、基本英単語であればそれを使い、その他の
難しい英単語や専門分野の単語は、ローマ字で命名するのが
良いと思います。
# ただこの場合も、'si'や'shi'、'cha'や'cya'など人によって違いがある
# ので、「ヘボン式で命名する」などの規約を作っておくのが吉。
0051デフォルトの名無しさん
NGNGgoo( http://www.goo.ne.jp/ )のEXCEEDもある。
でも、個人的には、yield_to_maturityなんてのよりも、manki_rimawari
のほうが好き。
005224
NGNG本気でそう思うんですか？ Aを親とするレコードBが、Cを親にするように変更
されたら、Bの子孫レコードすべてとそのレコードのGID2を参照するすべての
レコードが更新されるんですよ。もし階層構造の変更が頻繁に行われるので
あれば、デッドロックの嵐でしょうね。
個人的にはGID2とやらは、何の役にも立たないだろう、と思います。
0053デフォルトの名無しさん
NGNGプロジェクトでルールを決めてやっています。（当り前だと思うけど）
005446
NGNG>あれば、デッドロックの嵐でしょうね。
本当か？
>個人的にはGID2とやらは、何の役にも立たないだろう、と思います。
使わなければ役に立たない。
使おうと思えば使える。
再帰的に探すよりは多分早い。
0055デフォルトの名無しさん
NGNG>本気でそう思うんですか？ Aを親とするレコードBが、Cを親にするように変更
>されたら、Bの子孫レコードすべてとそのレコードのGID2を参照するすべての
>レコードが更新されるんですよ。もし階層構造の変更が頻繁に行われるので
だから、それはアプリケーションからのアクセス要件によりますって。
頻繁に、「select * from group table wher gid2 like '01%'」みたいな
検索を必要とするなら、レコードに変更があった時に、gid2を再構築
するのはそれほど悪い戦略では無いと思いますよ。
逆にそのような検索がめったに無いのであれば、get_gid2()みたいな
ストアードファンクション（プロシージャ）を用意しておけば良いだけの
話でしょ？
第三正規系として正しいかどうか、というのであれば、件のテーブル
設計は正しくないけれども、だからといって、アプリケーションからの
アクセス要件無しに、その設計が間違っているかどうかは判断出来ない
のでは？
> あれば、デッドロックの嵐でしょうね。
デッドロックにはなりませんよ。
> 個人的にはGID2とやらは、何の役にも立たないだろう、と思います。
GID2無しに( >>22 参照）、「G95088以下に属するUSERの中から
○○という条件に合致するものを検索する」みたいな検索は簡単
には出来ませんよね？
GID2があれば、
select * from user_table where gid2 like '0101%' and more_cond
って書けるでしょ？
005655
NGNG005755
NGNG■ GROUP_TABLE
GID GID2 GNAME PARENT_GID
---------------------------------
G94001 01 A NULL
G95088 0101 A/A G94001
G98001 0102 A/B G94001
G98004 010201 A/B/A G98001
G99022 010202 A/B/B G98001
G94011 0103 A/C G94001
G00023 02 B NULL
G00007 0201 B/A G00023
例えばG98001をG94001(GID2=01)の下からG00023(GID2=02)の下に移動する場合、
GID GID2 GNAME PARENT_GID
---------------------------------
G98001 0102 A/B G94001
G98004 010201 A/B/A G98001
G99022 010202 A/B/B G98001
のGID2の先頭2文字を'02'に変更できればOK。GNAMEはこの際置いとく。
一度のUpdate文で出来るかどうかはわかりませんが。
005824
NGNGそれは認めます。
>デッドロックにはなりませんよ。
そうですか？ 階層構造の変更が行われるときには当然1トランザク
ション内で更新される必要があるから、関連レコードすべてがロック
されますよね？ で、その中の複数レコードを更新する別トランザク
ションがあったらデッドロックになりませんか？
よく考えてみると、GROUPテーブルのつくりはそのまま(もしくは
親子関係を表現するテーブルを別に作る)で、GROUPを参照する
テーブルのほうがGIDのみでアクセスすればすむんじゃないですか?
005946
NGNG>よく考えてみると、GROUPテーブルのつくりはそのまま(もしくは
>親子関係を表現するテーブルを別に作る)で、GROUPを参照する
>テーブルのほうがGIDのみでアクセスすればすむんじゃないですか?
作った人じゃないから知らんけど、joinするよりしない方が速いから
そうしたんじゃないの？
006055
NGNG> 階層構造の変更が行われるときには当然1トランザク
>ション内で更新される必要があるから、関連レコードすべてがロック
>されますよね？
それはそのとおり。
> で、その中の複数レコードを更新する別トランザク
>ションがあったらデッドロックになりませんか？
それは、更新の待ち行列に入るだけで、デッドロックとは言いません。
>よく考えてみると、GROUPテーブルのつくりはそのまま(もしくは
>親子関係を表現するテーブルを別に作る)で、
今回の例の場合は、GROUP_TABLE内においては、親が1レコード
しかないので（親:子=1:n)、複数テーブルに分ける必要は無いと思います。
>GROUPを参照する
>テーブルのほうがGIDのみでアクセスすればすむんじゃないですか?
だーかーらー、パフォーマンスの関係で、ジョイン無しに
USER_TABLEだけからツリーを引っ張り出すことをしたいし、
そのようなことが良くある、みたいな状況だと、
USER_TABLEにGID2を入れる戦略もアリだって。
そーゆーこと無しに、その設計が正しいのかどうかなんて議論は
出来ませんって。
そーゆーこと無しに判断するなら、今回のテーブル設計は、それ
ほど間違いは無い、ってことしか言えないんじゃない？
006155
NGNG「再帰構造を線形構造にする」みたいな考え方は、
RDBにはなじまない、と思っています。
でも、これが無いと、エラク検索が大変になりそう。
006224
NGNGだから「複数レコードを更新する別トランザクション」って書いて
いるでしょう。もちろん必ずおきるわけではありませんが、1回の
トランザクションでロックするレコードの数が増えれば当然デッド
ロックの危険性は高くなりますよね？
>回の例の場合は、GROUP_TABLE内においては、親が1レコード
>かないので（親:子=1:n)、複数テーブルに分ける必要は無いと思います。
まあ確かにそれほど必要ではないですね。ただGROUPテーブルの大きさ
や更新の頻度によっては、更新時のページ分割やレコード転送などが
無視できないかな、と思ったので。
>だーかーらー、パフォーマンスの関係で、ジョイン無しに
>USER_TABLEだけからツリーを引っ張り出すことをしたいし、
>そのようなことが良くある、みたいな状況だと、
>USER_TABLEにGID2を入れる戦略もアリだって。
うーん、まあそれはそのとおりですね。よっぽどその検索のレスポンス
が要求される場合でない限り、そういう設計はしたくないですが(~~;)
0063デフォルトの名無しさん
NGNG> トランザクションでロックするレコードの数が増えれば当然デッド
> ロックの危険性は高くなりますよね？
あ、更新の順序が決まっていなくて、しかも、逐次行ロック（とかいう
言葉は多分無いけど、雰囲気分かりますよね）していく場合ですね。
それは、確かにおっしゃるとおりです。
あまり、そのようなことしないので、気づきませんでした。
# ところで、1さんのRDBMSは何を使ってるんでしょうね？
0064デフォルトの名無しさん
NGNG>うーん、まあそれはそのとおりですね。よっぽどその検索のレスポンス
>が要求される場合でない限り、そういう設計はしたくないですが(~~;)
私もあまりしたくありませんが、例えばディレクトリやファイルのモデル
をデータベース化しようとしたときに、「フルパス」という属性は入れる
と思います。get_fullpath()ってありがちでしょ？
これを、ルートディレクトリまで再帰的にたどっていかなきゃ分からない
としたら、それはそれでツライかも。
006563
NGNGfullpathという属性は入れません。
get_fullpath()というストアードファンクションで実装かな・・・
006648
NGNG>50
>付けた英単語を見て、万人がその内容を想像出来るかどうか、
>という問題はおいときます。
>私が良くやる方法は、まず対象カテゴリで頻出の英単語（その
>カテゴリ名ズバリが分かればそのほうがなお良い）で、英語圏
>のサイトをいくつか検索します。
>で、そのカテゴリや概念の説明ページを探し、そのカテゴリに
>対する正しい英単語を調べます。
なるほど確かにプロジェクト全体が把握できるのが最優先ですね
この方法でしたら多少込み入った用語でも
英単語化できそうですね
どちらにしろ英語はできないと厳しそうですが(^^;
>49,51
まとめて
gooとexciteはしってたのですが
やはり込み入った単語が出てこなかったので
そのときほかの人はどうしてるか気になったもので
他にもこの様なサイトが有ります
http://www.alc.co.jp/
0067デフォルトの名無しさん
NGNGGID2があったって良いけど、それを外部に対するキーにするなという主張だと思うぞ。
GID2の変更をそれを参照している全てのテーブルに反映させるのはなんというか…
つーかGIDとGID2だけを持ったテーブル作れば良いじゃん。
006855
NGNG>GID2の変更をそれを参照している全てのテーブルに反映させるのはなんというか…
まぁ、確かにうざいんだけど、非正規化したことが設計ミスかどうかは、
何をトレードオフにしたかによるので、一概にどうこう言えないと思いますよ。
トリガーが使えれば、同期させるのは自動にできるわけだし。
006924
NGNG>何をトレードオフにしたかによるので、一概にどうこう言えないと思いますよ。
まあ、GID2が夜間バッチで変更されるようなものならそれほど影響は
ないでしょうね。
その辺は1を書いた人に出てきてもらわないとわからんことですが...
>トリガーが使えれば、同期させるのは自動にできるわけだし。
どっちかっていうと更新処理の「手間」よりも、同時に更新される
レコード数が爆発的に多くなる可能性があることが問題なので、これ
はあまり説得力がないと思います。
0070デフォルトの名無しさん
NGNG出てきとくれ
0071デフォルトの名無しさん
NGNGGID2を主キーに使うというのは非正規化じゃないぞ。変更されるものが
なんで主キーなんだ？
#まあ言葉の定義なんぞ人によって違うからそれを非正規化といっても良いけど
この場合の非正規化とはGID2を別テーブルにせず、GIDとGID2が２つとも
(只の)キーとして１つのテーブルに存在することであって、主キーとしてGID2を
選択するのはただの間違い。
0072デフォルトの名無しさん
NGNG使用ルールを徹底してほしいよ。
007355
NGNG>GID2を主キーに使うというのは非正規化じゃないぞ。
ではなくて、GID2をGROUP_TABLEに持つことを非正規化と言っています。
多分、第2正規形に違反（というのか？）していると思います。
また、そのコピーをUSER_TABLEに持つのも、非正規化です。
「主キー」というのは、1さんが主キーというものの意味を誤解している
ために出てきた言葉だと思いますよ。
おそらく、実際のテーブルは、>>37のような構成になっていると思います。
constraint primary key pk_group_table (gid, gid2)
だったら、痛すぎですけど。
0074デフォルトの名無しさん
NGNG>#まあ言葉の定義なんぞ人によって違うからそれを非正規化といっても良いけど
正規化したものを崩すことが「非正規化」と言うのでは？
正規化する前のものを「非正規化」とは言わない。
それは、「正規化していない」と言うのが正しい。
・・・と私は思う。
0075>65
NGNG>get_fullpath()というストアードファンクションで実装かな・・・
DBMSによるけど、複数レコードが返ってくる事を考えるとめんどくさくない？
007675
NGNG多分
select gid1 from group_table where get_fullpath(gid1) like '%01%'
とか使うつもりでget_fullpath(gid1)って使うんだろうけど、
複数レコードが欲しいときが多ければ
get_fullpath('%01%')
みたいな使い方の方が便利そうだけど・・なぁ・・・
って意見
0077デフォルトの名無しさん
NGNG/￣ l | ／￣￣￣￣￣￣￣￣￣￣
■■-っ ＜ んなーこたーない
´∀｀/ ＼＿＿＿＿＿＿＿＿＿＿
＿_／|Ｙ/＼.
Ё|＿_ | / |
| У.. |
0078デフォルトの名無しさん
NGNG最近思うな。
0079デフォルトの名無しさん
NGNG最大1万件って話だったのに、運用してみたら10万件になったり
とか
0080デフォルトの名無しさん
NGNG数百万件くらいから、真剣にテーブルを考えましょう。
■ このスレッドは過去ログ倉庫に格納されています