集計関数使えば？

>>551
入力は↓のようにしてるんですが，
select jikan1, jikan2, timediff(jikan1,jikan2) from テーブル名;

この場合、集計関数はどこで使えばよいのでしょうか？
初心者ですいませんorz

>>546
ヒントアリガト。でもv4.1での実装なんでトリガはだめなんだorz

>>547
俺の頭の悪いのが問題かも知れんが、ちょっとイミフ


やっぱり素直にプログラム側で重複チェックを実装することにするヨ

5.1の目玉的な機能であるパーティショニングだけど、
FULLTEXTインデックスが使えないのね

データがすごい量で増えていくので、パーティショニング機能は
使いたいけど、全文検索するカラムがある場合は
そこだけ別テーブルで管理って感じなのか？

ver4のﾃﾞｰﾀをver5に移す時はどのような手順を踏めば良いですか？

初心者です。勉強でc++(visual studio)上からmysqlを操作する方法を探していますが、
方法を記載してるサイトがありましたら教えていただけないでしょうか？

質問です。
blog_articlesというテーブルの中に、timeというキーがあります。
timeはYYYY-MM-DD HH:II:SSというフォーマットになってます。

timeの、YYYY-MM-DDの部分だけで、重複削除してレコードを取り出したいのですが、
どのようなクエリ送信を行えばよいでしょうか？

>>558
GROUP BY LEFT(time,9)
で良くね？

10だったな
まあどうでもいいや

>>516
バグなんじゃない？
5.0なら大丈夫だと思う。

Oracleとは違うのだよ、Oracleとは。

DBに関しての質問です。
Yahooオークションのようなサイト作ろうと思ってます。
カテゴリーのテーブルはどのように作るべきでしょうか？
categoryテーブルを１つだけでよいのか？
それともcategory1,category2...と分けるべきなのか？
よろしくお願いします。

悪いこと言わんからもうちょっと基礎的な勉強してからにすれ

>>565
予想通りのレスありがとうございます。
一応、知ってる人だけレスください＾＾；

「カテゴリー」の定義にもよるけど、集品を分類するための単純なタグ付け
程度の意味合いであれば普通は一つ。
あとは商品とカテゴリーの対応関係が1:NかN:Nかに応じて商品テーブル
にcategory_idのカラムを付けるか商品vs.カテゴリーの対応表を作るか、
お好きなように。あと、

>category1,category2...と分けるべきなのか

という選択肢は、RDBを多少なりとも勉強した人間であれば脊髄反射的に
>>565と同様の感想を持つ程度に珍妙である事は覚えておいて損はない。
基礎的な本でスキーマとインスタンスの区別から勉強した方が良いよ。

>>564
どう作ろうがそれこそ自由なので一概に言えないが
やっぱり検索の事を考えるとテーブルは一つかな。
カテゴリの数だけテーブル作るのもめんどくさいし。

でも自由なんで、自分で実験をして自分が使いやすい方を決めた方がいい。

>>567
もうちょっと簡単に教えてください。
ネラーって難しい言葉を羅列して賢く見せたい人多いけどそんなのどうでもいいです。

>>568
カテゴリの数ではなく深さでテーブルを追加するべきではと思っています。
ジャンルによってカテゴリの深さも違いますし後で増えたときすぐ対応できますから。

１つってことは何種類のカラムを作るべきでしょうか？
category_id INT
category_name VARCHAR
この２種類で良いのでしょうか？
ちなみに自分としてはRDBを用い複数のテーブルを作るべきだと思ってます。
※作り方は自由と言われたらそれまでですが正解を導き出したいので皆さんに助けを求めています。

>>570
前提知識が無いままにここで聞いても時間の無駄。
悪いけど、RDBを使うレベルまでに到達していないから、
あなたにはSQLはまだ使えない。

勉強して出直してきてくださいな。

掲示板でなんでも手取り足取り教えてくれると思うな。

果実とおんなじなんだよ。
育てずに果実だけ得るなんてことはできなくてね。

>>570
いちいち一言カチンと来るが釣られてやる。バカの壁に叫ぶようなものか。

