私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part13
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 : ☆
レスフィルター : (試験中)
ぐぁぁああぁ…replace into って、delete → insert だから、
autoincrement のフィールドの値が変わるじゃねぇか…。
autoincrement のフィールドの値が変わるじゃねぇか…。
mysqlで誰にも知られていない
秘密のコマンドがあると聞いた
そのコマンドとは?
秘密のコマンドがあると聞いた
そのコマンドとは?
とりあえずマニュアル読めば誰にも知られていないわけではないけれど
>>952が知らないコマンドは出てくるんじゃないの?
>>952が知らないコマンドは出てくるんじゃないの?
>>952
またかよ…。 だからSELECTだっつってんだろが
またかよ…。 だからSELECTだっつってんだろが
ここで質問してもいいのかな?
もし、スレ違いだったら誘導してくれると嬉しいです。
服の検索をするためのテーブル設計について行き詰まっています。
同じ服だけど、他種類のサイズがある場合、
どういうテーブル設計にすればいいか考えあぐねています。
現状では、
(1) 服のサイズ以外の基本情報テーブル
(2) 服の型番で、各サイズごとに記載したテーブル
を用意しています。
サイズで検索し、当てはまった商品の基本情報と全サイズ一覧を出す場合、
一度のリクエストで、何度もクエリを送信しなければならず、非効率です。
何とか良い方法はないでしょうか?
あるいは、そういう目的別のテーブル設計事例集などがあればいいのですが、
テーブル設計でAmazon検索しても、なぜか魔法瓶が羅列されてしまって、参考になりませんw
お薦めの本、あるいは、複数サイズの洋服の最適なテーブル設計があれば、
ヒントだけでも頂けませんでしょうか?
もし、スレ違いだったら誘導してくれると嬉しいです。
服の検索をするためのテーブル設計について行き詰まっています。
同じ服だけど、他種類のサイズがある場合、
どういうテーブル設計にすればいいか考えあぐねています。
現状では、
(1) 服のサイズ以外の基本情報テーブル
(2) 服の型番で、各サイズごとに記載したテーブル
を用意しています。
サイズで検索し、当てはまった商品の基本情報と全サイズ一覧を出す場合、
一度のリクエストで、何度もクエリを送信しなければならず、非効率です。
何とか良い方法はないでしょうか?
あるいは、そういう目的別のテーブル設計事例集などがあればいいのですが、
テーブル設計でAmazon検索しても、なぜか魔法瓶が羅列されてしまって、参考になりませんw
お薦めの本、あるいは、複数サイズの洋服の最適なテーブル設計があれば、
ヒントだけでも頂けませんでしょうか?
JOINでもVUEでも一発で出すことはできるんですが、
型番ごとに各サイズを格納するという作業をプログラム側でやってしまうのは、
良い方法なのでしょうか? なんか泥臭い感じがして。
型番ごとに各サイズを格納するという作業をプログラム側でやってしまうのは、
良い方法なのでしょうか? なんか泥臭い感じがして。
>型番ごとに各サイズを格納するという作業をプログラム側でやってしまうのは、
あのね、「服の型番」と「サイズ」がどういう関係にあるか自体、業界外の人間には分からないんだ。
「型番」が決まればサイズが決まるのか、それとも、型番→サイズというハイアラーキーになっているのかとか…。
「型番」=「商品の基本情報」(のプライマリキー)で、「型番」→「サイズ」がハイアラーキーなのなら、
「型番ごとに各サイズを格納するという作業」は単なるJOINだから、プログラム側では何もしなくてよいのでは。
あのね、「服の型番」と「サイズ」がどういう関係にあるか自体、業界外の人間には分からないんだ。
「型番」が決まればサイズが決まるのか、それとも、型番→サイズというハイアラーキーになっているのかとか…。
「型番」=「商品の基本情報」(のプライマリキー)で、「型番」→「サイズ」がハイアラーキーなのなら、
「型番ごとに各サイズを格納するという作業」は単なるJOINだから、プログラム側では何もしなくてよいのでは。
なんだかシステム・エンジニアの要件定義そのもだな。
業界や会社の物事を、いかにコンピューター上で実現するか。
業界や会社の物事を、いかにコンピューター上で実現するか。
>>962
例えば、型番「hoge」の中にS(15)、M(20)、L(25)があるというイメージです。
言われているハイアラーキーな関係になるかと思います。
>>959で言うと、
(1) テーブルに、型番「foo」の基本情報のフィールドがあり、
(2) テーブルに、S、M、L というサイズのフィールドが、
型番「foo」に対してそれぞれあります。
上記前提で、
例えばサイズ検索をして、hogeのMが引っ掛かった場合、
「foo」の全サイズ情報も出力したいので、SとLのフィールドが必要になります。
しかし、型番「bar」のサイズ展開は、L、XL、XXLであるため、
型番を元に、サイズをひとつのフィールドにまとめてしまうと、
検索するのに問題が生じます。
よって、それぞれのサイズのフィールドに、
各型番の基本情報をまとめるようなビューを作成しなければならないのです。
この方式だと、検索結果に一致したサイズの型番で
改めてクエリを投げて、結果をまとめるという処理が必要になります。
未熟なので、もっと効率的な方法はいくらでもあるのでしょうし、
指摘されている方法であっけなく片付けられる手順があるのかも知れませんが、
それを学ぶ手段や書籍を見つけられずに試行錯誤しているのが現状です。
MySQLに関してチューニングや入門書はいくらでも見つけられるのですが、
こういう事例に関しての設計例は、一切見つけられなくて困っています。
何とかお知恵あるいは書籍の情報を頂ければと思うのですが。
例えば、型番「hoge」の中にS(15)、M(20)、L(25)があるというイメージです。
言われているハイアラーキーな関係になるかと思います。
>>959で言うと、
(1) テーブルに、型番「foo」の基本情報のフィールドがあり、
(2) テーブルに、S、M、L というサイズのフィールドが、
型番「foo」に対してそれぞれあります。
上記前提で、
例えばサイズ検索をして、hogeのMが引っ掛かった場合、
「foo」の全サイズ情報も出力したいので、SとLのフィールドが必要になります。
しかし、型番「bar」のサイズ展開は、L、XL、XXLであるため、
型番を元に、サイズをひとつのフィールドにまとめてしまうと、
検索するのに問題が生じます。
よって、それぞれのサイズのフィールドに、
各型番の基本情報をまとめるようなビューを作成しなければならないのです。
この方式だと、検索結果に一致したサイズの型番で
改めてクエリを投げて、結果をまとめるという処理が必要になります。
未熟なので、もっと効率的な方法はいくらでもあるのでしょうし、
指摘されている方法であっけなく片付けられる手順があるのかも知れませんが、
それを学ぶ手段や書籍を見つけられずに試行錯誤しているのが現状です。
MySQLに関してチューニングや入門書はいくらでも見つけられるのですが、
こういう事例に関しての設計例は、一切見つけられなくて困っています。
何とかお知恵あるいは書籍の情報を頂ければと思うのですが。
>それぞれのサイズのフィールドに、各型番の基本情報をまとめる
の意味が分からん。
単純に、これじゃだめなの?
基本情報に「bar」があり、サイズがMかLのものを取得。
create table dress (RID int primary key auto_increment, ID varchar(24), sz varchar(8));
create table info (RID int primary key auto_increment, ID varchar(24), body text);
insert into dress (ID,sz) values ('foo','S'),('foo','M'),('foo','L),('bar','S'),('bar','M'),('bar','L'),('bar','LL'),('bar','LX');
insert into info (ID,body) values('foo','dress type foo'),('bar','dress type bar');
select distinct D.ID,D.sz,I.body from dress as D left join info as I using (ID) where (I.body like '%bar%' and( D.sz = 'M' or D.sz = 'L'));
の意味が分からん。
単純に、これじゃだめなの?
基本情報に「bar」があり、サイズがMかLのものを取得。
create table dress (RID int primary key auto_increment, ID varchar(24), sz varchar(8));
create table info (RID int primary key auto_increment, ID varchar(24), body text);
insert into dress (ID,sz) values ('foo','S'),('foo','M'),('foo','L),('bar','S'),('bar','M'),('bar','L'),('bar','LL'),('bar','LX');
insert into info (ID,body) values('foo','dress type foo'),('bar','dress type bar');
select distinct D.ID,D.sz,I.body from dress as D left join info as I using (ID) where (I.body like '%bar%' and( D.sz = 'M' or D.sz = 'L'));
・サイズ情報テーブル size
n,type,size,length,width
1,'foo','S',15,40
2,'foo','M',20,45
3,'foo','L',25,50
4,'bar','L',24,52
5,'bar','XL',28,58
6,'bar','XXL',32,64
・商品情報テーブル item
n,type,name,info
1,'foo','ふー','フーな感じです。'
2,'bar','ばー','バーな感じです。'
かなりシンプルにしましたが、
テーブルのイメージとしてはこんな感じです。
ここからsize.lengthで検索し、
一致したtypeの商品情報と他のサイズの情報を取り出したいのです。
良い設計あるいは最適な取り出し方について事例を知っていれば
教えて頂けると嬉しいです。
n,type,size,length,width
1,'foo','S',15,40
2,'foo','M',20,45
3,'foo','L',25,50
4,'bar','L',24,52
5,'bar','XL',28,58
6,'bar','XXL',32,64
・商品情報テーブル item
n,type,name,info
1,'foo','ふー','フーな感じです。'
2,'bar','ばー','バーな感じです。'
かなりシンプルにしましたが、
テーブルのイメージとしてはこんな感じです。
ここからsize.lengthで検索し、
一致したtypeの商品情報と他のサイズの情報を取り出したいのです。
良い設計あるいは最適な取り出し方について事例を知っていれば
教えて頂けると嬉しいです。
サブクエリ exists の定番。
試してないけど
select distinct I.type,I.name,S.size,S.length,S.width from item as I left join size as S using(type)
where exists (select X.type from size as X where (X.size = 'M' and X.length= 15 and X.type = I.type);
試してないけど
select distinct I.type,I.name,S.size,S.length,S.width from item as I left join size as S using(type)
where exists (select X.type from size as X where (X.size = 'M' and X.length= 15 and X.type = I.type);
>>968
ありがとうございます。
非常に参考になります。
かなり欲しい結果に近い部分を得られました。
select distinct I.type,I.name,S.size,S.length,S.width from item as I left join size as S using(type)
where exists (select X.type from size as X where (X.length=15 and X.type=I.type));
で、fooのsize「S」が一致し、fooの全ての情報が取り出せました。
これに、X.length=15にあてはまるS.sizeがどれなのかも合わせて欲しいのです。
やはり、その場合は2回クエリを投げる必要がありますか?
実際のテーブルは規模がもっと大きいので、
検索結果が100件あるとすると、
ひとつのリクエストなのに1+100回クエリを投げないといけなくなり、
どうにか上手にまとめられればと思います。
ありがとうございます。
非常に参考になります。
かなり欲しい結果に近い部分を得られました。
select distinct I.type,I.name,S.size,S.length,S.width from item as I left join size as S using(type)
where exists (select X.type from size as X where (X.length=15 and X.type=I.type));
で、fooのsize「S」が一致し、fooの全ての情報が取り出せました。
これに、X.length=15にあてはまるS.sizeがどれなのかも合わせて欲しいのです。
やはり、その場合は2回クエリを投げる必要がありますか?
実際のテーブルは規模がもっと大きいので、
検索結果が100件あるとすると、
ひとつのリクエストなのに1+100回クエリを投げないといけなくなり、
どうにか上手にまとめられればと思います。
>>969
GUI tools
GUI tools
mysql5で最初から作られている
information_schema
っていうデータベースって削除してよい?
本家の解説読んでもイマイチワカランカッタ
information_schema
っていうデータベースって削除してよい?
本家の解説読んでもイマイチワカランカッタ
>>974
おまいは testデータベースも残しておけ
おまいは testデータベースも残しておけ
>>974
information_schemaはRDBMSにとって必須なものだよ。
Windowsのレジストリってよくわからない設定しか書いてないから
消してよい?って言ってるようなもん。
つまり、「それを消すなんてとんでもない。」
information_schemaはRDBMSにとって必須なものだよ。
Windowsのレジストリってよくわからない設定しか書いてないから
消してよい?って言ってるようなもん。
つまり、「それを消すなんてとんでもない。」
CREATE VIEW v AS SELECT * FROM t;
みたいにしてビューを作ると「*」が展開された形で作成されてしまい、
元のテーブルtのカラムが増減したときビューを作り直さなければならない
のですが、「*」を展開しない状態でビューを作ることはできないのでしょうか?
みたいにしてビューを作ると「*」が展開された形で作成されてしまい、
元のテーブルtのカラムが増減したときビューを作り直さなければならない
のですが、「*」を展開しない状態でビューを作ることはできないのでしょうか?
>>980
そうゆうのは、本番環境に投入する前にベンチなりとっとくもんじゃね?
それに、当然CPU,Memにもよるだろうし、ほかのプロセス(httddとかphpとか)状況にもよるし、
なにより、どんなクエリが発行されるかによって、(同一ハード環境でも)はっきり言って100倍違う。
ちなみにウチの環境だと、
cpu Core Duo 2.0Ghz Men 1GB で、
ごく軽いクエリをmysqldが100%cpu使って20000/s以上出るけど、
ちょっと複雑なクエリにすると、途端に1000/s位になるし、
Apache + mod_perl で実環境に近い状態でやると250/s位。
だからウチの場合ではその近辺まではなんも手ぇ打たんでいいかなと判断してる。(現状 20-25/s位で推移してるし)
もちろんこれはウチの環境に限っての話であって、これらの数値は全く意味をなさないけど。
サーバマシンの構成やデータ量、どんなクエリ投げてるかは、君しか知らんから、一概にいくらとは言えないよ。
そうゆうのは、本番環境に投入する前にベンチなりとっとくもんじゃね?
それに、当然CPU,Memにもよるだろうし、ほかのプロセス(httddとかphpとか)状況にもよるし、
なにより、どんなクエリが発行されるかによって、(同一ハード環境でも)はっきり言って100倍違う。
ちなみにウチの環境だと、
cpu Core Duo 2.0Ghz Men 1GB で、
ごく軽いクエリをmysqldが100%cpu使って20000/s以上出るけど、
ちょっと複雑なクエリにすると、途端に1000/s位になるし、
Apache + mod_perl で実環境に近い状態でやると250/s位。
だからウチの場合ではその近辺まではなんも手ぇ打たんでいいかなと判断してる。(現状 20-25/s位で推移してるし)
もちろんこれはウチの環境に限っての話であって、これらの数値は全く意味をなさないけど。
サーバマシンの構成やデータ量、どんなクエリ投げてるかは、君しか知らんから、一概にいくらとは言えないよ。
linuxにてシェルスクリプトでデータベースやテーブルの雛形構成を
作りたいと思っているのですが、手動なら>mysql 起動後に
SQLを打ち込んでいますが、スクリプトからの場合はどのような
方法が良いでしょうか?
作りたいと思っているのですが、手動なら>mysql 起動後に
SQLを打ち込んでいますが、スクリプトからの場合はどのような
方法が良いでしょうか?
すみません、自己解決しました。
テキストファイルにコマンド列記し、
mysql -u root < hoge.txt でいけました。失礼しました。
テキストファイルにコマンド列記し、
mysql -u root < hoge.txt でいけました。失礼しました。
mysqldumpで 指定したフォルダに保存したい場合は
どうすればいいんでしょうか?
教えて下さい。
どうすればいいんでしょうか?
教えて下さい。
自己解決致しました。
申し訳ありませんでした。
申し訳ありませんでした。
ひょっとして、この現象に見舞われてるのは俺だけなのか?
windowsのコマンドプロンプトで
> mysql
と
> mysqladmin
はどう違うんでしょうか?
> mysql
と
> mysqladmin
はどう違うんでしょうか?
http://dev.mysql.com/doc/
PHP の Windows Help に続き、↑の Japanese v5.1 の CHM の Windows HTML Help ファイルでも、
キーワード部分が文字化けしてたので、修正した。ヘルププロジェクトファイルとコンテンツファイルをちょびっと弄った。
欲しい人はどうぞ
http://toku.xdisc.net/Sn2/up3/www/re2467.zip.html
PHP の Windows Help に続き、↑の Japanese v5.1 の CHM の Windows HTML Help ファイルでも、
キーワード部分が文字化けしてたので、修正した。ヘルププロジェクトファイルとコンテンツファイルをちょびっと弄った。
欲しい人はどうぞ
http://toku.xdisc.net/Sn2/up3/www/re2467.zip.html
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / mysql スレッド一覧へ
みんなの評価 : ☆類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- 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 総合 Part19 (982) - [94%] - 2011/6/9 2:33
- MySQL 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
- MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
- MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
- MySQL 総合 Part22 (1001) - [89%] - 2012/7/10 16:45
- MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について