私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part12
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 : ○
レスフィルター : (試験中)
innoDBにてリレーションを組んだテーブルがあるんですが、
片一方のテーブルのデータを削除すると "foreign key constraint fails"が出ます。
ondelete cascadeをせずに、片一方のテーブルのデータを削除する方法はありますでしょうか。
片一方のテーブルのデータを削除すると "foreign key constraint fails"が出ます。
ondelete cascadeをせずに、片一方のテーブルのデータを削除する方法はありますでしょうか。
夜だからかちょっと混乱してるかもです…
ショッピングカートのデータベースです。
user,shopcartというテーブルがあり、それぞれ
-user
userid int(11)
name varchar(64)
-shopcart
userid int(11)
goodsid int(11)
price int(11)
accounted int(1) #0:未清算,1:清算済み
となっています。(実際はもっと複雑で違った用途ですが…)
このとき、
未清算(accounted=0)で、価格が10,000円以上(price>10000)の商品が
買い物かごに入っているユーザの名前を検索するのは
どういったSQL文を書けばいいのでしょうか。
ショッピングカートのデータベースです。
user,shopcartというテーブルがあり、それぞれ
-user
userid int(11)
name varchar(64)
-shopcart
userid int(11)
goodsid int(11)
price int(11)
accounted int(1) #0:未清算,1:清算済み
となっています。(実際はもっと複雑で違った用途ですが…)
このとき、
未清算(accounted=0)で、価格が10,000円以上(price>10000)の商品が
買い物かごに入っているユーザの名前を検索するのは
どういったSQL文を書けばいいのでしょうか。
違った…これじゃすごい単純だ
SELECT name from INNER JOIN shopcart ON user.userid = shopcart.userid WHERE shopcart.price>10000 & shopcart.accounted = 0
でいけたわ
必要なのは
「未清算(accounted=0)で、価格が10,000円以上(price>10000)の商品が
買い物かごに入っている」
かつ
「清算済み(accounted=1)で、価格が10,000円以上(price>10000)の商品が
買い物かごに入っている」
ユーザの名前を検索するSQL文でした
お騒がせしてます
SELECT name from INNER JOIN shopcart ON user.userid = shopcart.userid WHERE shopcart.price>10000 & shopcart.accounted = 0
でいけたわ
必要なのは
「未清算(accounted=0)で、価格が10,000円以上(price>10000)の商品が
買い物かごに入っている」
かつ
「清算済み(accounted=1)で、価格が10,000円以上(price>10000)の商品が
買い物かごに入っている」
ユーザの名前を検索するSQL文でした
お騒がせしてます
priceは除いても必要な構文は同じなので除外します。
日本語で言うと
「未清算の商品と清算済みの商品がそれぞれ1点以上カートに入っているユーザの名前」となります
つまりまとめてみると
『shopcartに userid=x AND accounted=1 なレコードがあり、かつ
shopcartに userid=x AND accounted=0 なレコードがある』
という条件を満たすuserid=xに対応するnameを求める
ということです。
ん?おかしい?
GROUP BYでもいける気もする
日本語で言うと
「未清算の商品と清算済みの商品がそれぞれ1点以上カートに入っているユーザの名前」となります
つまりまとめてみると
『shopcartに userid=x AND accounted=1 なレコードがあり、かつ
shopcartに userid=x AND accounted=0 なレコードがある』
という条件を満たすuserid=xに対応するnameを求める
ということです。
ん?おかしい?
GROUP BYでもいける気もする
これでどうか
select u.name from
(select distinct userid from shopcart where accounted=0 and price>=10000) a,
(select distinct userid from shopcart where accounted=1 and price>=10000) b,
user u
where a.userid=b.userid
and a.userid=u.userid;
select u.name from
(select distinct userid from shopcart where accounted=0 and price>=10000) a,
(select distinct userid from shopcart where accounted=1 and price>=10000) b,
user u
where a.userid=b.userid
and a.userid=u.userid;
>>562
そのページは phpMyAdmin 2.5.6 向けに書かれているみたいだから
書かれている通りに作業を進めていってもうまくいかないと思うよ。
(認証メソッドもクッキー認証のままだろうし)
面倒くさいかもしれないけど、設定ファイルに書かれている項目を
一つひとつ理解しながら進めるのがいいと思う。
あるいは最新版にも使えそうな別の解説ページを探すとか。
そのページは phpMyAdmin 2.5.6 向けに書かれているみたいだから
書かれている通りに作業を進めていってもうまくいかないと思うよ。
(認証メソッドもクッキー認証のままだろうし)
面倒くさいかもしれないけど、設定ファイルに書かれている項目を
一つひとつ理解しながら進めるのがいいと思う。
あるいは最新版にも使えそうな別の解説ページを探すとか。
>>565
そうみたいですね
2.5.6を落として入れてみたんですが、それも上手くいきませんでした。
実は壊れたマシンの中じゃ動いてたんだけど、こういうのって
上手く動作したらすぐにそのバージョンや手順をメモっておくべきなんでしょうね
失敗したなぁ;; ありがとうございました
そうみたいですね
2.5.6を落として入れてみたんですが、それも上手くいきませんでした。
実は壊れたマシンの中じゃ動いてたんだけど、こういうのって
上手く動作したらすぐにそのバージョンや手順をメモっておくべきなんでしょうね
失敗したなぁ;; ありがとうございました
あとそのときのバージョンのインストールパッケージ一式残しておくこと
いつまでもダウンロードできるとは限らない
いつまでもダウンロードできるとは限らない
CPUの交換を行って、CPUの性能が上がったのに
データアクセスが遅くなりました。
CPUを交換したら、Mysqlの再インストールが必要な場合があるんでしょうか?
データアクセスが遅くなりました。
CPUを交換したら、Mysqlの再インストールが必要な場合があるんでしょうか?
>>569
返答ありがとうございます。
やっぱりMysqlをインストールする時にそのマシンの
構成によって何かしらの変化があるって事なんですね?
再インストールすれば大丈夫でしょうか?
素人ですいません。。。
返答ありがとうございます。
やっぱりMysqlをインストールする時にそのマシンの
構成によって何かしらの変化があるって事なんですね?
再インストールすれば大丈夫でしょうか?
素人ですいません。。。
カーネルにも依存するわな。
今度のFreeBSDはマルチコアに対して期待できるパフォーマンスを発揮するが、
LINUXだと、コアが増えるとパフォーマンスが落ちるみたいな話があるし。
今度のFreeBSDはマルチコアに対して期待できるパフォーマンスを発揮するが、
LINUXだと、コアが増えるとパフォーマンスが落ちるみたいな話があるし。
んで、>>569 の言いたい事は何?
5.0以降なら
select TABLE_NAME
from information_schema.TABLES
where TABLE_SCHEMA = 'db_name'
and TABLE_NAME not like 'dtb%';
select TABLE_NAME
from information_schema.TABLES
where TABLE_SCHEMA = 'db_name'
and TABLE_NAME not like 'dtb%';
…以外のだったのね スマソ
2ちゃんねるって有料なの?
はい。有料です。
2ちゃんねる使用料
■閲覧
1スレッド 25円
■書きこみ
1レス 10
スレ立て 500円(大人の時間、ニュース速報は1000円)
混雑時は立てる事が出来ない場合がありますが、その時は課金されません
■書きこみ放題
・プラチナプラン 4800円 閲覧無料 スレ立て200円、通常3スレ/月、実況5スレ/週の無料サービス
・ゴールドプラン 3500円 閲覧無料 スレ立て半額 HOT!
払わないと、大変なことになるかもしれませんね・・・( ̄ー ̄)ニヤリ
2ちゃんねるは有料だった
ソース
http://www.geocities.jp/guide_2ch/
はい。有料です。
2ちゃんねる使用料
■閲覧
1スレッド 25円
■書きこみ
1レス 10
スレ立て 500円(大人の時間、ニュース速報は1000円)
混雑時は立てる事が出来ない場合がありますが、その時は課金されません
■書きこみ放題
・プラチナプラン 4800円 閲覧無料 スレ立て200円、通常3スレ/月、実況5スレ/週の無料サービス
・ゴールドプラン 3500円 閲覧無料 スレ立て半額 HOT!
払わないと、大変なことになるかもしれませんね・・・( ̄ー ̄)ニヤリ
2ちゃんねるは有料だった
ソース
http://www.geocities.jp/guide_2ch/
select文を打つ前にset charset utf8を投げてみれ。
コマンドプロンプトでsql文を投げてるなら、PHPのmysql_queryでも試してみ。
そのテーブル自体がutf8じゃなかったりすると、ALTER TABLEで文字コードを変換する必要がある。
未確認だけど、たぶんdefault-character-set統一後にTABLEを作成する必要があるかもです。
コマンドプロンプトでsql文を投げてるなら、PHPのmysql_queryでも試してみ。
そのテーブル自体がutf8じゃなかったりすると、ALTER TABLEで文字コードを変換する必要がある。
未確認だけど、たぶんdefault-character-set統一後にTABLEを作成する必要があるかもです。
>>588
そういう押し付けがましいレスは止めろ。
5.0.45って書いているんだから、文字コードの問題じゃないだろ。
ラーメン屋の癖にイタリアン風の盛り付けをして、
フォークとスプーンで食べさせるのと一緒だろ。
分をわきまえろ。
そういう押し付けがましいレスは止めろ。
5.0.45って書いているんだから、文字コードの問題じゃないだろ。
ラーメン屋の癖にイタリアン風の盛り付けをして、
フォークとスプーンで食べさせるのと一緒だろ。
分をわきまえろ。
>>589
そういうイタリア風のレスは止めろ。
そういうイタリア風のレスは止めろ。
set names utf8; も試してみて。
あと関係ありそうなシステム変数を手当たり次第ダンプすれば
解決の糸口になるかも。
show variables like 'character_set%';
show variables like 'collation%';
あと関係ありそうなシステム変数を手当たり次第ダンプすれば
解決の糸口になるかも。
show variables like 'character_set%';
show variables like 'collation%';
チャーハンに付いてくるレンゲでは食べにくい。
普通の金属のスプーンなら食べやすいけど。
PHP使ってる時点でスキル低いから無理でしょ。
SJIS使えるアクセスでも使ったら?
普通の金属のスプーンなら食べやすいけど。
PHP使ってる時点でスキル低いから無理でしょ。
SJIS使えるアクセスでも使ったら?
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / mysql スレッド一覧へ
みんなの評価 : ○類似してるかもしれないスレッド
- MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
- MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
- MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
- MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
- MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
- MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
- MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
- MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について