回答編集履歴

8 修正

sazi

sazi score 13629

2017/09/08 01:33  投稿

テーブル設計の際には、横(列)方向に拡張しなくて良いようにして下さい。
例えば、費目が増えたら列追加しないと駄目なテーブルは設計しないように。
でも、「費目を列にした方が見易いじゃないか」というのは当然あります。
そういった場合は、そのように整形して表示するなりした方が、保守は断然楽になります。
年月なんかも列方向に展開するような持ち方はすべきではありませんが、年と1月~12月の列というのは固定なので少しはありだと思います。
※とは言え、集計などがあるようだとそれも面倒なので、お薦めはしませんが。
また、期毎や年毎に同じ構造のテーブルを名称を変えて持つのも後々面倒なので止めておくこと。
そういったものは、列として定義して識別できるようにする。
追記
---
テーブル設計の際は、そのデータに対して行う処理も合わせて考えてみて下さい。
画面や帳票での登録や表示を、最低でもSQLで行った時に処理しやすいか?というのを考えながら、
行うとそんなに外れた設計にはならないと思います。
それから、テーブルをどのような単位で作成するかについては、「何々をする」という**動詞(形容詞や名詞ではなく)**で括れる単位にすると良いですよ。
追記2
---
大福帳型をベースにするのが一番拡張性があります。
・家計簿(日付,ユーザー,費目,入金,出金,適用
・家計簿(日付,ユーザー,費目,入金,出金,摘要
上記に関連する必要なマスタ
・費目(ID,名称)
・ユーザー(ID,名称)
あれば便利
適用マスタ(テキスト)
摘要マスタ(テキスト)
※用途として、入力画面から簡易にボタンでテキストを登録し、利用する場合には単にリストを選択するみたいな。
ざっくりとはこんな感じでしょうか。
7 追記

sazi

sazi score 13629

2017/09/07 10:42  投稿

テーブル設計の際には、横(列)方向に拡張しなくて良いようにして下さい。
例えば、費目が増えたら列追加しないと駄目なテーブルは設計しないように。
でも、「費目を列にした方が見易いじゃないか」というのは当然あります。
そういった場合は、そのように整形して表示するなりした方が、保守は断然楽になります。
年月なんかも列方向に展開するような持ち方はすべきではありませんが、年と1月~12月の列というのは固定なので少しはありだと思います。
※とは言え、集計などがあるようだとそれも面倒なので、お薦めはしませんが。
また、期毎や年毎に同じ構造のテーブルを名称を変えて持つのも後々面倒なので止めておくこと。
そういったものは、列として定義して識別できるようにする。
追記
---
テーブル設計の際は、そのデータに対して行う処理も合わせて考えてみて下さい。
画面や帳票での登録や表示を、最低でもSQLで行った時に処理しやすいか?というのを考えながら、
行うとそんなに外れた設計にはならないと思います。
それから、テーブルをどのような単位で作成するかについては、「何々をする」という**動詞(形容詞や名詞ではなく)**で括れる単位にすると良いですよ。
追記2
---
大福帳型をベースにするのが一番拡張性があります。
・家計簿(日付,ユーザー,費目,入金,出金,適用)
上記に関連する必要なマスタ
・費目(ID,名称)
・ユーザー(ID,名称)
あれば便利  
・適用マスタ(テキスト)  
※用途として、入力画面から簡易にボタンでテキストを登録し、利用する場合には単にリストを選択するみたいな。  
ざっくりとはこんな感じでしょうか。
6 追記

sazi

sazi score 13629

2017/09/07 10:38  投稿

テーブル設計の際には、横(列)方向に拡張しなくて良いようにして下さい。
例えば、費目が増えたら列追加しないと駄目なテーブルは設計しないように。
でも、「費目を列にした方が見易いじゃないか」というのは当然あります。
そういった場合は、そのように整形して表示するなりした方が、保守は断然楽になります。
年月なんかも列方向に展開するような持ち方はすべきではありませんが、年と1月~12月の列というのは固定なので少しはありだと思います。
※とは言え、集計などがあるようだとそれも面倒なので、お薦めはしませんが。
また、期毎や年毎に同じ構造のテーブルを名称を変えて持つのも後々面倒なので止めておくこと。
そういったものは、列として定義して識別できるようにする。
追記
---
テーブル設計の際は、そのデータに対して行う処理も合わせて考えてみて下さい。
画面や帳票での登録や表示を、最低でもSQLで行った時に処理しやすいか?というのを考えながら、
行うとそんなに外れた設計にはならないと思います。
それから、テーブルをどのような単位で作成するかについては、「何々をする」という**動詞(形容詞や名詞ではなく)**で括れる単位にすると良いですよ。
追記2
---
大福帳型をベースにするのが一番拡張性があります。
・家計簿(日付,ユーザー,費目,入金,出金,適用)
上記に関連する必要なマスタ
・費目(ID,名称)
・ユーザー(ID,名称)
ざっくりとはこんな感じでしょうか。
5 追記

sazi

sazi score 13629

2017/09/07 09:20  投稿

テーブル設計の際には、横(列)方向に拡張しなくて良いようにして下さい。
例えば、費目が増えたら列追加しないと駄目なテーブルは設計しないように。
でも、「費目を列にした方が見易いじゃないか」というのは当然あります。
そういった場合は、そのように整形して表示するなりした方が、保守は断然楽になります。
年月なんかも列方向に展開するような持ち方はすべきではありませんが、年と1月~12月の列というのは固定なので少しはありだと思います。
※とは言え、集計などがあるようだとそれも面倒なので、お薦めはしませんが。
また、期毎や年毎に同じ構造のテーブルを名称を変えて持つのも後々面倒なので止めておくこと。
そういったものは、列として定義して識別できるようにする。
 
追記  
---  
テーブル設計の際は、そのデータに対して行う処理も合わせて考えてみて下さい。  
画面や帳票での登録や表示を、最低でもSQLで行った時に処理しやすいか?というのを考えながら、  
行うとそんなに外れた設計にはならないと思います。  
 
それから、テーブルをどのような単位で作成するかについては、「何々をする」という**動詞(形容詞や名詞ではなく)**で括れる単位にすると良いですよ。  
4 修正

sazi

sazi score 13629

2017/09/07 02:56  投稿

テーブル設計の際には、横(列)方向に拡張しなくて良いようにして下さい。
例えば、費目が増えたら列追加しないと駄目なテーブルは設計しないように。
でも、「費目を列にした方が見易いじゃないか」というのは当然あります。
そういった場合は、そのように整形して表示するなりした方が、保守は断然楽になります。
年月なんかも列方向に展開するような持ち方はすべきではありませんが、年と1月~12月の列というのは固定なので少しはありだと思います。
※とは言え、集計などがあるようだとそれも面倒なので、お薦めはしませんが。
 
また、期毎や年毎に同じ構造のテーブルを名称を変えて持つのも後々面倒なので止めておくこと。  
そういったものは、列として定義して識別できるようにする。  
3 修正

sazi

sazi score 13629

2017/09/07 02:51  投稿

テーブル設計の際には、横(列)方向に拡張しなくて良いようにして下さい。
例えば、費目が増えたら列追加しないと駄目なテーブルは設計しないように。
でも、「費目を列にした方が見易いじゃないか」というのは当然あります。
そういった場合は、そのように整形して表示するなりした方が、保守は断然楽になります。
年月なんかも列に持つべきではありませんが、年と1月~12月の列というのは固定なので少しはありだと思います。
年月なんかも列方向に展開するような持ち方はすべきではありませんが、年と1月~12月の列というのは固定なので少しはありだと思います。
※とは言え、集計などがあるようだとそれも面倒なので、お薦めはしませんが。
2 追記

sazi

sazi score 13629

2017/09/06 22:27  投稿

テーブル設計の際には、横(列)方向に拡張しなくて良いようにして下さい。
例えば、費目が増えたら列追加しないと駄目なテーブルは設計しないように。
でも、「費目を列にした方が見易いじゃないか」というのは当然あります。
そういった場合は、そのように整形して表示するなりした方が、保守は断然楽になります。
年月なんかも列に持つべきではありませんが、年と1月~12月の列というのは固定なのでありだと思います。
年月なんかも列に持つべきではありませんが、年と1月~12月の列というのは固定なので少しはありだと思います。
※とは言え、集計などがあるようだとそれも面倒なので、お薦めはしませんが。
1 修正

sazi

sazi score 13629

2017/09/06 22:25  投稿

テーブル設計の際には、横(列)方向に拡張しなくて良いようにして下さい。
例えば、費目が増えたら列追加しない駄目なテーブルは設計しないように。
例えば、費目が増えたら列追加しない駄目なテーブルは設計しないように。
でも、「費目を列にした方が見易いじゃないか」というのは当然あります。
そういった場合は、そのように整形して表示するなりした方が、保守は断然楽になります。
年月なんかも列に持つべきではありませんが、年と1月~12月の列というのは固定なのでありだと思います。

思考するエンジニアのためのQ&Aサイト「teratail」について詳しく知る