ポイントテーブルのPoint.createdをGroupByして
日付毎のPoint.user_idをcountして出しました。

しかし、集計の期間内で重複しないPoint.user_idを
countしなければいけなくなったのですが
日付でGroupByした結果から期間内の重複Point.user_idを省いた
countは1クエリで可能でしょうか?
ヒントでかまわないのでお助け願います。

A 回答 (2件)

いやだから・・・



SELECT created,COUNT(DISTINCT user_id) as unique_count
FROM Point
GROUP BY created

ってこと。
例示がないので、検証はできません。

この回答への補足

それだと日毎にuser_idがユニークになりますが、
期間ではユニークにならないと思うのですが。。
where created > start_day
な感じで期間内でuser_idが重複しないものをカウントしたいんです。。

補足日時:2009/05/13 16:24
    • good
    • 0

状況がよくわからないですが



COUNT(DISTINCT user_id)

じゃないでしょうか?

この回答への補足

回答ありがとうございます。
説明不足ですいません。
Point.user_idがPoint.created毎にあります。
Point.createdをGroupByしてしまうため
Whereで指定するPoint.createdの期間内からPoint.user_idの重複を取り除けずに
困っています。。

補足日時:2009/05/13 15:54
    • good
    • 0

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

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

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

Q文法:V+O+~ing

今、現代史の英書にチャレンジしているのですが、同じようなような構文で引っかかっています。いずれも、V+O+~ing の構文。

1) The clunky way that power has been exercised under President Bush has left it looking isolated, tired, even weak.

2) The fight is on between social integrationists who oppose enlargement and reform and liberal expansionists who see Europe doing best by looking outwards and shedding outdated institutions like the Common Agricultural policy.

1)の has left it looking isolated, tired, even weak は、「孤立し、疲弊し、そして弱くさえ見えさせた」と理解しました。

2)の see Europe doing best by looking outwards は、「外を見る事によって、ヨーロッパは全力を尽くしていると評価する」と理解しました。

文法書を見たところ、V+O+~ing のVが知覚動詞の時に、このような構文になるようなのですが、そう考えると、1)の方が分かりません。


文法に強い方、宜しくお願いします。

今、現代史の英書にチャレンジしているのですが、同じようなような構文で引っかかっています。いずれも、V+O+~ing の構文。

1) The clunky way that power has been exercised under President Bush has left it looking isolated, tired, even weak.

2) The fight is on between social integrationists who oppose enlargement and reform and liberal expansionists who see Europe doing best by looking outwards and shedding outdated institutions like the Common Agricultural policy.

1...続きを読む

Aベストアンサー

これらの文の構造は、SVOCの第5文型です。
Cには、普通、名詞、動詞原型、不定詞、分詞等が主に入ります。

分詞(ご質問の場合は現在分詞)を入れることのできる他動詞は、知覚動詞に限りません。
leaveもそうですし、例えばhaveを使役動詞として使う場などでも、Cに分詞を入れることが可能です。

この辺りは非常に複雑、といいますか、確たる体系化が成されていないところで、文法書のそこそこ詳しいものでも、本質的レベルでは、単例文群の解説のみに止まっているものが多いのが実情です。
個々の動詞によって、Cに入れることのできるタイプが様々故、まとめにくいのでしょう。

面倒ですが、単語毎、”辞書”をお引きなられて、その用例を参照なさった方が、とりあえず直接的に目的が達せられる可能性が高く、手っとり早いと言えます。

なお、ご質問にあるleaveの訳は、「Oを~している状態にしておく(放置したままにしておく)」であろうかと思われます。

Qfind_or_createのようなクエリを出したい

お疲れ様です。
お世話になります。

データベースにあるキーを基にSELECTを出して、該当レコードがあればそのレコードのIDを取得、
なければ、そのキーをINSERTして、INSERT_IDを取得する。

これをひとつのクエリでできないかと悩んでいます。
perlだとfind_or_createというメソッドがあるらしいのですが、
私はPHP書きです。
DBはMySQL5を使っています。
PHPも5xです。

ググってもあまりいい案はなく、ムリならムリと突きつけていただければ
2つのクエリでがんばります。

よろしくお願いします。

Aベストアンサー

>そのキーをINSERTして、INSERT_IDを取得

auto_incrementを使うということですか?
auto_increment指定列と、もう一つ別のユニークなキーがあり、そのキーで検索するということでしょうか?

