利用規約の変更について

SELECT * FROM table1,table2 WHERE table1.id=table2.data_id;

phpmyadminにて、上記のようなSQL文を実行してtable1とtable2のデータを
リレーションにより表示します。
この時に表示した内容のテーブルを新規作成するにはどうすれば良いでしょうか?

A 回答 (1件)

SELECT *



しているのでフィールド名が競合する可能性が否定できません。

それが回避できるなら
CREATE TABLE hoge SELECT * ・・・
で作ることができます。

ただしデータの流し込みによってつくるテーブルなので
フィールの型が想定したものとちがう可能性があります。
すなおに任意にCREATE TABLE で設定してから
流し込みをすることお勧めします
    • good
    • 0
この回答へのお礼

うまくいきました。
ありがとうございます!

お礼日時:2012/05/01 14:53

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

関連するカテゴリからQ&Aを探す

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Qリレーションシップと外部キー制約について

■最終的にやりたいこと
・なるべくコード(SELECT文など)を見ずに、「DB」「テーブル定義者」「ER図」等からテーブル間の関係性を把握したい


■具体例
・投稿一覧。「userテーブル」「postテーブル」
・「postテーブル」の「user_id」カラムは、「userテーブル」の「id」カラムに対応
※簡易な場合はある程度想像は付くのですが、ちょっと複雑な構成になると途端に苦労するので、何か良い方法はないかと思い、質問しました


■質問
◆「リレーションシップを組む」際、「外部キー制約」はかけるのでしょうか?
例えば、上記「投稿一覧」DBを構築する際では、どうするのでしょうか?
1.普通、「外部キー制約」をかける
2.普通、「外部キー制約」をかけない
3.どちらでも良い

◆「外部キー制約」は何の為にかけるのでしょうか?
・「SELECT&JOIN」でデータ取得出来るのであれば、「外部キー制約」と「リレーションシップ構築」に関係性はないと思うのですが、そういう認識で合っているでしょうか?
・参照先データが削除されたら整合性がとれなくなる場合のみかけるものでしょうか?

◆「リレーションシップを確認」する目的で、「外部キー制約」をかけても良いのでしょうか?
・「データ削除の整合性」ではなく、「リレーションシップを確認」する目的で外部キー制約」をかけても良いのでしょうか?

◆「外部キー制約」以外に、「リレーションシップを確認」する方法はあるのでしょうか?
・コード(SELECT文など)を見ずに、テーブル間の「リレーションシップを確認」する方法としては、「外部キー制約」以外に何かあるのでしょうか?
・そもそも、「外部キー制約確認」=「リレーションシップ確認」という考えは正しいのでしょうか?

■最終的にやりたいこと
・なるべくコード(SELECT文など)を見ずに、「DB」「テーブル定義者」「ER図」等からテーブル間の関係性を把握したい


■具体例
・投稿一覧。「userテーブル」「postテーブル」
・「postテーブル」の「user_id」カラムは、「userテーブル」の「id」カラムに対応
※簡易な場合はある程度想像は付くのですが、ちょっと複雑な構成になると途端に苦労するので、何か良い方法はないかと思い、質問しました


■質問
◆「リレーションシップを組む」際、「外部キー制約」はかけるのでしょうか?
例え...続きを読む

Aベストアンサー

 えらく、外部キー制約に拘っているように見えますが、外部キー制約は、テーブル間の関係の一例でしかありません。

 「最終的にやりたいこと」の文章がすごく象徴的です。
 というのは、完成したER図というのは、実体に対して、これをデータベースでどのように表現したかを全て記した図です。 この図には、全てのテーブル・その属性・そしてテーブル間の関係が全部表現されています。(ていうか、全部表現されていなければ、そのER図は未完成です。)
 省略せずに全てが書かれたER図を見れば、テーブル定義書は機械的に完成しますし、DBの実体もやはり機械的に完成します。

 テーブル間の関係が少し複雑になってくると、関係が見えなくなる。理解できなくなるのは誰でも同じです。これをわかりやすく整理して、誰にでも(設計している途中の自分にも)紛れなく解るようにするためにER図を書く。
 これがER図の目的です。
 (間違っても、クライアントの要求に応じて、仕方なく、システムが全部完成した後で、完成図書を作成する事務作業の一部として作成する物では断じてありません。)
 
 さて、こうして書かれたER図があるのに・・・「「ER図」等からテーブル間の関係性を把握したい」とはどういうことか?
 少なくとも、設計作業の一部としてちゃんと作成したER図があれば、これを見てテーブル間の関係が解らないなんてあり得ません。(本当に解らなければ、それはER図が間違っています。)
 複雑すぎて、ER図が理解できないというのなら解ります。その場合は、きっと、何を見ても理解できないでしょう。もはや解っている人に、実体の説明からレクチャーしてもらうしかありません。

 さて、外部キー制約とは、外部キーの要件を満たす様にデータが入力されることを、システムとして強制するために作成します。(NULLが絶対に入っていないことをシステムとして強制するためにNOT NULL制約をつけるのと全く同じです。)
 したがって、外部キーで無いものに外部キー制約をかけてはいけません。
 また、外部キー制約はデータ削除の整合性を取るためにつけるものでもありません。外部キー制約をつけたテーブルで、データが削除された時に外部キーの要件を満たさなくなるデータを自動的に連鎖削除するオプション機能はありますが、これは単なる便利機能です。
 本来の機能は、NOT NULL制約の付いた要素をNULLにしようとすると、エラーではじかれるのと同じで、外部キー制約を満たさなくなる追加・更新・削除の操作をしようとするとエラーではじかれることになります。

>・コード(SELECT文など)を見ずに、テーブル間の「リレーションシップを確認」する方法としては、「外部キー制約」以外に何かあるのでしょうか?
 
 このコードを書く時に、テーブル間の関係を理解するために、ER図を書いておくんです。ER図がなかったら、そもそも、このコードが書けません。(まぁ、世の中には、ER図は制作者の頭の中だけに存在するという事例は山とありますけどね(苦笑))
 最終目的に対して、質問が本末転倒になっているのがわかりますか?

 

 えらく、外部キー制約に拘っているように見えますが、外部キー制約は、テーブル間の関係の一例でしかありません。

 「最終的にやりたいこと」の文章がすごく象徴的です。
 というのは、完成したER図というのは、実体に対して、これをデータベースでどのように表現したかを全て記した図です。 この図には、全てのテーブル・その属性・そしてテーブル間の関係が全部表現されています。(ていうか、全部表現されていなければ、そのER図は未完成です。)
 省略せずに全てが書かれたER図を見れば、テーブ...続きを読む


人気Q&Aランキング

おすすめ情報