虹裏img歴史資料館

1 17/07/16(日)10:10:37 No.439982850

select "くそはげ";

2 17/07/16(日)10:10:44 No.439982864

メリケン人の講演をネットで見てると すぃーくぉーーー って発声してて　へーと思った

3 17/07/16(日)10:12:31 No.439983127

(+)って書くの禁止ね

4 17/07/16(日)10:13:43 No.439983321

SQLの勉強の前にデータの正規化について義務教育化すべきだよ

5 17/07/16(日)10:13:48 No.439983338

select * form 「」 where nenshu >= 10000000

6 17/07/16(日)10:13:51 No.439983347

SQLでプログラミングはやめて…

7 17/07/16(日)10:14:09 No.439983390

accessだとUNIONだと255文字に制限されてUNION ALLだと255文字超えても出力できるとかいうのが意味わかんなかった

8 17/07/16(日)10:15:45 No.439983640

>select "くそはげ" from dual;

9 17/07/16(日)10:16:25 No.439983747

正規化は色んな所で役立つからいいよね

10 17/07/16(日)10:16:30 No.439983754

プログラマのためのSQLとSQLアンチパターンは読んで覚えておくように

11 17/07/16(日)10:17:17 No.439983889

誰だよこのクソ長い複雑怪奇なSQL書いたやつ… ストアドも使ってるから解析めどい…

12 17/07/16(日)10:17:53 No.439983971

nenshu NUMBER(7)

13 17/07/16(日)10:19:14 No.439984176

select * from ( select "あ" from dual union all select "い" from dual union all select "う" from dual union all select "え" from dual union all select "お" from dual )

14 17/07/16(日)10:20:00 No.439984284