#1の例のauto_increment版です。

1.テスト用表定義
create table t1
(c1 int primary key auto_increment,
c2 char(1),
c3 varchar(10));
create unique index t1ix1 on t1(c2);

2.テスト用初期データ
insert into t1(c1,c2) values(null,'a'),(null,'b');

3.ストアドプロシジャの定義
drop procedure if exists find_or_create; -- 存在したら削除
delimiter // -- 終端記号の変更
create procedure find_or_create
(in pKey char(1),
out pInsertID int,
out pRC int)
--
-- 存在したらキー値を返し、存在しなかったら追加
--
begin

set pRC=0,pInsertID=null;
-- 検索してみる
select c1
into pInsertID
from t1
where c2=pKey;
if pInsertID is null then
-- 存在しなかったら追加
insert into t1(c1,c2)
values(null,pKey);
-- LastInsertIDを取得
select last_insert_ID()
into pInsertID;
set pRC=4;
end if;
end;
//
delimiter ; -- 終端記号を元に戻す

4.テスト
call find_or_create('c',@InsertID,@rc);
select @InsertID,@rc;
call find_or_create('c',@InsertID,@rc);
select @InsertID,@rc;
call find_or_create('d',@InsertID,@rc);
select @InsertID,@rc;
call find_or_create('a',@InsertID,@rc);
select @InsertID,@rc;

>そのキーをINSERTして、INSERT_IDを取得

auto_incrementを使うということですか?
auto_increment指定列と、もう一つ別のユニークなキーがあり、そのキーで検索するということでしょうか?

#1の例のauto_increment版です。

1.テスト用表定義
create table t1
(c1 int primary key auto_increment,
c2 char(1),
c3 varchar(10));
create unique index t1ix1 on t1(c2);

2.テスト用初期データ
insert into t1(c1,c2) values(null,'a'),(null,'b');

3.ストアドプロシジャ...続きを読む

Q【英語】【by ~ingの意味上の主語は主節の主語と同じ?】

奇妙な質問かもしれませんが、質問があります。
それは、一般に手段を表すby~ingのingの主語は主節の主語に一致しなければならないのか?ということです。

例えば、weblioにおける例文、
The device is used by being connected with a signal outputting means which outputs signals every time when safe numbers of the game machine increase by a set number.
この装置は、遊技機のセーフ数が設定数だけ増加する毎に信号を出力する信号出力手段に接続して用いられる。

【1】この主文の主語は、The device ですよね。従ってby~ingの意味上の主語は、The deviceとなり、受け身のbeing connectedにしている。この解釈は正しいですか?

【2】となると、上記文章を以下のように書き換えたとすると、(無理やりですが。。。)
You use the device by being connecting it with a signal outputting means which outputs signals every time when safe numbers of the game machine increase by a set number.
のように、by以下を修正すればよいということなのでしょうか?

手段を表すby ingの主語は、主文に常に一致させなければならないと考えていいのでしょうか?
教えていただけると幸いです。

奇妙な質問かもしれませんが、質問があります。
それは、一般に手段を表すby~ingのingの主語は主節の主語に一致しなければならないのか?ということです。

例えば、weblioにおける例文、
The device is used by being connected with a signal outputting means which outputs signals every time when safe numbers of the game machine increase by a set number.
この装置は、遊技機のセーフ数が設定数だけ増加する毎に信号を出力する信号出力手段に接続して用いられる。

【1】この主文の主語は、The...続きを読む

Aベストアンサー

【1】正しい解釈です。

【2】ちょっとあわてましたね。
"by being connecting it with"ではなく"by connecting it with"ですね。

元の文:"The device is used by being connected with a signal (by you)"と考えれば、
1)You use the device
2)You connnect it(=the device) with a signal
と考えなくてはなりませんね。すると上のよう(by connecting it with)になります。

QUNIQUE KEY user_name_inde

サンプルのCREATE TABLE文 の中に、
UNIQUE KEY user_name_index(user_name)

とあったのですが、意味を教えてください。

 自分で調べた限りは、UNIQUEというのはあったのですが、
 UNIQUE KEY が見つかりませんでした。
 UNIQUE KEY は、UNIQUEと同義なのでしょうか?
 あるいは、こういう書き方があるのでしょうか?

 また、CREATE TABLEの中で、user_nameカラムを作成しているのですが、
 user_name_index(user_name)では、何をしているのでしょうか?
 user_name_indexと別の名前でUNIQUE KEYに設定しているのでしょうか?

 それとも、_indexとついてるので、
 この書き方だけで、ユニークインデックスなるものにしているのでしょうか?