スキーマとインスタンスという言葉はRDBを知らない人にとっては全く
馴染みがないものなので腹が立つのは判る。
ただこれはデータベース設計における基本的な考え方なので、正解が
欲しければまず勉強してもらわないと始まらない。

すごく意訳をすればスキーマとは未来永劫変化しないもの、とか構造。
というか、そういう意気込みで設計するもの。
インスタンスとはデータの出し入れとかその日の気分で変化しうるもの。

で、テーブルの定義は「スキーマ」に属する。カテゴリが増えたり深さが
変化する度にテーブルを増やしたり消したりするのは、世間一般的には
良い設計ではないし、検索や運用も大抵は困難という経験則がある。

なので、カテゴリ数が増減したり深さが変化してもテーブルの定義を
いじったりテーブルの追加削除を行う必要が一切無い、まずはそういう
テーブルを考えてみること。これがスタート地点。大原則。黙って従え。

ちなみに深さありのカテゴリ表を作りたいのであれば、大抵は次のような
テーブルがら設計を考え始めると思う。無論他の方法もある。

category_id INT
category_name VARCHAR
parent_id INT

>>572
その作りで、1番上のカテゴリに属するデータがいくつ入ってるとかわかりますか？
下位カテゴリから上位カテゴリを取得することは可能ですが
上位カテゴリから下位カテゴリ（末端）を取得することは不可能ですよね？

>>572
いちいち相手しないで放っとけや

>>574
おまえこそいちいち気にすんなやｗ

>>573
SQL92の範疇では苦手な類だけど、全然可能だよ。
SQLの教本には必ず出てくる類の問題。
"SQL 階層問い合わせ"、で検索してみるとよし。

>>574
いぢっているだけなので、飽きたら止めます。

一つのテーブルにカラムってPCのスペックにもよるでしょうけど何個くらい追加して大体大丈夫なもんなんでしょうか？
テーブル

カラム1　カラム2　カラム3　カラム4・・・・
データ　データ　　データ　　データ
　・　　　　　・　　　　　・　　　　　　・
　・　　　　　・　　　　　・　　　　　　・
　・　　　　　・　　　　　・　　　　　　・


このカラムがもし40個くらいだと、多すぎって笑われちゃうレベルですかね？

正規化した上で必要なら別にいいのでは

>>576
おい！騙したなこの野郎！
MySQLには階層問い合わせがないらしいじゃない。
Oracleじゃないんだよここは。
ストアド・プロシジャで作るしかないのかな？

だれか>>569を教えて下さい。

>>580
いいって何が？それでできなかったの？

>>569
それでいいよ。

カラムが40個とか50個とか、現場ではざらにあると思うが（それが良いかどうかは別にして

>>581
>>582
なんか結果が違ったので。勘違いかな。もうちょっと確認してみます。

>>579
中途半端に調べて人を嘘つき呼ばわりするな。

階層問い合わせ機能(WITH RECURSIVE)がSQL99からの標準。
それ以前のSQL92の時代は階層の深さの上限を仮定してクエリを組み
立てることで階層問い合わせを実現していた。ちょっと面倒。

だから「SQL92の範疇では苦手な類」と書いた。
しかし苦手だが出来ない訳じゃない。これは自己結合(知らない言葉
だからって腹立てるなよ)の典型的な応用例で、ちゃんとしたSQLの
解説本には必ず例が説明されている。

珍妙なテーブル定義やストアド等の聞きかじりの技術を持ち出す前に
基本を学べ。基本を。

>>578>>583
はい
一応このテーブル一つで管理したいデータでして、
特に問題なさそうなのでこのままやってみることにします
ありがとうございました

>583
それって、正規化が出来てないか、手抜いてるんじゃ・・・。＞カラムが４０個とか５０個

>>585
WITH RECURSIVE kanri AS (
SELECT * FROM category WHERE category_id = '2'
UNION ALL
SELECT category.* FROM kanri,category WHERE category.parent_id = kanri.category_id
) SELECT * FROM kanri;

