回答編集履歴
6
推敲
answer
CHANGED
|
@@ -15,6 +15,6 @@
|
|
|
15
15
|
--
|
|
16
16
|
気付いた点について一つ。
|
|
17
17
|
`t_account`の方に**FK**として`detailid`がありますが、この関係だと`t_detail`の方が先に作成されていないとおかしいことになり、`t_detail`は身長と体重の組み合わせのパターンテーブルとして既に存在しているという事になります。
|
|
18
|
-
なのでその場合の関係は、`t_detail`⇒`t_account`として1:多ですね。
|
|
18
|
+
なのでその場合の関係は、`t_detail`⇒`t_account`として**1:多**ですね。
|
|
19
19
|
|
|
20
20
|
身長と体重として入力するような場合には、`t_detail`に**FK**として`accountid`があるのが正しい設計だと思います。
|
5
追記
answer
CHANGED
|
@@ -15,4 +15,6 @@
|
|
|
15
15
|
--
|
|
16
16
|
気付いた点について一つ。
|
|
17
17
|
`t_account`の方に**FK**として`detailid`がありますが、この関係だと`t_detail`の方が先に作成されていないとおかしいことになり、`t_detail`は身長と体重の組み合わせのパターンテーブルとして既に存在しているという事になります。
|
|
18
|
+
なのでその場合の関係は、`t_detail`⇒`t_account`として1:多ですね。
|
|
19
|
+
|
|
18
20
|
身長と体重として入力するような場合には、`t_detail`に**FK**として`accountid`があるのが正しい設計だと思います。
|
4
推敲
answer
CHANGED
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
和訳しても勘定など計算に関するものが殆どで個人と結びつくようなものではありません。
|
|
4
4
|
元々キーを管理するような意味合いです。
|
|
5
5
|
|
|
6
|
-
`detail`はそれに対する付加
|
|
6
|
+
`detail`はそれに対する付加情報で、たまたま体重や身長ということだけだと思います。
|
|
7
7
|
|
|
8
8
|
身長や体重のように1:1になるものもあれば、1:多になるものもあります。
|
|
9
9
|
これらを拡張していくとすれば、軸となるものが必要でそれが`account`ということになります。
|
3
推敲
answer
CHANGED
|
@@ -14,5 +14,5 @@
|
|
|
14
14
|
追記
|
|
15
15
|
--
|
|
16
16
|
気付いた点について一つ。
|
|
17
|
-
`t_account`の方に**FK**として`detailid`がありますが、この関係だと`t_detail`の方が先に作成されていないとおかしいことになり、`t_detail`は身長と体重の組み合わせのテーブルとして既に存在しているという事になります。
|
|
17
|
+
`t_account`の方に**FK**として`detailid`がありますが、この関係だと`t_detail`の方が先に作成されていないとおかしいことになり、`t_detail`は身長と体重の組み合わせのパターンテーブルとして既に存在しているという事になります。
|
|
18
|
-
|
|
18
|
+
身長と体重として入力するような場合には、`t_detail`に**FK**として`accountid`があるのが正しい設計だと思います。
|
2
推敲
answer
CHANGED
|
@@ -1,12 +1,12 @@
|
|
|
1
|
-
テーブルの名称であるaccountとdetailについて考えてみましょう。
|
|
1
|
+
テーブルの名称である`account`と`detail`について考えてみましょう。
|
|
2
|
-
account自体は個人が主体ではありません。
|
|
2
|
+
`account`自体は個人が主体ではありません。
|
|
3
3
|
和訳しても勘定など計算に関するものが殆どで個人と結びつくようなものではありません。
|
|
4
4
|
元々キーを管理するような意味合いです。
|
|
5
5
|
|
|
6
|
-
detailはそれに対する付加詳細で、たまたま体重や身長ということだけだと思います。
|
|
6
|
+
`detail`はそれに対する付加詳細で、たまたま体重や身長ということだけだと思います。
|
|
7
7
|
|
|
8
8
|
身長や体重のように1:1になるものもあれば、1:多になるものもあります。
|
|
9
|
-
これらを拡張していくとすれば、軸となるものが必要でそれがaccountということになります。
|
|
9
|
+
これらを拡張していくとすれば、軸となるものが必要でそれが`account`ということになります。
|
|
10
10
|
|
|
11
11
|
また、キー同士の関係で1:1になるものでも、利用する機能に合わせて分割する場合もあります。
|
|
12
12
|
例えば、個人の様々な情報を入力する複数の画面を考えた時、一つのテーブルとするより画面ごとのテーブルに分割する方が、処理も楽ですしね。
|
|
@@ -14,5 +14,5 @@
|
|
|
14
14
|
追記
|
|
15
15
|
--
|
|
16
16
|
気付いた点について一つ。
|
|
17
|
-
t_accountの方にFKとしてdetailidがありますが、この関係だとt_detailの方が先に作成されていないとおかしいことになり、t_detailは身長と体重の組み合わせのテーブルとして既に存在しているという事になります。
|
|
17
|
+
`t_account`の方に**FK**として`detailid`がありますが、この関係だと`t_detail`の方が先に作成されていないとおかしいことになり、`t_detail`は身長と体重の組み合わせのテーブルとして既に存在しているという事になります。
|
|
18
|
-
項目の内容からしてみるとあり得ないので、t_detailにFKとしてaccountidがあるのが正しい設計だと思います。
|
|
18
|
+
項目の内容からしてみるとあり得ないので、`t_detail`に**FK**として`accountid`があるのが正しい設計だと思います。
|
1
追記
answer
CHANGED
|
@@ -9,4 +9,10 @@
|
|
|
9
9
|
これらを拡張していくとすれば、軸となるものが必要でそれがaccountということになります。
|
|
10
10
|
|
|
11
11
|
また、キー同士の関係で1:1になるものでも、利用する機能に合わせて分割する場合もあります。
|
|
12
|
-
例えば、個人の様々な情報を入力する複数の画面を考えた時、一つのテーブルとするより画面ごとのテーブルに分割する方が、処理も楽ですしね。
|
|
12
|
+
例えば、個人の様々な情報を入力する複数の画面を考えた時、一つのテーブルとするより画面ごとのテーブルに分割する方が、処理も楽ですしね。
|
|
13
|
+
|
|
14
|
+
追記
|
|
15
|
+
--
|
|
16
|
+
気付いた点について一つ。
|
|
17
|
+
t_accountの方にFKとしてdetailidがありますが、この関係だとt_detailの方が先に作成されていないとおかしいことになり、t_detailは身長と体重の組み合わせのテーブルとして既に存在しているという事になります。
|
|
18
|
+
項目の内容からしてみるとあり得ないので、t_detailにFKとしてaccountidがあるのが正しい設計だと思います。
|