Microsoft SQL Server 総合スレ 11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Microsoft SQL Server (Transact-SQL) の総合スレッドです。
・Microsoft 公式サイト
http://www.microsoft.com/japan/sql/
過去スレとかめんどいから誰か適当に貼って >>694
そういうJOINの使い方は悪手だよ
NOT EXISTSを使おう exists は確かにわかりやすい記述だけど遅い
大量のデータで使うとサーバーが唸る
できるならinner joinでやったほうがいい
http://kkoudev.github.io/blog/2013/09/14/sql/ >>696
NOT EXISTSをINNER JOINにするのは無理だし
MySQLはNested Loopしか使えないからね
他の一般的RDBとは事情が違うよ >>695
NOT EXISTSのほうがパフォーマンスいいことのほうが多いけど
LEFT JOINが悪手ってわけでもないと思うけどな
少なくとも質問者はLEFT JOINを理解してない風なので
そっちからはじめたほうがいい みなさまありがとうございます。
LEFT JOINでできるとは思いませんでした…頭が硬いですね。
教えていただいたNOT EXISTSも調べたところまさにやりたいことでした。
何とかなりそうです。
ありがとうございました。 >>695
環境、データ、インデックスとかによって違うからお前さんみたいに盲信してるのが一番ヤバイ 経験上LEFT JOIN でIS NULLのほうが速い場合がほとんど >>692さんみたいな書き方を良くするんですが、これは遅いのですか? あっ、ただ自分の場合は
「WHERE NOT 顧客ID IN (SELECT 顧客ID FROM 売上テーブル)」
ではなく
「WHERE 顧客ID NOT IN (SELECT 顧客ID FROM 売上テーブル)」
と書きます。 売上げテーブルに顧客IDでインデックス貼ってあればそんなに遅くない気もする 692は自分だけど、後でみなさん言われるとおり
SELECT * FROM 顧客テーブル
WHERE NOT EXISTS (SELECT TOP 1 FROM 売上テーブル WHERE 顧客ID=顧客テーブル.顧客ID)
のほうが速そうだな 速いとか遅いとか気にしたいんならDBが適切にメンテされているかを考えるべきやな
SQLの表記のゆれなど考えるだけ無意味 NOT INの場合はパフォーマンス以前に
顧客IDがNOT NULLじゃないと意図した結果が得られない可能性がある
NOT NULLなら意図した結果が得られるけど、速度はDBの最適化に依存
INの最適化レベルが高いDBならNOT EXISTSと同程度の速度に場合もある
でもそうならない場合もあるからこういうケースでは基本使わない >>700
環境、データ、インデックスとかによって違うからお前さんみたいに
テストした環境でLEFT JOINが速いからLEFT JOINにしてしまう奴が一番ヤバイ >>710
うまい返ししたつもりなんだろうけどアホ晒してるだけやぞww >>711
普通に答えただけだけどうまかったか?w
マジかwセンスあんな俺www 単純なnot inならouter joinと同じ実行計画吐いたきがする >>714
だからたまたまその時その環境でそういう実行プランが作られたという経験を
後生大事に今生の知識として胸にしまいこんでも無駄だと言っておろうが
SQLはいつだってよりシンプルにより直接的にやりたい事を表現してる様に書くべきなんや >>712
誰もうまい返しとは言ってないぞ
日本語の理解力もないとな w >>716
は?こっちこそお前がうまい返しと言ったとは言っとらんが???
異次元の理解力だなお前…
というかアスペだなwww >>717
> というかアスペだなwww
自己紹介乙w 5chはROM専みたいな筆不精は、長文が書かれていると、時間をかけて書いていると思い込む。
世の中、超速で読み書きができる人間がいるのだよ。 仕事でやってるなら仕事が異常に速いひとを知ってるはずだけどな。並の人間の20倍、30倍くらい仕事が速い人もいる。 1.5人月で見積もられた仕事を1日で片付ける人か。
さすがにそれは見たことないわw >>726
そんな思考だから仕事遅いんだよ
できる人できない人の違いすら理解できてない 仮に1.5人月のコードを5000行とすると
1日でそれ書いて、さらに仕様書とかも書いてテストもするんやで?
めちゃくちゃ打つの速いやん >>731
何で考えても書く行数は変わらんのだけどw 無能な働き者の手による大量の無駄なコードは有能な怠け者の手による洗練された短いコードに劣る >>732
724が言ってるような並の人間より仕事が20倍30倍速いやつってのは
並の人間が5000行書かないと実現出来ない処理を200行程度書くだけで実現したりできるわけ
キーボードだってできるだけ打たなくていい方法を考える
見積もり時に書く行数がほぼ固定されてるような仕事してるなら
できるだけそこから早く抜け出すことだな >>735
それコードが圧縮されとるだけやんwコードゴルフかw
コードは20倍圧縮されても作業にかかる時間は速くなっとらんでそれwww お前らはどうしてスキルないくせに突飛な主張してマウントとりたがるんや?
俺は笑えるからこうして楽しんどるけど一般的にはみっともないだけやでw どれだけ優秀な人間だろうと、1.5人月で見積もった仕事を1日で片付けたらな
そもそもの見積もりがぼったくりすぎるだけだな メタプログラミングやコードジェネレーションを考えればいいと思うよ
できるやつは無駄を省いて機械に仕事をさせる
Paul GrahamのLispの話と同じ 新進気鋭の「グラフデータベース」って用途が思いつかないな RDBはグラフと相性悪いからな
用途が思いつかないうちは使う必要ない 一昔前の技術で言えば多次元DBと同じようなもん
RDBみたいにあらゆる所で使われる技術ではない グラフデータベース=ビッグデータ()
とか言ってると恥ずかしいよ 間違えて全データ消してしまったんですが
ldf/mdfファイルから消す直前のデータに戻す方法ってありますか? バックアップあるなら戻せばいいじゃん?
リカバリモデルにもよるけど bakファイルがなくてldf/mdfファイルだけの状態です 2017 Expressへ32bit windows7接続出来ますか? ありがとうございました。
WINDOWS認証ですが18456エラーが出ます、あとLOGを見ると明示的に指定されたデータベースを開けませんでした。
とあります、何が悪いのでしょうか?
今までは2005 EXPRESSでした。 何時のVerからかは忘れたが、今はマシン名\インスタンス名の形式で指定してやらんと繋がらない
例えばlocalhost\SQLEXPRESS >>755そうですか?試してみます、ありがとうございました。 >>754
そのエラーコード以外に状態コードが出てるでしょ
それ込みでググればだいたい原因分かるよ
Error: 18456, Severity: 14, State: 38. <―このStateの部分
メッセージから推測するとPermissionに問題ないなら
そのログインに指定されてるDefault Databaseがないんじゃないのかな?
存在するデータベースを指定してみれば切り分けできる SQL Server 2017 Express の localdb のみをインストールし、コマンドプロンプトから
sqllocaldb start MSSQLLocalDB
として開始しようとすると、
「プロシージャ エントリ ポイント BCryptKeyDerivation がダイナミック リンク ライブラリ bcrypt.dll から見つかりませんでした。」
と出て失敗します。
対処方法はありますか? Windows7 64bit です。
SQLServer2017構成マネージャーにも何も出てこないし、
SQL Server Management Studio で (localdb)\MSSQLLocalDB としても接続できず困っています。 >>759 ありがとうございます。
bcrypt.dll ファイル自体は system32 と SysWOW64 のどちらのフォルダにも存在しています。
SQL Server 2017 Express は、そもそも Windows7 はサポート外で、ただし localdb だけならいける、と
いうことなのでやってみたけど、やっぱダメなのか・・
SQL Server Management Studio をちょっと勉強したかったのだが。 >>760
「ただしlocaldbだけなら〜」はどこからの情報なのか >>761
これです→ http://diy-kagu.hatenablog.com/entry/2017/08/09/155801
記事は2016だけど、2017でも大丈夫だろうと。
自分の環境特有の理由かもしれない。
もう少しやってみてダメなら 2017 をアンインストールして 2016 で再度やってみる。
SQLの勉強でなくて、SQL Server Management Studio を勉強したい。 >>763 ありがとうございます。
2017バージョンの localDB と SSMS をアンインストール後、
2014バージョンの localDB と SSMS を入れ、SSMS から接続までできました。
これで SSMS の勉強ができます。 SQL Server 2016 expressで特定のテーブルのアクセスが異常に遅いのですが、何か原因はありますか?
特定のテーブルの情報
・データ50万件 (select count(*)だけで10秒かかる)
・頻繁にインサートしている
・主キーを設定していない
プログラムでDBに接続側がタイムアウトになるくらい何かが起きているようです。 sp_who2 をすると、サーバーに繋ぎに来てるコンピュータ名やプログラム名が見れますが
ドメインユーザー名を取得することできませんか。
SQL認証で、ユーザー/パスを全員共通にしてあるんですけど
各接続SPIDに対するドメインユーザー名が判別できるとありがたいんですが。
Windows認証だったら判別つくのですが、プログラムはSQL認証で使いたいです。
(ユーザーがもし SSMS で繋ぎにきたときにテーブル全開示になっちゃうのを防ぐため) >>765
俺、そのケースで散々パフォーマンスチューニングだのインデックス再構築だの設計変更だのしてたが、
最終的なオチはExpressのデータファイルの10GB制限に引っかかっててインデックス検索で1MB単位で容量の削除、自動拡張を繰り返してた、
というケースがあった。
今でも当時のことを思い出すと赤面するぐらい恥ずかしい思い出。 >>770
インサートで限界を突破して自動拡張が停止
→ロールバックされて容量が元に戻る
→ギリギリ容量が残ってるので自動拡張が…
以下、タイムアウトするまで(あるいは何とか入りきるまで)延々繰り返し
みたいな(ちょっと詳細省いたけど 自動拡張されたデータファイルのサイズはロールバックしても自動的に縮小されたりしなかったと思うんがだが
自動拡張に出来なくて空きがないならエラーで帰ってくるから、タイムアウトまで延々待たされるなんて事も無かったと思うけど SQL Server の参考書でいいやつってどれ?
SQL の文法解説じゃなくて、SQL Server 独特の文化とか、SSMS の操作法とか、そのあたりを学びたい。 >>774
公式DLの自習書シリーズが最強だと思う
ボリュームが多いが参考書臭さがなく実務より >>774
公式DLの自習書シリーズが最強だと思う
ボリュームが多いが参考書臭さがなく実務より >>774
あまりない。そこがSQL Serverの厳しいところ。 >>775 おお! 無料でこんなのあるんだ、ありがとう!
>>777 オラクルよりもマイナーなのかな? >>778
自習書は日本マイクロソフトが日本の会社に作らせたもの。
ただし手抜きや説明の偏り、一部は間違っているが、日本マイクロソフトのサポートの方もこれを参考にしている。
マイクロソフトはどの製品も作りっぱなしでマニュアルは自動翻訳のよくわからないものばかり。
Management StudioについてはどのRDBMSより経験がなくても直感的にわかりやすい。 >>774
SQL Server 2005、2008以降は大きく変わっていないから、特に翔泳社の本は役に立つよ。
最近のSQL Server本は本当に役に立たない。特にマイクロソフト公式本はひどい。
秀和システムの赤い本もひどい。 >>782
>マイクロソフトはどの製品も作りっぱなしでマニュアルは自動翻訳のよくわからないものばかり。 >>783
マイクロソフトのサイトを見たことがないの? M$日本の公式ドキュメントは「これは自動翻訳で生成されました」だらけなんだが
>>785はggrもしないらしい >>787
英語のドキュメント読むに決まってんだろ何言ってんの? >>787
ググった結果英語のドキュメントが出てこない世界に住んでるんだねすごいね 789の世界のgoogleは日本語の結果のみ表示ができないらしい >>792
ユーザーにわからせようとはしてない。外国人は基本的に不親切だから、この説明でわからない方が悪いというスタンス。 自動拡張されたデータを削除してもファイルサイズが大きいままなのですがどうすればサイズを小さくできますか? ■ このスレッドは過去ログ倉庫に格納されています