SQL初心者質問スレ [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
DB自体の操作やユーザー管理も含めて言っているのじゃないかな? 業務で使う時は特殊な記述を避けるというだけの話かと 顧客id 顧客名
取引id 顧客id 取引額 取引日
こんな2つの顧客テーブルと取引テーブルがあるとします。
取引テーブルの取引日と顧客idはUNIQUEな関係です(同じ日の再度の取引はない)。
ある顧客との、ある期間中どれだけ取引があったか(回数と総額)の計算をしたいです。
顧客テーブル
顧客id INT PK
顧客名 VARCHAR NN
取引テーブル
取引id INT PK
顧客id INT FK
取引額 INT NN
取引日 DATE NN
UNIQUE (顧客id, 取引日)
インデックスを貼るべきところとかよくわからないのですが、テーブルはこんな感じでいいのでしょうか?
検索(WHERE)に取引日を使うので、取引日にもインデックス貼ったほうがいいのでしょうか?
あと取引日のDATE型なんですが、UNIXTIMEのようにある日からの起算のほうが検索早そうなのでINTにしたほうがいいですか? >取引日にもインデックス貼ったほうがいいのでしょうか?
それで検索をよくするんだったら良いんじゃないの。自分は株価テーブル作っててPKが(コード、出来高年月日)なんだけど、
出来高年月日での検索もするんでその出来高年月日にindex貼ったら実行スピードめちゃ上がったし >>345
DATE型使っても、内部表現はバイナリー値だから実行スピードは変わらないだろう >>346-347
レスありがとうございます。
実例での効果まであげていただいて感謝です。
DATA型でも検索速度は変わらないとのことなので、
このままでCREATEしたいと思います。 RDBMSの内部構造を意識するのが初心者なのかと。 まあプログラムやってればその辺はちょっとは検討つくでしょう
JavaScriptみたいのしかやったことないとかだとDBいじる機会もなかなかないだろうし
ところでDATE型とINT型の検索速度の比較って
ググって見るとINT型のほうが早いみたいだけど 郵便番号と地名が書いてるデータベースを作るとして
0から始まる北海道はとりあえず無視するとして
7桁のユニークな数字になるわけですが
そういう番号があっても主キーにせずオートインクリメントなサロゲートキーを作るべきですか? 郵便番号は郵便局が自分たちの業務をやりやすくするために振っただけのものであって
地名との一対一の紐付けを保証するものではないし
郵便局の都合で変更されることもある
そのへんを理解した上で使うなら別にいいんじゃない? 「郵便番号の」サロゲートだとしたらそのへんは何も変わらんが。 >>353
> ところでDATE型とINT型の検索速度の比較って
> ググって見るとINT型のほうが早いみたいだけど
そらそうよ。プログラムやってれば見当つくはず。
>>354
困ったことに、郵便番号と地名は1:nです データベースは当然、1:n関係を表現できるだろうに。何を困ることがある? 郵便番号はちょっと例えが悪かったかな・・・
例えばクレジットカードとか連番だと都合が悪いけど一意な番号
それでもサロゲートは必要? だってとりあえずauto incrementを主キーにしとけって書籍に書いてるんだもの 初心者にはあれこれいうよりベストな書き方覚えろっていう
ベストでもないオレオレ書き方教える書籍は多い
全部のテーブルにcreated updated作れみたいな >>353
そもそもどのRDBMSのINT型なのか知らないが、標準SQLではコンピュータの数値表現としているので、速いのはあたりまえ。
ちなみにOracleでは標準SQLのINT型はNUMBER型なのでまったく違う。当然Oracleでは計算が遅くはなる。 >>365
プログラミング言語の歴史では、小文字をメインに使うようになったのはC言語あたりから。 Oracleの場合、内部で大文字に変えていると聞いたことがある
本当かどうかは確かめたことないし、今もそうなのかは分からないが
使っていた当時は全部大文字で書いてたな DB側で用意してる関数含めてユーザ入力による変数になってる
テーブル名とかカラム名以外は全部大文字にしてる
`table` `long_table_name` `column` `long_column_name`
ご丁寧に``で囲んでるけどこれもいらんのよなあ
なんかいい規則があればいいんだけど 基本的に大文字しか使えない環境が当たり前の頃からSQLあるからな、、、
COBOLでの EXEC SQL 文とか懐かしいなあ >>368
それを言うのがいるけど、プログラマでそんなことを言ったら恥ずかしいぞ。大文字、小文字を区別しないなら大文字、小文字の判定処理が入るわけで、そこから大文字に変換する処理が遅くて問題になるなど阿呆みたいなこだわりだ。 大文字に変換する処理が遅くて問題になるなんて誰か言ってた? 大文字が大文字かどうかより、文字がなんなのかの判定も入るわけで、そんな処理時間はいつの時代のコンピュータの性能で考えているんだよw
こんなことを言い出したらRDBはあらゆることが遅すぎて使えない。現実にRDBはコンピュータの性能が上がったから使い物になるようになった歴史も知らないのか? 368本人です。何かお騒がせしてしまい済みません。
相当昔の話です。
動かしていたサーバーはW2k、CPUはP3、メモリー4G程度でした。
できるだけ負荷を減らせと言う指示の中で作業してました。 パーサーの仕様で大文字小文字区別しないにしても
大文字しかパースできなくて変換処理が必要だとしても
それに判定を挟む必要もなければ
ただの一文にすぎないSQLに処理時間なんてギャグかよって話 >>378
構文解析にかける時間に比べれば
文字列の処理なんて微々たるものがわからないような猿 >>377
判定処理はいるだろw
文字がAならAかどうか判定する。
何この低レベルw 小文字混ざってる前提で全て大文字にしてからパースすればいいだけってのは
プログラマーならわかるだろ 結局予約語だけ大文字で書けばいいの?
開発効率落ちまくるけどどの参考書もそうしてるよな コーディング規約ってのがそれぞれのチームなり部署なりにあるだろ?
それに従えば良いだろ。
んで自分一人のものだけなら好き勝手に そうなんだけどさ、大文字と小文字使い分けるのってすごい面倒なんだよなぁ
玄人の皆さんは使い分けなきゃいけない状況のときどうやって書いてるの?
毎回shift+capslockしてるの?てか列名日本語にするのほんとやめてください 使い捨ては全部小文字
あとで見返すことがあるものは予約後大文字、シフトに指置けばいいべ >>384
効率落ちまくるって、どんだけクエリ書いてるんだよ
300char/minだとして、大文字小文字意識しても5秒ほどしかかわらんだろ
つまり、1分の差がでるのに3600文字必要
毎日1万字書く奴がいたとしても、せいぜい3分/dayくらいの差だ >>388
お前はキーパンチャーかwどんだけキーボードマスターだよw 全部小文字でもいいだろ好きにしろ
ぱっと見てここSQLだなってわかるようにしたいなら大文字にすりゃいいし
動きゃいいんだよ >>381
大文字にするにあたって元の文字が大文字か小文字か判定する必要はないって話だと思うんだが、
あなたが言うように判定するのは無駄なので判定しないのが普通。 >>388
キーパンチャーなみのタイプ速度で、普通は考えられないような量のクエリを1日にタイプするとしても、
それでも1日あたりの作業低下量は3分程度なんだが、>>384はどんだけタイプしてんだよって話だ
読解力ない奴って、底が知れんわ そもそもSQL誕生して何十年も経ってるのにいまだにこの議論してんだから
大文字小文字の問題は根深いよな
>>392
タイピング速度の問題ではなくてストレス的な意味の開発効率を言ってると思うぞ>>384は >>393
この程度のコーディングルールでストレスとか、向いてないんじゃねーの? 安価ミスしちゃうそそっかしい人はフォーマッタ使えばいいんじゃないでしょうか。 >>393
> 大文字小文字の問題は根深いよな
根深いっつーか、どっち派もいるというだけでしょ
他言語だっていつまでたっても中括弧の書き方レベルの議論が終わらないし てか、別に大文字小文字で開発効率が落ちる奴がいても不思議じゃない。
不思議じゃないが、だから何ってはなしで。
俺らには関係ない。 スレチかも知れんがMac使ってるやつはSequel入れとけフリーでこんないいの
なかなかないぞ 大文字小文字もインデントの具合も全てどうでもいいと思ってるが・・・
カンマを行頭に置く奴だけは許せん!!! 俺もこの程度で効率落ちまくるなら、プログラマに向いてないと思うよ プログラマなら、たとえMISRA-C完全準拠を要求されても、淡々と従うものだ。 >>381
お前がw
このスレでw
一番低レベルだがなwww 俺は逆に面倒だと思う人のほうがプログラマには向いてるとおもうけどな
if so を考えるのって大事だと思うぞコーダーって意味なら向いてないと思うけど >>404
面倒だと思うのはかまわない
ただ、この程度で効率落ちまくるレベルの奴は、プログラマに向いてないってだけだ 「落ちまくる」のは向き不向きよりも不慣れなだけだろう
向き不向きの話をするなら、大文字で書くことに何の疑問も持たない人の方がプログラマに向いていない
理由があって大文字を選択してるなら良いことだと思うが >>406
キーワードを大文字で書けくらい、即慣れるだろ
ふつーのプログラマなら、効率が落ちまくったりしません >>386
> 毎回shift+capslockしてるの?
誰も答えないのでコメントしとくか。
普通はCapsLockなんか使わないでしょ。
Shift推しながらタイプするだけ。 予約語なんて一覧にして各RDBのドキュメントに乗ってんだから
ちょちょいとコピペして整形して正規表現で置き換えりゃいいだろ それでは気をとりなおしてwレベル高い正規表現どうぞw
↓ エディタに丸投げするだけなのに
本気で言ってるのかどうなのか・・・ >>391
何をわけのわからないことを言ってるのか?コンピュータからしたら大文字と小文字のアルファベットは別の文字だぞ。 初心者が数字列を数値だと言い張ってゆずらないのと同じなのかな?
こういうのは時間の無駄だから関わらない方がいいわ。 全くだな
話がわかってないID:cT/4yIz6 のようなキチガイは構ってはいけない いやいくら馬鹿だからってキチガイさすがには言いすぎだろw
さて与太話はこれくらいにして
そろそろ正規表現の話題の戻そうか ぶっちゃけどんなプログラミング言語習得するよりDB極めたほうが金になるよな
業界の中でもDBエンジニアを目指すのが一番おすすめだわ >>423
クエリだけ書けてもプログラムないと高度な事できないだろ。分析止まりでランニングできない。 >>425
逆にクエリが書けなればダイナミックなプログラムはかけないけどな >>426
だからどちらかじゃなくて両方必要って話だろ 改行考慮や大文字小文字無視するだけでも正規表現使う理由にはなる
正規表現と聞いて脊椎反射するやつはエディタで置換したことないやつ 凄く難しいこと言ってSO
だけど全体的には凄くアタマ悪SO
正規厨って大体SOUL 難しいように聞こえるならお前の頭が悪いのだろう
正規表現は一般的なテキスト処理にも使われるもので
プログラムの中だけで使われるものじゃない 突如何者かに向けて正規教室を始めた正規厨SO FOOL 正規表現知ってから、もう、文字数数えて
左から何文字目から何文字目でアレを見つけて
文字数数えて次のアレを見つけて文字数数えて
切り取って、みたいなことやらなくなったから
頭が鈍った気がするけど
便利でもう過去には戻れない。 だが正規表現にバグがあった時のことを考えると
怖くて本番業務には使えない 正規厨ってニートだったのかYO
正規ばかり弄ってないで働けYO ■ このスレッドは過去ログ倉庫に格納されています