質問: ### 前提・実現したいこと テーブルを分割するべきか否かについて ### 発生している問題・エラーメッセージ 現在のテーブル構造はこうで、カラム数は140程度で、現在はレコード件数は87万件ほどです。 ``` ---------------------------------------------- |メインID | サブID | その他の情報カラム達・・・・ ---------------------------------------------- ※サブIDは、メインIDごとに1から始まる連番(自動採番)です。 ``` 悩んでいる点は以下の2点です。 1そもそも、全メインIDのうち、半数以上はサブIDは1しか持っていない。 2多いもので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 | ----------------------------------------------- ``` この設計は、経験者の方から見て実用に耐えますでしょうか? また、もっとよい方法があればご教示ください。
回答: ER図に起こして、 データ構造の正規化を検討すると良いです。 ER図 リレーションシップを正しく使い分けよう WindowsだとA5:SQL mk-IIでER図を描けますし、 そのままテーブルの定義(CREATE TABLE文)を起こせたりします。 一つのテーブルでいくつもの意味を持たせて自己参照するような印象を受けましたが、 データの入れ物としてのマスターテーブルと、 親子関係を示すリレーションテーブルとに目的を分けたほうが、 きれいな設計になりそうな気がします。 質問者さんが言うところの > > サブIDが1のレコードのみのテーブルと、サブIDが2以上のレコードのみのテーブルを個別に作ろうと考えています。 > > > っていう分け方をしてしまうと、 そのサブIDによって参照するテーブルそのものが異なるのは悪手です。 参照するテーブルを切り替えるのが面倒になって すぐにビューを組むことになるんじゃないかと思います。 サブIDのナンバリングが、 メインID由来で1から始まる、っていうのは人に見せるためのものにしてしまって、 テーブルの中でのユニークキーを別途設けたほうが良いでしょう。 それを、別のメインIDとのリレーションのテーブルを設けて グルーピングの助けにするのが良いかと。 !イメージ説明 また、 RDBMSの都合上、格納した順番通り順序が保持されて記録されるわけではなく、 ルールを与えない限りランダムな順序で出てくる可能性もあります。 ORDER BY句できれいに並べ直した状態で抽出するから格納状態の順序は気にしないものです。 (具体例に乏しく、質問文中の説明がアタマに全然入ってこなかったもので、ぬるい回答ですみません。)