回答編集履歴
3
表現を追加。
answer
CHANGED
|
@@ -10,7 +10,7 @@
|
|
|
10
10
|
|
|
11
11
|
テーブル設計として良否を決定するものは"性能"です。テーブル設計としてカラム数が設計の良否を決定づけるものではありません。システムの利用者にとって性能は絶対的評価基準で、処理が遅いシステムはそれだけで悪とみなされます。データベースはシステムの性能の核になります。テーブル設計は最も性能が出るよう努力されたものであることが求められます。
|
|
12
12
|
|
|
13
|
-
yamashoさんも「SQL実行１回のコストが高くなる」と性能に悪影響があることは想定されています。これは正しいです。「今後の保守・開発がスムーズに進む」この気持ちすごくわかります。ですが、メリットに書かれた内容に利用者にとってのメリットはあるでしょうか。私には我々開発者がよくやる開発側の論理にに見えました。
|
|
13
|
+
yamashoさんも「SQL実行１回のコストが高くなる」と性能に悪影響があることは想定されています。これは正しいです。「今後の保守・開発がスムーズに進む」この気持ちすごくわかります。ですが、メリットに書かれた内容に利用者にとってのメリットはあるでしょうか。私には我々開発者がよくやる開発側の論理にに見えました。やってしまった結果性能が落ちトータルで悪い結果につながるオチがつくパターンです。
|
|
14
14
|
|
|
15
15
|
正規化に取り組んでみてください。もしかしたら結果として200カラムを超えるテーブルが出来上がるかもしれません。もしそうなったら、200カラムを超えるテーブルは正しいテーブル設計であったと言えます。
|
|
16
16
|
|
2
表現を変更。
answer
CHANGED
|
@@ -5,7 +5,7 @@
|
|
|
5
5
|
この時、求められる処理と正規化のレベルに注意してください。それが正しい設計につながります。
|
|
6
6
|
|
|
7
7
|
良い設計ではないとした理由は、保守・開発がスムーズに進むことを目的としているからです。
|
|
8
|
-
yamashoさんにとっては求めている回答と少しずれた
|
|
8
|
+
yamashoさんにとっては求めている回答と少しずれた回答かもしれませんね。
|
|
9
9
|
説明します。
|
|
10
10
|
|
|
11
11
|
テーブル設計として良否を決定するものは"性能"です。テーブル設計としてカラム数が設計の良否を決定づけるものではありません。システムの利用者にとって性能は絶対的評価基準で、処理が遅いシステムはそれだけで悪とみなされます。データベースはシステムの性能の核になります。テーブル設計は最も性能が出るよう努力されたものであることが求められます。
|
1
表現を変更。
answer
CHANGED
|
@@ -10,7 +10,7 @@
|
|
|
10
10
|
|
|
11
11
|
テーブル設計として良否を決定するものは"性能"です。テーブル設計としてカラム数が設計の良否を決定づけるものではありません。システムの利用者にとって性能は絶対的評価基準で、処理が遅いシステムはそれだけで悪とみなされます。データベースはシステムの性能の核になります。テーブル設計は最も性能が出るよう努力されたものであることが求められます。
|
|
12
12
|
|
|
13
|
-
yamashoさんも「SQL実行１回のコストが高くなる」と性能に悪影響があることは想定されています。これは正しいです。「今後の保守・開発がスムーズに進む」この気持ちすごくわかります。ですが、メリットに書かれた内容に利用者にとってのメリットはあるでしょうか。私には我々開発者がよくやる開発側の論理に
|
|
13
|
+
yamashoさんも「SQL実行１回のコストが高くなる」と性能に悪影響があることは想定されています。これは正しいです。「今後の保守・開発がスムーズに進む」この気持ちすごくわかります。ですが、メリットに書かれた内容に利用者にとってのメリットはあるでしょうか。私には我々開発者がよくやる開発側の論理にに見えました。
|
|
14
14
|
|
|
15
15
|
正規化に取り組んでみてください。もしかしたら結果として200カラムを超えるテーブルが出来上がるかもしれません。もしそうなったら、200カラムを超えるテーブルは正しいテーブル設計であったと言えます。
|
|
16
16
|
|