Aベストアンサー

>UNIQUE KEY user_name_index(user_name)

user_name_indexという名前で、user_nameにユニークインデックスを設定しています

「user_name_index」は特に命名ルールがあるわけではなく
hogeでもfugaでもなんでもかまいませんが、本人が後から見てわかるようなものに
しておくのが賢明です

たとえば
(1)CREATE TABLE X (A INT,B INT,C INT,UNIQUE KEY D(A));
(2)CREATE TABLE Y (A INT UNIQUE,B INT,C INT);
(3)CREATE TABLE Z (A INT,B INT,C INT,UNIQUE KEY E(B,C));

(1)であればAフィールドをつかったDという名前のユニークキーを作りますし
(2)のような書き方でもユニークインデックスは設定できます
(この場合、インデックス名はAになります)
(3)のように複合インデックスを貼ることもできます
(この場合BとCの組み合わせがユニークであるという意味になります)

>UNIQUE KEY user_name_index(user_name)

user_name_indexという名前で、user_nameにユニークインデックスを設定しています

「user_name_index」は特に命名ルールがあるわけではなく
hogeでもfugaでもなんでもかまいませんが、本人が後から見てわかるようなものに
しておくのが賢明です

たとえば
(1)CREATE TABLE X (A INT,B INT,C INT,UNIQUE KEY D(A));
(2)CREATE TABLE Y (A INT UNIQUE,B INT,C INT);
(3)CREATE TABLE Z (A INT,B INT,C INT,UNIQUE KEY E(B,C));

(1)であればAフィールドをつかったDという...続きを読む

Qto+ingの形はどういういみですか?

こんにちは
すごく初歩的なことかもしれませんが
commited to workingと
commited wroking
の違いはなんでしょうか?
基本的にtoのあとにingのかたちをつけるのは平気なのでしょうか?
このcommitedはcommitの動詞ではなくcommittedの形容詞でだからこそto+ingが使えるのですか?

動詞+to+ingのかたちって可能でしょうか?
また形容詞+to+ingだけが可能なのでしょうか?
あるとすればなんて言う名称ですか?たとえば(現在完了、現在~とか)

よろしくおねがいします

Aベストアンサー

commitの基本的な使い方は
"commit ○○ to ××"
で、意味は
「○○を××に引き渡す、ゆだねる」
です。
○○と××にはともに名詞が入ります。

質問文中の表現"committed working"は、この使い方の、○○の部分が
動名詞workingである場合ですね(commitedはcommitの過去形)。
これだけだと「働くことを引き渡した」だけになってしまい、
何に対して引き渡すのかがわかりません。
また「働くことを引き渡した」という表現自体も意味不明です。
このようなcommitの使い方は普通されないと思います。

質問文中のもう一つの表現"commited to working"は、上の基本的な使い方を受動態にした
"○○ is committed to ××"
のbe動詞以下を抜き出したものですね。
この場合、committedは過去分詞です。
意味は「働くことに引き渡される」になりますが、commitのよく使われる用法に、
"commit oneself to ××"で「××に関わりあう、××を引き受ける」というのがあり、
これの受動態が"one is committed to ××"になります。
この意味に取ると、"commited to working"は「働くことを引き受ける」になりますね。
このような使い方はよく見られます。

さて、to+...ingについてですが、ここに出てくるtoは、
動詞の原型を後ろにとって不定詞を作るtoではなく、
名詞を後ろにとって間接目的語を導く前置詞のtoです。
ですから、今の例のように、上の××として「働くこと」を入れたければ、
workを動名詞にしてworkingとしなくてはいけないわけです。

「toの後に動詞の類が出てきたら不定詞だ」と直感的に考えないで、
そのtoが本当に不定詞を作るtoなのか、それとも前置詞のtoで
後ろには名詞をとるものなのか、ということを
しっかり判断するようにしなくてはいけません。
特に、形容詞+to+名詞の形は多いですので、この名詞の部分に
動名詞が入っているものを、不定詞と間違わないように気をつけてください。

