前提・実現したいこと
テーブルを分割するべきか否かについて
発生している問題・エラーメッセージ
現在のテーブル構造はこうで、カラム数は140程度で、現在はレコード件数は87万件ほどです。
---------------------------------------------- |メインID | サブID | その他の情報カラム達・・・・ ---------------------------------------------- ※サブIDは、メインIDごとに1から始まる連番(自動採番)です。
悩んでいる点は以下の2点です。
①そもそも、全メインIDのうち、半数以上はサブIDは1しか持っていない。
②多いもので20以上のサブIDを持つものもあり、時間を空けて追加されていくため、飛び飛びになっている。
例 ----------------------------------------------- | 10000 | 1 | | 10001 | 1 | | 10002 | 1 | ・・・・・ | 92192 | 2 | | 10000 | 2 | ←ここで追加された為、10000-1とかなり離れて10000-2が出来ている。 -----------------------------------------------
考えていること
サブIDが1のレコードのみのテーブルと、サブIDが2以上のレコードのみのテーブルを個別に作ろうと考えています。
こうして、メインテーブルの3カラム目を見て、1でなければサブテーブルを見に行く感じです。
例:メインテーブル ----------------------------------------------- | 10000 | 1 | 2 | ← 3カラム目が、メインID.10000が持っているトータルサブID数。 | 10001 | 1 | 3 | | 10002 | 1 | 11 | ・・・・・ | 92192 | 1 | 5 | ----------------------------------------------- 例:サブテーブル ----------------------------------------------- | 10000 | 2 | その他の情報カラム達・・・・ | 10001 | 2 | その他の情報カラム達・・・・ | 10001 | 3 | その他の情報カラム達・・・・ | 10002 | 2 | ・・・・・ | 10002 | 11 | -----------------------------------------------
この設計は、経験者の方から見て実用に耐えますでしょうか?
また、もっとよい方法があればご教示ください。
タグとしてはPostgreSQLだけに絞るより「データベース設計」のようなタグをつけたほうがより適当かと思います。