syntaxエラーが出てできませんがなにか…orz

おいおい
WITH RECURSIVEはMySQLで使えないってオチか？

>>589
書き方が中途半端だったが、MySQLはまだWITH RECURSIVEを
サポートしていない。だからSQL92の範疇でやる基本的な方法を
まず学べと言った。親切な自分がポインタを示すとだな、

http://www.mysql.gr.jp/mysqlml/mysql/msg/12071

これのAdjacency List(連接リスト)モデルが、階層の深さの上限を
仮定してクエリを組み立てる古典的なやり方。
これが基本。SQLの解説書にも必ず出ている。だから文句言う前に
ちゃんとした解説書でまずこれを勉強しろ。理解して使いこなせ。
WITH RECURSIVEだって発想の基本的な出発点はここだから。

ついでにこの記事には「ネストセット」という方法も書いてあるが、
ちょっと頭の体操が必要な上にちゃんと理解していないと更新で
はまる。せっかち君には正直お勧めしたくない。危険すぎて。
だからまず連接リストモデルをどうにかすべし。

WHERE の条件に bit 演算入れられますか？

MySQL - 4.0.27
MySQL - 5.0.45

下のようなテーブルで、日付とIDを記録しています。
COMEDATE | ID
-----------+-------
2009-02-21 | 10010
2009-02-21 | 10005
2009-02-22 | 10001
2009-02-22 | 10002
2009-02-22 | 10003
2009-02-22 | 10004
2009-02-22 | 10005
2009-02-23 | 10001
2009-02-23 | 10002
2009-02-23 | 10006
2009-02-23 | 10007
2009-02-23 | 10008

このデータから、特定の期間内のID種類数を求めるには
どうしたらよいでしょうか？

上記の場合であれば、９種類のIDがありますので、
9を求められればと思います。

出来れば、サブクエリの利用できる環境と、
そうでない場合のSQLを教えていただけると助かります。

SELECT count(DISTINCT id) FROM table WHERE comedate BETWEEN '2009-2-21' and '2009-02-23'
とか。
ってバージョンの違いわからないのでやってみて。

サブクエリバージョンは、、、
SELECT count(id) FROM (SELECT DISTINCT id FROM table WHERE comedate BETWEEN '2009-2-21' AND '2009-02-23') AS t;

>>594
ありがとうございました。
なぜか、固定観念でGROUP BYが必要だと思い込んで四苦八苦していました…

| 日付 | 作業 | 時間 | 名前 | 役職 |
------------------------------------------------
| 2007/9/7 | 開始 | 8:00:00 | 田中 | ヒラ |
| 2008/9/7 | 終了 | 17:48:00 | 田中 |　　　|
| 2008/9/7 | 開始 | 9:30:00 | 佐藤 | 課長 |
| 2008/9/7 | 終了 | 17:00:00 | 佐藤 |　　　|
| 2008/9/7 | 開始 | 9:00:00 | 青木 | 部長 |
| 2008/9/7 | 終了 | 17:00:00 | 青木 |　　　|
| 2007/9/7 | 開始 | 8:00:00 | 山田 | ヒラ |
| 2007/9/7 | 終了 | 17:23:00 | 山田 |　　　|

このテーブルから、ヒラである田中と山田のデータだけを抽出した結果を表示させたいんです。
つまり、↓のようになる感じです。

| 2007/9/7 | 開始 | 8:00:00 | 田中 | ヒラ |
| 2008/9/7 | 終了 | 17:48:00 | 田中 |　　　|
| 2007/9/7 | 開始 | 8:00:00 | 山田 | ヒラ |
| 2007/9/7 | 終了 | 17:23:00 | 山田 |　　　|

どなたかお願いします。

>>579
select
　A.日付, A.作業, A.時間, A.名前, A.役職
from
　T A,
　(SELECT DISTINCT 名前, 役職 FROM T) B
where
　A.名前 = B.名前
AND
　B.役職 = 'ヒラ'

データを見たときにヒラ社員も作業終了時はヒラ以上に
グレードアップするのかと思い少し笑ってしまいました。

sage