commitの基本的な使い方は
"commit ○○ to ××"
で、意味は
「○○を××に引き渡す、ゆだねる」
です。
○○と××にはともに名詞が入ります。

質問文中の表現"committed working"は、この使い方の、○○の部分が
動名詞workingである場合ですね(commitedはcommitの過去形)。
これだけだと「働くことを引き渡した」だけになってしまい、
何に対して引き渡すのかがわかりません。
また「働くことを引き渡した」という表現自体も意味不明です。
このようなcommitの使い方は普通されないと思います。

質問文中...続きを読む

QHAVING count()で重複したデータは1として取得する方法

質問の内容はタイトルの件なのですが、詳細に説明させて頂きます。

テーブル名:sample
----------
id,type
----------
1,A
1,A
1,B
1,C
----------

上記のような4件のレコードが入ったテーブルがあったとします。
このテーブルのidでグループ化し、
--------------------------
SELECT id
FROM sample
GROUP BY id
HAVING count(type) = 3
--------------------------
のようにして、typeが3種類だけのレコード(A,B,Cのような)を取得したいのですが、
この方法だと、単純にレコード件数の4件が取れてしまいます。
どうにかAの重複を1つとして、うまく取得する方法は無いでしょうか。

よろしくお願い致します。
また、質問内容におかしな点などあればご指摘下さい。

Aベストアンサー

すみませんなんか違う

SELECT id
FROM sample
GROUP BY id
HAVING count(distinct type) = 3

とするとユニークなtypeが拾えます

Qto+~ と ~+ing 形

to+動詞の原形
動詞の原形+ing
が「すること」というのはわかり,大体の使い分けも分かるのですが,聞いたこともないような動詞を「すること」にしなければならない場合,to+~ と ~+ing のどちらにすべきかを,どう調べればいいのでしょうか?

辞書に載っているのでしょうか?辞書ならば,引いた後,どこを見ればいいのでしょうか?

Aベストアンサー

不定詞にするか、動名詞にするか、という問題ですよね?
だとしたら、変形する動詞の問題ではありません。
つまり、前置詞の後ろなら不定詞ではなく動名詞。他動詞句の後ろなら、その他動詞句の問題になります。
give up -ing / mind -ing などは「~することを」の部分は動名詞になります。
decide to - / hope to - などは不定詞になります。
このように動詞句によって、後にくる「~すること」が不定詞になるか動名詞になるかが決まります。
もちろん
begin や start のようにどちらが来ても構わない(微妙な意味の差異はある)ものも多いですが。
更に
remember や forget のように目的語が動名詞と不定詞では意味が異なるものもあります。
従って、辞書で引く場合は「~すること」になる動詞を調べるのではなく、その前の動詞を調べなくてはなりません。
一般的に、不定詞は「未来・プラス指向」、動名詞は「過去・マイナス指向」という傾向があるみたいですが全てではありません。

Qトランザクションとlast_insert_id

トランザクション中にinsertする予定のテーブル(未コミット)のauto_increment値を取得することはできるのでしょうか。

以下のような処理を期待しているのですが、hoge1テーブルのauto_increment値が取得できずに困っております。last_insert_id に関わらず、hoge1テーブルのauto_increment値が取得できる方法があれば教えてください。

(1) トランザクション開始

(2) $sql=" INSERT INTO hoge1(name) value('あああ'); ";

(3) ( ロールバック )

(4) $key=mysql_insert_id();

(5) $sql2=" INSERT INTO hoge2(hoge1_primary,age) value($key,'20歳'); ";

(6) ( ロールバック )

(7) コミット

(8) トランザクション終了

よろしくお願いします。

環境: php5,mysql5 (InnoDB)

トランザクション中にinsertする予定のテーブル(未コミット)のauto_increment値を取得することはできるのでしょうか。

以下のような処理を期待しているのですが、hoge1テーブルのauto_increment値が取得できずに困っております。last_insert_id に関わらず、hoge1テーブルのauto_increment値が取得できる方法があれば教えてください。

(1) トランザクション開始

(2) $sql=" INSERT INTO hoge1(name) value('あああ'); ";

(3) ( ロールバック )

(4) $key=mysql_insert_id();

(5) $sql2=" IN...続きを読む

Aベストアンサー