select decode(decode(decode(…

15 17/07/16(日)10:20:01 No.439984289

Select * From KABUKI As k Where '546' In (k.van, k.te, k.lin) 結構便利そうだけど使う機会に殆ど出会わない

16 17/07/16(日)10:20:44 No.439984401

>select decode(decode(decode(… プログラムでやれや！

17 17/07/16(日)10:21:08 No.439984467

>select decode(decode(decode(… case式使えや

18 17/07/16(日)10:21:36 No.439984551

>accessだとUNIONだと255文字に制限されてUNION ALLだと255文字超えても出力できるとかいうのが意味わかんなかった たぶんunionだと内部でソート処理して重複チェックするから その処理の都合

19 17/07/16(日)10:21:48 No.439984582

in使う奴は殺すマンいるこわい

20 17/07/16(日)10:22:05 No.439984626

CASE式つかうとSQLプログラミングがサクサクになるぞ

21 17/07/16(日)10:22:20 No.439984661

>Select * From KABUKI As k Where '546' In (k.van, k.te, k.lin) そういう設計書書くとたいてい上司に怒られる

22 17/07/16(日)10:22:31 No.439984693

>CASE式つかうとSQLプログラミングがサクサクになるぞ SQLでプログラミングはやめて…

23 17/07/16(日)10:24:01 No.439984922

MySQLのストアドマジフリーダム

24 17/07/16(日)10:24:02 No.439984923

プログラマのためのSQLは若い頃に第2版で読んだけど最近第4版で読み直そうとしたら脳の衰えを感じた

25 17/07/16(日)10:24:13 No.439984959

>そういう設計書書くとたいてい上司に怒られる だって k.van = '546' Or k.te = '546' Or k.lin = '546' って書くのバカっぽいじゃない

26 17/07/16(日)10:24:37 No.439985022

TRUNCATEするね…

27 17/07/16(日)10:25:45 No.439985217

>TRUNCATEするね… トラウマやめて… うっかりテスト環境のデータいれ直すつもりで本番環境にね…

28 17/07/16(日)10:26:06 No.439985276

>うっかりテスト環境のデータいれ直すつもりで本番環境にね… やったのか「」！

29 17/07/16(日)10:26:13 No.439985300

普通のプログラムでもオアオアオア～ってなるより list.contains(a)みたいにやったほうがきれいだもんなー

30 17/07/16(日)10:26:20 No.439985318

いわゆる共通テーブル式が使えるか使えないかで自由度が大幅に変わる 具体的には頼むからMySQLははよ実装してくれ

31 17/07/16(日)10:26:20 No.439985319

With便利だよね

32 17/07/16(日)10:26:36 No.439985363

なんか新人がデータベース適当にいじってた エクセル見たいなもんすよね！って 大事になった

33 17/07/16(日)10:26:52 No.439985416

(+)超便利だと思うんだけどなんで流行らないん？

34 17/07/16(日)10:27:12 No.439985474

>(+)超便利だと思うんだけどなんで流行らないん？ 実質流行ってる！

35 17/07/16(日)10:27:36 No.439985551

SELECT A.HAGE FROM 「」 A WHERE EXISTS (SELECT * FROM NU B WHERE A.CIAO = B.CIAO) って書くと「*使うなって標準化資料に書いてあるだろボケェ」って怒られるのいいよね良くない

36 17/07/16(日)10:27:55 No.439985600

>だって >k.van = '546' Or k.te = '546' Or k.lin = '546' >って書くのバカっぽいじゃない 思うにばかっぽい書き方でも 大事なのはバカでも誰でも一目見て意味を察することが出来ることでは？

37 17/07/16(日)10:28:57 No.439985772

>大事になった accessでやったのか…

38 17/07/16(日)10:29:03 No.439985787

実質超はやってるけど 標準の書式じゃないから移植性というアレがソレで 業務システムだとインフラの移植することあるのか謎だけど

39 17/07/16(日)10:29:05 No.439985795

B.*でいいんじゃね

40 17/07/16(日)10:29:54 No.439985909

>やったのか「」！ ちょっと一部上場の仕訳テーブルを飛ばしましてね… うn兆円の取引データがですね…

41 17/07/16(日)10:30:32 No.439986010

読み易さなんか些細なこと イチバン重視しないといけないのはoptimizerに最適な問い合わせをしてもらえるクエリを書くことだよ Hint句バリバリ決め打ちでレイプしてもいい

42 17/07/16(日)10:30:43 No.439986043

>って書くと「*使うなって標準化資料に書いてあるだろボケェ」って怒られるのいいよね良くない existsの中のselect項目は1とか'X'とか適当な固定値にしとくのがセオリーで *だと内部処理でテーブルの全項目取得する分ちょっと遅いと実しやかに囁かれている

43 17/07/16(日)10:31:02 No.439986085

>うn兆円の取引データがですね… 本番ならバックアップあるからへーきへーき 当日のお客様業務は1からやり直しだけど

44 17/07/16(日)10:31:29 No.439986152

よっぽど複雑怪奇な条件でないなら単テーブルアクセスごときにＳＱＬ文を書かなければいけないというのはおかしいと思ってほしい

45 17/07/16(日)10:32:04 No.439986249

>思うにばかっぽい書き方でも >大事なのはバカでも誰でも一目見て意味を察することが出来ることでは？ インデックス使えなさそうな事の方が問題だと思う 最近のオプティマイザはそれでもうまいことしてくれるのかもしれんが

46 17/07/16(日)10:32:20 No.439986293

結合条件がwhere句に来るのが嫌

47 17/07/16(日)10:32:21 No.439986298

countとか下手に実数や列指定するより*で書いた方が 今どきのRDBMSの実装だとハイハイカウントカウントねでよしなに処理してくれるから速かったりする

48 17/07/16(日)10:32:37 No.439986325

オプティマイザが優秀ならSQLなんて適当でいいんだよ 死んだ

49 17/07/16(日)10:32:41 No.439986330

>SQLの勉強の前にデータの正規化について義務教育化すべきだよ メモ機能追加したいって言ったら今のレコード数*メモの領域拡張が必要です!とか言われて諦めたらしい うちの会社はベンダーのおもちゃだと思う

50 17/07/16(日)10:32:46 No.439986342

>*だと内部処理でテーブルの全項目取得する分ちょっと遅いと実しやかに囁かれている そういう理屈ではなく単に*を使ってデータ全消しした前歴があるから使うなってだけだと思う

51 17/07/16(日)10:33:10 No.439986404

久しぶりに書いたらIndex効かない条件忘れててｸｿｧってなる

52 17/07/16(日)10:33:34 No.439986475

基本的にはEntityFrameworkがSQL勝手に実行してくれるから楽だけど 使い方気をつけないと糞遅いSQL吐き出すから注意してね

53 17/07/16(日)10:33:38 No.439986484

別名つけないと怒られる…

54 17/07/16(日)10:33:49 No.439986513

わかったインデックスいっぱいつけよう！

55 17/07/16(日)10:33:50 No.439986518

>existsの中のselect項目は1とか'X'とか適当な固定値にしとくのがセオリーで >*だと内部処理でテーブルの全項目取得する分ちょっと遅いと実しやかに囁かれている 今日日のRDBMSでそんなクソタコな実行する奴ないだろ まぁAccessというかJETはタコだったが

56 17/07/16(日)10:34:09 No.439986571

集計ぬく時にスパッとしたの書けると非常に気持ちいい

57 17/07/16(日)10:34:32 No.439986641

Explainの見方よくわかんにゃい

58 17/07/16(日)10:34:42 No.439986661

>わかったインデックスいっぱいつけよう！ 遅い……

59 17/07/16(日)10:34:46 No.439986675

ずらり並んだorとinはSQLが何かしらの内部表現にパースされたときに同じものとして評価されてると思いたい Pervasiveみたいなド古いDBでSQLによる問い合わせが後付けされたものだとそんなことしてないかもしれない

60 17/07/16(日)10:35:46 No.439986861

古いデータは別テーブルに移さずパーティション切ればいいのだ

61 17/07/16(日)10:36:12 No.439986928

>結合条件がwhere句に来るのが嫌 個人的にJOIN使わない奴はクソだと思っている ついでに(+)使う奴は高確率で空文字とNULLを同一視してるから嫌い

62 17/07/16(日)10:36:17 No.439986942

mysqlのオプティマイザそんなに賢くないしね クセがある

63 17/07/16(日)10:36:33 No.439987000

インデックス君についてよくわからない人は多い

64 17/07/16(日)10:36:33 No.439987003

配列型いいよね…

65 17/07/16(日)10:36:40 No.439987025

>オプティマイザが優秀ならSQLなんて適当でいいんだよ >死んだ DB2でoptimizerが優秀すぎて途中から実行計画が変わって性能が劣化したときがあって参ったな… データ量だけでなく何か特定のパターンの問い合わせが多いとそれに最適化してきやがるの かしこいね

66 17/07/16(日)10:37:33 No.439987166

SQL2008の機能ゴールド持ちでも知らない どうなってんの

67 17/07/16(日)10:38:23 No.439987304

>countとか下手に実数や列指定するより*で書いた方が BIみたいな集計関係をやらされてるとcount(*)とcount(col1)ってのが物凄く重要な意味を持ってくるんでやるなとか言ってるのに付き合ってられない

68 17/07/16(日)10:38:47 No.439987372

最近なにかもうSQL自体がレガシー扱いで物足りない with句が入ったときのあの1テーブル1回の問い合わせで バシッとツリー構造表現できたときぐらいのアハ感が欲しい

69 17/07/16(日)10:39:10 No.439987436

いやじゃ… 仕事の話なぞしとうない…

70 17/07/16(日)10:39:50 No.439987525

オプティマイザなんてバカでいいんだよ データがどう変わろうがこっちが指定したインデックスを使い続けてればいいんだ

71 17/07/16(日)10:40:10 No.439987586

やめろやめろせっかくのきゅうじつにやめたかいしゃのぎょうむのはなしなどききたくない

72 17/07/16(日)10:40:38 No.439987655

>ついでに(+)使う奴は高確率で空文字とNULLを同一視してるから嫌い ORACLEのVARCHARいいよね良くない

73 17/07/16(日)10:41:06 No.439987748

COUNTで*と列指定が同じ意味になるのはNULLを含まない時だけだからなぁ 逆に純純粋なレコード数カウント時に適当な列いれてたりするのは…すぞってなる

74 17/07/16(日)10:41:35 No.439987825

Oracle様の仕様は絶対だ 口を慎め

75 17/07/16(日)10:41:55 No.439987877

IS NULL入れないと結果かわるのいいよね

76 17/07/16(日)10:41:55 No.439987878

胃が痛くなってきた…

77 17/07/16(日)10:42:44 No.439988037

SQLServerの仕様の自由奔放ぶりはすがすがしさすら感じる

78 17/07/16(日)10:42:45 No.439988042

最近入り口に触れたばかりだから色々分かってくるのが楽しいけど深淵に触れるとおかしくなっちゃうのか…

79 17/07/16(日)10:42:47 No.439988046

ストアドであらゆる計算してるシステム保守してるけど辛い

80 17/07/16(日)10:43:06 No.439988088

>>大事なのはバカでも誰でも一目見て意味を察することが出来ることでは？ >インデックス使えなさそうな事の方が問題だと思う そういうこと気にするならテーブル設計間違えてるってことなんでそっちのほうが問題

81 17/07/16(日)10:43:27 No.439988158

>データがどう変わろうがこっちが指定したインデックスを使い続けてればいいんだ 本当はデータ入ってるのに自動収集した0件統計使ってSQL動くのいいよね よくない

82 17/07/16(日)10:43:38 No.439988183

いいや君にはよく分からない動きをするトリガー群もメンテナンスしてもらう

83 17/07/16(日)10:44:13 No.439988305

>いいや君にはよく分からない動きをするトリガー群もメンテナンスしてもらう おぅふぁっく…

84 17/07/16(日)10:44:30 No.439988359

へちょい設計を後付けでカバーしてくれるマテリアライズドビューみたいな仕組みがMySQLくんにも欲しい…

85 17/07/16(日)10:45:06 No.439988462

なんか入れ子になっててよくわからないPL/SQLも頼むね

86 17/07/16(日)10:46:07 No.439988645

せっかくDBスペシャリスト取ったのにDB使わない業務に異動になってしまった

87 17/07/16(日)10:46:09 No.439988654

>Oracle様の仕様は絶対だ >口を慎め 空文字とNULLの件ならOracleですらもういつやめてもおかしくないから非推奨つってるかんな！

88 17/07/16(日)10:46:45 No.439988777

今時のシーケンシャル読み込みが速いストレージだと バカチョンにsumるだけの問い合わせとか パーティショニング綺麗にしてたらindex使わない方が速いのかなぁ

89 17/07/16(日)10:47:06 No.439988848

SQLに関しては難解であったとしてもパフォーマンスが出ればそちらの方がいい…

90 17/07/16(日)10:47:08 No.439988856

宣言的なクエリとかよくわかんないからカーソルでぶん回すね…

91 17/07/16(日)10:47:44 No.439988942

いやじゃ…こんなクエリなぞメンテしとうない…

92 17/07/16(日)10:48:23 No.439989052

>>TRUNCATEするね… >トラウマやめて… >うっかりテスト環境のデータいれ直すつもりで本番環境にね… これ数回やった同僚がいたわ

93 17/07/16(日)10:48:27 No.439989061

>SQLに関しては難解であったとしてもパフォーマンスが出ればそちらの方がいい… パフォーマンス必要なところ以外はやめてくだち

94 17/07/16(日)10:48:37 No.439989094

sqlなんてプログラムの方と構造が一致してないレガシーだから代替物が出てきてほしい

95 17/07/16(日)10:48:52 No.439989158

なんで三連休の中日に苦行してるんだよ！？

96 17/07/16(日)10:48:56 No.439989172

>これ数回やった同僚がいたわ なそ にん

97 17/07/16(日)10:49:06 No.439989199

保守性と書きやすさと速度のトレードオフ

98 17/07/16(日)10:49:21 No.439989248

start with やらleadやらあの辺の有効活用ができない

99 17/07/16(日)10:49:24 No.439989256

>ストアド ある条件ごとに返す項目変えるViewの項目をストアドで実装 ストアドの中では呼ばれる度にカーソル開いて引数と比較していて 「遅いんですけぉ！！！１１１１！」とかやってるの見たときは眩暈がした

100 17/07/16(日)10:49:37 No.439989295

>せっかくDBスペシャリスト取ったのにDB使わない業務に異動になってしまった 正直実務に役立つような試験には思えなかったし惜しむようなもんでもなかろう 次の業務のやつも取ろうぜ

101 17/07/16(日)10:49:48 No.439989326

>sqlなんてプログラムの方と構造が一致してないレガシーだから代替物が出てきてほしい むしろコードはsqlのラッパだと考える

102 17/07/16(日)10:49:55 No.439989343

(+)ってなに?

103 17/07/16(日)10:50:01 No.439989365

>最近入り口に触れたばかりだから色々分かってくるのが楽しいけど深淵に触れるとおかしくなっちゃうのか… チョコっと違うだけで計算量がO(n)なのがO(n^2)になったりO(n^n)になってりするし 時間かけた挙句そもそも使い物にならないデータ引っ張ったりすることになるしで つらいつらい

104 17/07/16(日)10:50:47 No.439989508

OracleDBのアホなインデックスの参照見てからwhere句長いSQL文見るたびにヒント足したくなる

105 17/07/16(日)10:50:55 No.439989534

>正直実務に役立つような試験には思えなかったし惜しむようなもんでもなかろう 正規化を問う問題多いしかなり実務で役立つと思うが

106 17/07/16(日)10:51:34 No.439989671

>(+)ってなに? Oracle方言の外部結合 fromにleft outer joinで書くんじゃなくて whereに書くやつ

107 17/07/16(日)10:51:34 No.439989672

そうは言うがSQLやめたらきっとISAMん頃みたいに プログラミング言語でそのまま問い合わせ書くことになるぞ… 今でもNoSQLやらMapReduceでガラガラポンする類とかそんな気があるが

108 17/07/16(日)10:52:02 No.439989753

>sqlなんてプログラムの方と構造が一致してないレガシーだから代替物が出てきてほしい むしろ最近は宣言的な奴はやってきてるじゃないか LINQとか考え方は高階なSQLみたいなもんなのに型安全で最高だぞ

109 17/07/16(日)10:53:38 No.439990048

テーブル結合をwhereとjoin両方使ってるクエリとかなんで…？ってなる

110 17/07/16(日)10:53:50 No.439990088

十年ちょっと前はXML DBとXQueryの時代が来ると思ってた

111 17/07/16(日)10:54:45 No.439990265

>テーブル結合をwhereとjoin両方使ってるクエリとかなんで…？ってなる JOINに条件式一個しかかけないと勘違いしてるとか

112 17/07/16(日)10:54:52 No.439990281

人類に最も必要なのは(人間から見て)関係無い既存行を再計算しないalter table

113 17/07/16(日)10:55:06 No.439990326

leadは便利だよエクセルでよくやる後行との比較ができるよ

114 17/07/16(日)10:56:26 No.439990587

書き込みをした人によって削除されました

115 17/07/16(日)10:56:49 No.439990646

' OR 1=1

116 17/07/16(日)10:56:53 No.439990657

>テーブル結合をwhereとjoin両方使ってるクエリとかなんで…？ってなる whereじゃそこでjoinしたいテーブルにキーがないと結果に出てこなからそこで困るんだろ

117 17/07/16(日)10:58:10 No.439990869

同一キーのテーブルは一つのテーブルに統一するのが正規化の基本だけど それだとNULL値の多い列が多くなって来ない？

118 17/07/16(日)10:58:27 No.439990917

>leadは便利だよエクセルでよくやる後行との比較ができるよ ウィンドウ関数のrows betweenで十分な気がする

119 17/07/16(日)10:59:57 No.439991159

>同一キーのテーブルは一つのテーブルに統一するのが正規化の基本だけど そうだっけ？

120 17/07/16(日)11:01:10 No.439991363

トランザクションで整合性持たせるじゃん？ ロックかかるじゃん リードできないじゃん…どうすればいいの

121 17/07/16(日)11:01:12 No.439991371

>同一キーのテーブルは一つのテーブルに統一するのが正規化の基本だけど お仕事ではそうかもしれないけど理想の話ならもっと細かくしちゃう

122 17/07/16(日)11:01:52 No.439991481

Foreign Key は設定するのが多数派だよね

123 17/07/16(日)11:01:59 No.439991499

>トランザクションで整合性持たせるじゃん？ >ロックかかるじゃん >リードできないじゃん…どうすればいいの ロックされてるなら待てばいいじゃん？

124 17/07/16(日)11:03:01 No.439991668

>Foreign Key は設定するのが多数派だよね 面倒のもとだから設定しないなぁ

125 17/07/16(日)11:03:02 No.439991676

>お仕事ではそうかもしれないけど理想の話ならもっと細かくしちゃう だよね 品目マスターとか列めっちゃ多くなるしNULL多くなる

126 17/07/16(日)11:03:24 No.439991754

FKがあると客がコンプライアンス的に不味い手修正をすることができないからダメだ

127 17/07/16(日)11:03:35 No.439991794

>同一キーのテーブルは一つのテーブルに統一するのが正規化の基本だけど >それだとNULL値の多い列が多くなって来ない？ 正規化ってそういう意味じゃないというか 第6正規形までいけばNULL自体が原理的に存在しないぞ、実用には耐えんが

128 17/07/16(日)11:03:47 No.439991835

>ロックされてるなら待てばいいじゃん？ めっちゃ遅いんですけお！

129 17/07/16(日)11:04:09 No.439991911

それが正しいDBの姿じゃ

130 17/07/16(日)11:04:11 No.439991923

わかんねえ…もう1列ん中にカンマ区切りで入れちまえ…

131 17/07/16(日)11:05:20 No.439992140

10年前にSQLアンチパターンみたいな本があれば あんなことやこんなことを防げて俺は定時で帰れたはずだった

132 17/07/16(日)11:05:21 No.439992141

>わかんねえ…もう1列ん中にSQL入れちまえ…

133 17/07/16(日)11:05:26 No.439992160

select * from table1 A inner join table 2 B ON A.key = B.keykey inner join table 3 C ON A.subKey = C.subKey inner join table 4 D ON B.subSubKey = D.Key AND D.subKey = A.Key inner join....

134 17/07/16(日)11:05:31 No.439992184

>第6正規形までいけばNULL自体が原理的に存在しないぞ、実用には耐えんが データが存在しないからってことか？ どうせ結合して取ってきたらNULLで返ってくるんだから素直に項目入れてほしいわ

135 17/07/16(日)11:06:34 No.439992371

NULLだけは絶対に許さない 全てのカラムにNOTNULLを付けさせてもらう

136 17/07/16(日)11:07:16 No.439992514

理想的なDB設計で実装して パフォーマンス問題はインフラ担当に何とかして貰おう

137 17/07/16(日)11:07:59 No.439992644

ディスク全部SSDにしてもらおう

138 17/07/16(日)11:08:00 No.439992646

>データが存在しないからってことか？ >どうせ結合して取ってきたらNULLで返ってくるんだから素直に項目入れてほしいわ じゃなくて、データが存在しないことをレコードの有無自体で表現できるところまでやるのが6なんだよ 外部結合して非正規化したら当然NULLになる