トランザクション中のINSERTに対しても、LAST_INSERT_ID()関数は適切な値を返すと思いますが、状況としては、『取得できない』とは、エラーがでるのでしょうか?それとも、不適切な(予期しない)値が得られるのでしょうか?
状況をもう少し教えていただけると助かります。
(直にSQLで『SELECT LAST_INSERT_ID();』を実行して、ダメでしょうか?)

Q「名詞+ING形」について教えて下さい?

回答いただいた中からの質問です。
a) I took pictures of flying birds.
b) I took pictures of birds flying.
a)「私は飛ぶ鳥の写真を撮った。」
b)「私は飛び立つ鳥の写真を撮った。」
a)「-ing形+名詞」の場合は、「永続的・一般的な意味」を持つ意味
b)「名詞+-ing形」の場合は、「一時的・具体的な意味」を持つもの
と説明いただきました。
(質問)
a)についてはNHKラジオ講座で「現在分詞の前置修飾」と教わりました。b)の用法は始めて目にします。
(1)「名詞+-ing形」に文法上の呼び名はありますか?
(2)b)は和訳によると、鳥が水際から飛び立つ様が浮かんできますが、何故か、その違いと、使い方をもう少し例文を交えて教えて下さい。
「名詞+ING形」について、どんな事でも結構ですので、参考になるアドバイスを、皆様よろしくお願いいたします。 以上

Aベストアンサー

最初にNo.3の06miyachanさんへ質問です。次に、tommy0313さんのご質問へ答えます。

(1)No.3の06miyachanさんへ質問です。

>I hate to be play with crying children. (形容詞+名詞)
>「私は『泣き虫』と遊ぶのはいやだ」(過去においても、今でも、泣き虫というすべての人がきらいだ。)

to be play と書かれていますが、to be playing または、to play の間違いではありませんか。

(2)tommy0313さんのご質問への答え。

前置修飾と後置修飾の違いです。前置修飾は、普通の形容詞に多く見られ、たとえば a big white bird のように、永続的である意味本質的な特徴を示すわけです。分詞がこのように前置されれば、同じ感覚で捕らえられ、永続的で本質的な意味と感じることになります。
同様に、後置修飾は、多く関係代名詞とbe動詞の省略と感じられ、つまり、a bird that is flying からのthat is/was の省略と感じられるため、文章と感じるわけですし、is,was という時制を示す部分があったと感じるので、一時的な属性と感じるわけです。

しかし、a crying baby も a baby crying もよく使います。基本的には、互いに分かっていること、既知のこと、または、一目見て分かるようなことについては、前置修飾を使い、新情報として改めての説明が必要なことには後置修飾を使うのだと思っています。

最初にNo.3の06miyachanさんへ質問です。次に、tommy0313さんのご質問へ答えます。

(1)No.3の06miyachanさんへ質問です。

>I hate to be play with crying children. (形容詞+名詞)
>「私は『泣き虫』と遊ぶのはいやだ」(過去においても、今でも、泣き虫というすべての人がきらいだ。)

to be play と書かれていますが、to be playing または、to play の間違いではありませんか。

(2)tommy0313さんのご質問への答え。

前置修飾と後置修飾の違いです。前置修飾は、普通の形容詞に多...続きを読む

QLAST_INSERT_IDで同時にアクセスが会った時

MYSQL 3.23
auto_incermentで発行されたIDを別テーブルに使いたいのです。

last_insert_id や mysql_insert_id はコネクションごとに区別されるというのは本当でしょうか?

同時に複数のinsertが実行された場合でも、同じコネクションで発行されたIDだけを取得可能でしょうか?

よろしくお願いします。

Aベストアンサー

「多くの場合、ユーザは、複数のテーブルの
一意の識別子を管理するために ROLLBACK や
LOCK TABLES を使用していた。これは、
AUTO_INCREMENT カラムおよび SQL 関数
LAST_INSERT_ID() または C API 関数
mysql_insert_id() を使用することで、
はるかに効率的に処理することができる。」
とありますので、一応は保証されていると考えて
よいのではないでしょうか。もちろん私が、保証
することはできませんので、自己責任で判断すべき
ことです。
3.23はトランザクション環境にないため、厳密に
整合性を保つためにはid管理は使用者側が任意に
行うべきだというのが個人的な感想です。

お役にたてませんで、申し訳ないです

参考URL:http://dev.mysql.com/doc/refman/4.1/ja/ansi-diff-transactions.html


人気Q&Aランキング