SQLなら俺に訊け [無断転載禁止]©2ch.net (457ﾚｽ)
上下前次1-新
1: 2017/07/14(金)07:40 ID:HFjsarQi(1) AAS
さあ
331(3): 2024/12/20(金)16:41 ID:cA4MHukG(1) AAS
テーブルごと全てのカラムにまとめて別名付けるとかできないのかな
以下のような場合に別名付けるとき
テーブルA
id
name
description
テーブルB
id
name
description
省11
332: 2024/12/21(土)11:36 ID:KZIgeCwE(1) AAS
うちはそのまま A.name のまま扱ってるよ
333(1): 2024/12/21(土)19:55 ID:IOryZJAZ(1) AAS
>>331
またそのネタかよw
334: 2024/12/21(土)20:43 ID:SDOaO/8s(1) AAS
SQLを出力するプログラム位かけるやろ
335(1): 313 2024/12/23(月)08:20 ID:hrYrd+aN(1) AAS
>>330
クエリ式であってSQLじゃねぇだろ
SQLの語順ならSELECTが最初だ
336: 2024/12/23(月)10:17 ID:xh1kOIEb(1) AAS
>>333
また、って言うくらいには結構求められている機能だと思う
337: 2024/12/23(月)18:35 ID:GjEN+y4a(1) AAS
>>329
LINQはそもそも.NETのコードの物だから
メソッドチェーンで書く時の順番がそのままになってるだけよ
HogeList.Where().Select()って書き方になるからクエリ式もそうなる。
338(2): 2024/12/24(火)09:46 ID:MemH7BuO(1) AAS
>>331
すべてのカラムに最初からそういう名前をつけているよ
テーブルA
A_id
A_name
A_description
テーブルB
B_id
B_name
B_description
省9
339: 2024/12/24(火)12:30 ID:V4/fVU02(1) AAS
>338
>331を読むに、別名（エイリアス）でテーブル名付けたいって事でしょ
確かに長ったらしいテーブル名は一括で一文字のエイリアス名を付けたいな…の思う事もあるから>338の言わんとしてることも分かる
340: 2024/12/24(火)22:39 ID:S4CkJ4V1(1/2) AAS
>>335
標示SQLではSELECTよりもWITHが先
341(1): 2024/12/24(火)22:40 ID:S4CkJ4V1(2/2) AAS
>>338
同じカラム名なのに意味が異なるという狂った設計なのが間違い
342(1): 2024/12/25(水)01:30 ID:YXgPFPfq(1) AAS
SQLというよりSQL clientの機能の話じゃね？
SELECT a.id, a.name, b.id, b.name FROM foo a INNER JOIN bar b ON …
↑みたいなクエリを書いた時に結果のカラム名が単にid, name, id, nameと表示されるのではなくa.id, a.name, b.id, b.nameと表示されればいいわけでしょ？
プログラムから結果セットにアクセスする時は”a.id”や”b.id”でアクセスするんだから表示調整くらい簡単にできそうだけどな
343(1): 2024/12/25(水)08:15 ID:63Wcp4qk(1/2) AAS
誰もWITHの話なんかしとらんのに突然の主張ｗ
344: 2024/12/25(水)12:26 ID:wfmvBy7R(1) AAS
日本語SQLスズラン
345: 2024/12/25(水)15:26 ID:PDJSnv/I(1) AAS
be with you
346(1): 2024/12/25(水)17:53 ID:YmcCoB80(1/3) AAS
>>343
SELECT句よりも先にWITH句を書くので、SELECT句が先ではない。
347: 2024/12/25(水)17:56 ID:YmcCoB80(2/3) AAS
>>342
根本的に同じカラム名なのに別のカラムという設計がおかしい
どちらかのテーブルにしかないカラムなら、修飾そのものがいらない
それはあんたはSQLの話ではなくて、別の製品の仕様の話をしている
それに同じ名前のカラム名なら別名を定義するべきだ
348: 2024/12/25(水)17:58 ID:YmcCoB80(3/3) AAS
SQLを適当に書く人間が増えて、めちゃくちゃなシステムだらけになった。
同じカラムが、同じカラムがというなら、結合したビューでも用意しとけよw
349(1): 2024/12/25(水)18:33 ID:WXVFxdaX(1/2) AAS
元の話も読めないようなヤツはWITHがどうのと主張しとらんと黙っといた方がいいよｗ
350(1): 2024/12/25(水)18:36 ID:63Wcp4qk(2/2) AAS
>>346
誰もWITHの話なんかしとらんのに突然の主張ｗ
351: 2024/12/25(水)19:42 ID:r1WXKMXg(1/3) AAS
>>350
335 313 sage 2024/12/23(月) 08:20:37.09 ID:hrYrd+aN
>>330
クエリ式であってSQLじゃねぇだろ
SQLの語順ならSELECTが最初だ
352: 2024/12/25(水)19:44 ID:r1WXKMXg(2/3) AAS
>>349
SQLの構文仕様を調べたことがあるのか？
SQLそのものは自然言語の英語の語順になっているだけ
353: 2024/12/25(水)19:47 ID:r1WXKMXg(3/3) AAS
「クエリ式」はSQLの世界の話ではなく、SQLを組み立てる側のライブラリの世界の話。
使われる方が使う方を意識するという発想で設計書を書かせようとする人間がいるが、それだと延々とドキュメントを修正することになる。
世界中の人間に聞いて回ってドキュメントを修正するなど無理だし、無意味。
354(1): 2024/12/25(水)21:03 ID:WXVFxdaX(2/2) AAS
ダメだわこの頭でっかちｗ
355: 2024/12/26(木)13:44 ID:KwPCWpVD(1) AAS
>>341
うれしい副産物として、違うカラム名にできるというメリットもある
356: 2024/12/30(月)02:42 ID:SuC1UiOz(1/2) AAS
>>354
SQLを書きたくないという理由を聞きたい
他人にぶん投げられれば気が済むのか？
357: 2024/12/30(月)02:44 ID:SuC1UiOz(2/2) AAS
なぜ「データベース」板を無視して「プログラム」板に書いているのも謎
358(1): 2024/12/30(月)14:22 ID:y1s4zo7f(1) AAS
SQLなんて一回描いたら何度も描き治すもんでもないからな
面倒臭がるのは怠慢
359(1): 2024/12/30(月)19:29 ID:V3PHz5v0(1) AAS
>>358
なおすでーー
360: 01/01(水)21:42 ID:sxxQrAOo(1) AAS
>>359
そう何度も直すことは無いよ
361: 01/01(水)23:12 ID:21eIb2Fa(1) AAS
へぼかったら治すでーー
362: 01/05(日)10:38 ID:c9RkuEF2(1) AAS
単にテキストエディタの機能を使いこなせずに毎度、すべてキー入力している初心者は案外、多い。
363: 01/05(日)10:48 ID:8kdOFrcZ(1) AAS
ORMなんていらん
364(1): 01/05(日)19:51 ID:ToFXQ1cV(1/2) AAS
サブクエリ難しい
365: 01/05(日)19:52 ID:ToFXQ1cV(2/2) AAS
息をするようにSQLを書きたい
366(1): 01/05(日)20:49 ID:ktpqqLIO(1) AAS
>>364
当該処理がクエリを2回以上発行することを許されてる仕様や環境なら、無理にサブクエリ１発で処理しようとせず2回以上に分けて処理するのも手だよ
サブクエリって見づらいしメンテナンスしづらいし
367(1): 01/05(日)22:36 ID:Gf5gTRAY(1) AAS
CTEのおかげてサブクエリの出番はめっきり少なくなったよね
368: [sega] 01/06(月)12:33 ID:HkxXvSmh(1) AAS
>>367
ＣＴＥってなに？
369(1): 01/06(月)18:37 ID:xyyiC8Hr(1) AAS
>>366
ありがとう
やってみる
逆にそれでサブクエリの感覚が掴めるかもしれないと勝手な期待をしている
accessとExcelVBAでやっているけど、IT素人のPC好きなおじさんがやる
やってるから何分感覚がつかめない
ミックさんのデータベース入門は読んでいるけど読み切れていない
370: 01/06(月)20:05 ID:PWtKQBnB(1) AAS
>>369
そうそう、その視点や観点が本当に大事
プログラム全般そうだけど一気に書こうとするとスパゲティ化して自分でも訳わからなくなるから
必ず最小から始めて、それらをくっ付けて大きくしていくみたいな感覚が大事
371: 01/09(木)00:01 ID:8WDo/TAk(1) AAS
サブクエリは普通に使うだろ
372: 01/11(土)10:22 ID:ouBpeDRU(1) AAS
サブクエリを使うクエリを分解したらたいていN+1になるしな
373: 01/19(日)01:50 ID:IALgBqxE(1) AAS
サブクエリ使う理由ってめんどくさがったり一時領域をケチる以外に理由ないよ
サブクエリを使わずに結果を出すようにした方がメンテもパフォーマンスも上がる
374: 01/19(日)02:17 ID:9/Z57kyd(1) AAS
サブクエリの有無ごときで議論になるの笑ってしまうなw
どんなちっこいアプリなんだ？電卓とか？
375: 01/19(日)06:33 ID:ugzsMDEi(1) AAS
1週間も経って突然貶し始める方が笑ってしまうわ
376: 01/19(日)09:51 ID:pfUoPKo5(1) AAS
どこの句のどういう使い方をするサブクエリなのか書いてくれないと、サブクエリを使うべきなのか、そうでないか答えようがない。
377: 警備員[Lv.1][新芽] 01/19(日)13:34 ID:bMoMF2/G(1) AAS
SQLを複数回に分割して発行すると、その間DBに更新がないことを担保する必要がありますか？
378: 01/19(日)16:06 ID:vo12PcwL(1) AAS
トランザクションを指定すれば？
379: 01/19(日)16:20 ID:MoFiVYUu(1) AAS
そこはSQLを複数回に分割して発行するかどうかよりも上位のレベルで
トランザクションや同時実行制御の観点から設計しておくべき事項
担保する必要性の有無は分割しようがしまいが変わらない
380: 警備員[Lv.4][新芽] 01/19(日)18:28 ID:T6GaQrgY(1/2) AAS
やはりトランザクションですね
ありがとうございます!!
381: 警備員[Lv.4][新芽] 01/19(日)18:29 ID:T6GaQrgY(2/2) AAS
ちなみに、サブクエリとするか分割するかのレスに乗っかって、でした
382: 01/20(月)11:39 ID:7SyPOdKK(1) AAS
サブクエリを使わないで、一旦チンポテーブルに書き出す方式があったよね
あれなんだっけか
383(3): 警備員[Lv.1][新芽] 01/20(月)18:23 ID:O4abJDGp(1/3) AAS
次の3つのフィールドで構成される複合主キーがあり
(PK1, PK2, PK3)
検索キーとしてPK2とPK3だけをよく用いるとき、主キー以外にもインデックス(PK2, PK3)を作成すべきですか？
384: 01/20(月)18:55 ID:kikzz/Vc(1/2) AAS
キーのバラつき具合やオプティマイザの機能にもよるから一概に不要とも作成すべきとも言えない
385: 01/20(月)18:55 ID:kikzz/Vc(2/2) AAS
実際のクエリプランを見て判断
386: 警備員[Lv.3][新芽] 01/20(月)19:12 ID:O4abJDGp(2/3) AAS
ありがとうございます>>383です
ちなみにaccessです
387: 警備員[Lv.3][新芽] 01/20(月)19:14 ID:O4abJDGp(3/3) AAS
>>3々3です
accessで複合主キーを設定したとき、インデックスは自動で付与されるでしょうか
388(1): 01/21(火)08:53 ID:9Kz0tqcV(1) AAS
インデックスじゃない主キーってなんだ……。
389(3): 警備員[Lv.5][新芽] 01/21(火)09:13 ID:X3sBvw4I(1) AAS
>>388
調べてみるとそうみたいなんだけど(主キーにはインデックスが張られる)、単一主キーだと、該当キーにRequired、Uniqueなインデックスが作成されるけど、複合主キーでは個々のフィールドに個別にはインデックスが作成されてなくて
それがどういうことか(インデックスが張られているか)分からなくて
分かりにくくてごめんね
390(1): 01/21(火)11:15 ID:+xYYoS0+(1/2) AAS
>>389
DBの構成上、主キーであれば最低限１つのインデックスは張られる
それはPK1,PK2,PK3全部揃ったときにB木を辿れればいいだけなので、6(=3P3)通りのどれかだが、
何もなければ PK1->PK2->PK3 の1つのインデックスになる
この場合、PK1,PK2 のセットならインデックスが使えるが、今回のように PK2, Pk3 のセットだと使えない
これはクエリプランを見れば判断出来る
SQLiteだとこのケースでは上記の通り
というかCREATE INDEX時(CREATE TABLE時)に使われ方を予測する事は不可能なので、
DBとしては、記述通りPK1->PK2->PK3で一つ作るか、全組み合わせを作っておくかしか出来ない
よく使われる検索に対して自動的にインデックスを作成して高速化してくれるDBがあるのかもしれんが俺は知らん
391: 01/21(火)11:23 ID:+xYYoS0+(2/2) AAS
>>389
> 単一主キーだと、該当キーにRequired、Uniqueなインデックスが作成されるけど、複合主キーでは個々のフィールドに個別にはインデックスが作成されてなくて
これは少し勘違いしてる
インデックスはあくまでB木であって、個々のフィールドやカラムとは全く別物
インデックスが当たってるかは、クエリプランで確認すべき事
392(1): 警備員[Lv.7][新芽] 01/21(火)13:20 ID:j6Q/IyUA(1/4) AAS
>>389です
ありがとうございます
(以下Accessです)
新たにテーブルに、主キー(PK1,PK2,PK3)を作成した段階で数万件のレコードを入れ、仮に(PK1,PK3)をキーとしてSELECTで抽出をするとめちゃくちゃ遅い…(1)
上のテーブルの主キーの個々のフィールド(3つ)にインデックスを設定して(1)と同じ条件の抽出をするとかなり速い…(2)
(2)のインデックスを削除して主キーと同じフィールドに複合インデックスを設定するともっと速い…(3)
(1):(2):(3)=65:1.5:1
くらいの比率でした
主キーを設定しただけではとても遅かったです(65倍)
なにか設定・前提に誤りがあるかもしれません
393(1): 警備員[Lv.7][新芽] 01/21(火)13:21 ID:j6Q/IyUA(2/4) AAS
実行計画の出し方は調べてみます
多分見方が分かりませんがw
394(1): 01/21(火)16:54 ID:c07BxmkO(1) AAS
>>392
(1)で設定した複合主キーと
(3)で設定した複合インデックスとで
インデックスを構成するカラムの順番は本当に同じ？
395: 警備員[Lv.8][新芽] 01/21(火)17:55 ID:j6Q/IyUA(3/4) AAS
>>394
すみません、ちょっと投稿内容に誤りがありました
(1)の複合主キーと、(3)の複合インデックスをまったく同じフィールド、個数、順序とすると、(1)と同じように、複合主キーのみでインデックスを設定しないときの同じように65倍の時間が掛かりました
デフォルトで設定されたインデックスと一致しているので当然なのかもしれません
先ほどの(3)の結果としてを得たのは、試行錯誤して複合インデックスから検索キーとしないフィールドを削除したもので、複合主キーのフィールド数より2つ少ないです
後出しになりすみません
データの内容によっても結果は変わるでしょうし、オレ環なので諦めるしかないかなと
396(1): 警備員[Lv.8][新芽] 01/21(火)18:09 ID:j6Q/IyUA(4/4) AAS
簡単のため、当初複合主キーのフィールド数を3としました
397(1): 01/22(水)00:08 ID:l3OLrM1a(1) AAS
{PK1,PK2,PK3}で複合キーが定義されてる場合
検索条件が{PK1}か{PK1, PK2}か{PK1, PK2, PK3}であればどのDBMSでも大半のケースでインデックスが使われる
検索条件が{PK1, PK3}の場合はPK1のselectivity次第でインデックスが使われるものがある
検索条件が{PK2, PK3}のように一番左のカラムが含まれない場合はindex skip scanという機能が実装されてなければインデックスは使われない(Accessにはたぶん実装されてない)
他のクエリとの兼ね合いで複合主キーを構成するカラムの順序を変更できないということであれば該当クエリ用に複合インデックスを追加するのは妥当
398: 01/22(水)00:28 ID:VcBzYOin(1/7) AAS
>>396
というか何がやりたいのか不明な事になってるが、
> 検索キーとしてPK2とPK3だけをよく用いるとき、主キー以外にもインデックス(PK2, PK3)を作成すべきですか？
であれば遅い(＝インデックスがない)と分かったのだからインデックス作ればいいだけでは
>>393
> 多分見方が分かりませんがw
見方なんて分かる必要なくて、
1. インデックスがある検索に対してクエリプランを出させる(＝インデックス検索)
2. インデックスがない検索に対してクエリプランを出させる（＝リニア探索)
3. 実際に自分がやりたい検索が、1,2のどちらに似てるか見る、特に先頭付近
省5
399(1): 警備員[Lv.3][新芽] 01/22(水)01:45 ID:x9n06qn/(1/2) AAS
>>390
>>397
ありがとうございます
最左のカラムを検索キーとするかがポイントなんですね
当初は>>390での指摘がピンときていませんでした
合間のレスで「仮に(PK1,PK3)で検索し」は迂闊でした
いまは手元に試験用のコードがありませんが、最左のカラムを含んでいなかったと思います
SQLをずいぶん自由に書けるようになったと思っていましたが、テーブル、インデックスの作成がこんなに大切だったと知りました…
400: 01/22(水)01:53 ID:IIgBVdb4(1) AAS
そもそもＡＣＣＥＳＳのクエリプラントとか、取得大変だがな
401: 01/22(水)05:04 ID:xghKhcgN(1) AAS
ACCESSにクエリプランなんてあるん？ｗ
ファイルで配布できる必要があるとかじゃなければ、MS SQL Expressなり使った方がやりやすくない？
昔と違ってGUIツールも今は無料配布になってるし。
402(2): 01/22(水)07:08 ID:VcBzYOin(2/7) AAS
>>399
> 最左のカラムを検索キーとするかがポイントなんですね
違う。というか理由を理解ではなく結果を暗記しようとする辺り、文系馬鹿の匂いがするが、
とにかく、「B木」でググって記事を読め
現在のプログラミングでは基本で、そこそこ初心者が記事を書くネタになってるから、いくらでも出てくる
そしてVBAにもハッシュはあるだろ。ググるとScripting.Dictionaryと出てくるが、中身は同様にB木のはずだから、
何か知らんが速いという事で済まさず、この機会にちゃんと理解しろ
そしてその言い方なら、
左側が全部揃ってるかがポイント
が正解になる
省1
403(1): 警備員[Lv.5][新芽] 01/22(水)09:37 ID:x9n06qn/(2/2) AAS
>>402
ありがとうございます
B木の「B」はBinaryでなくBalanceだったのですね
B木の深さは複合キーの個数で一定となるツリーなんですね
二分木をイメージして「??」でしたが、B木の構造がイメージできればインデックスの効果が得られるか否かが分かりやすいと思いました
404: 01/22(水)10:44 ID:VcBzYOin(3/7) AAS
>>403
> 二分木をイメージして「??」でしたが
いやそういう問題じゃない
というか相変わらずインデックスが何かさっぱり分かってないようだが、単なるリーフへの探索手段だぞ
実際はこんなキーの分け方はあり得ないが、馬鹿でも分かるように敢えて例とすると、
お前が名詞を1,000枚持ってて、あいうえお順に格納して保管してるとする
これは主キーが複合キーの{PK1:苗字1文字目, PK2:苗字2文字目以降, PK3:名前}として、
石破茂を{'石','破','茂'},
岸田文雄を{'岸','田','文雄'}
と格納されてる状態と見なせる
省6
405(3): 警備員[Lv.7][新芽] 01/22(水)10:58 ID:ZVwqoD6m(1/3) AAS
B木については知らなかったが、今回の複合インデックスの件について二分木は論外だとは分かっています
ちなみに、>>402ハッシュの中身がB木というのは自分の認識と異なります
字面でうまく伝わらない部分はあったと思いますが、B木を知ることができ(あえて理解とは言わない)よかったです
ありがとうございました
406: 01/22(水)11:07 ID:s+SsM2Gu(1) AAS
中途半端な知識で間違ったことばっかり書いてるのに
人を馬鹿する自称バカではない理系おじさんは少し自重したほうがいい
407(1): 警備員[Lv.7][新芽] 01/22(水)11:27 ID:ZVwqoD6m(2/3) AAS
>>405
x ハッシュの中身が
o Scripting.Dictionaryの中身が
文脈から分かったかもしれませんが
408: 01/22(水)11:27 ID:VcBzYOin(4/7) AAS
>>405
> 今回の複合インデックスの件について二分木は論外だとは分かっています
いやそうじゃねえ
そもそも論外でもないし、インデックスが二分木でも問題ないし、この場合には二分木もB木の一種だよ
B木とは深さ方向が一定になるように調節されてるものの呼称であり、実際は二分木が多数だろうし
まあ君に理解する気がないのは分かったし、実際に理解しなくても済む人達も大勢居るのも事実
ただプログラマならどのみちいつか引っかかるから、この機会にちゃんと理解しといた方が得だぞという話
君がどうするかは君が決める事
409(1): 01/22(水)11:42 ID:a9tNcWhf(1) AAS
>B木とは深さ方向が一定になるように調節されてるものの呼称であり、実際は二分木が多数だろうし
君が論外
410(1): 01/22(水)12:42 ID:VcBzYOin(5/7) AAS
>>407,409
そうじゃない、というかそこは問題ではない
というのが分からないのが問題なのだろうが、君は全てを「具象」で捉えて「暗記」してるだけだろ、これは典型的な文系のやり方
本来は「抽象」で捉えて「理解」しないといけない項目
「B木」も「二分木」も(昔ながらのハッシュ関数を使った)「ハッシュ」も別物ではなくて、
同一の物を分類してるだけ、しかも直交もしてない
話を戻すと、問題は、
・DBのインデックス動作が分からない
・どうインデックスが作成されるかも分からないし、
・どういうクエリならインデックスが使われるのかも分からない
省16
411: 01/22(水)12:49 ID:VcBzYOin(6/7) AAS
>>410訂正
× 同一の物
○ 同種の物
無駄に絡まれそうなので念のため
まあ俺がどう論外である事を証明したところで、
君がインデックスを理解する事には繋がらないよ
君は努力の方向を間違ってる
(ネットにはこのタイプも多いけども)
412: 01/22(水)13:23 ID:0peR6PAs(1) AAS
どんなにアスペな言い訳しようが君がバカだという事実に変わりはないよ
413(1): 警備員[Lv.8][新芽] 01/22(水)13:46 ID:ZVwqoD6m(3/3) AAS
>>405です
途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
また、複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました
理解不足は否めませんが、実用上問題がないレベルとなったので、これでよしとします
ありがとうございました
414: 01/22(水)18:46 ID:VcBzYOin(7/7) AAS
>>413
> 複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました
当たり前、というかDBの使い方の初段階で説明/理解すべき事柄
> 途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
> と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
そうじゃない
ひととおり設計を理解した上で弄くり回して理解を深めるのなら身に付くが、
今の君のように、何も理解してない状態で試行錯誤したところで時間の無駄でしかないよ
(それよりは記事を漁って理解するまで何度も読み込む努力をした方が何倍もいい)
とはいえ、現実問題としてaccessの実アプリの方が優先なのは分かる
省13
415: 01/22(水)21:30 ID:o3lkJXbH(1) AAS
おっさん、文章が長いな。もっと簡潔に書きなさい。あなたの文章にインデックス貼ってクエリもチューニングした方が良いぞ
416: 01/22(水)23:15 ID:J/9pPL5e(1/2) AAS
絵に書いたような老害だなｗ
417: 01/22(水)23:17 ID:J/9pPL5e(2/2) AAS
ありゃ「描いた」だぞと老害に指摘されそうだなｗ
418: 01/22(水)23:29 ID:I1bb5L41(1) AAS
老害でも技術力があれば匿名掲示板では役立つけどどう見てもないから救いようがない
絶対干されてるタイプ
419: 01/23(木)19:03 ID:0iiPrNry(1) AAS
どうでもいいけど、制約とインデックスを同一として扱ってるのがモヤるわ
ユニーク制約と主キー制約をインデックスで処理しないＤＢＭＳはみたことないとしても
420: 01/23(木)19:56 ID:hJ60cV1T(1) AAS
お前の方が色々混同してそうだが
421: 警備員[Lv.1][新芽] 01/23(木)23:23 ID:5wOSbPSv(1) AAS
さ…さすが〜!
し…知らなかった〜!
す…すごーい!
せ…センスい〜ぃ!
そ…そうなんだ〜!
(「合コンさしすせそ」より)
422: 01/23(木)23:29 ID:rNgwBkvb(1) AAS
制約の話で思い出したがAccessの場合は
foreign key制約を設定すればインデックスが自動で出来たはず
(PK1, PK2, PK3)で構成される複合主キーがあって
検索キーとして(PK2, PK3)を利用したいということなら
PK1と(PK2, PK3)は違う親テーブルから主キーを引き継いでるんだろうから
そこにインデックスを張らないという選択はほぼ無いな
423: 01/24(金)04:28 ID:agkokgy5(1) AAS
383以降を見る限り、そんな高級な話ではなく、まるっきり分かってなかっただけだろ
そして(PK2,PK3,PK1)と出来なかった理由の推定なら、そこは(PK1,PK2)とPK3とくくるべき
424: 01/24(金)11:19 ID:SzuokRLj(1) AAS
分かってないのになぜ無理して絡もうとするのが
425(4): 02/03(月)18:36 ID:hEyRnoXc(1) AAS
PostgreSQLを使っているのですが、
更新前のデータも参照したいので、
更新処理を、元のデータに変更を加えたデータを追記し、更新元のデータに最新ではないフラグを付ける形でやっています。
新しくカラムを追加したのですが、更新処理の変更を忘れて、更新すると新しいカラムがデフォルト値に戻されてしまうバグを作ってしまいました。
既存の行をコピーして、primary keyと変更したいカラムだけ変更する方法ってありませんか？
426: 02/03(月)23:14 ID:k1KW9LUA(1) AAS
>>425
>既存の行をコピーして、primary keyと変更したいカラムだけ変更する方法ってありませんか？
この質問はバグにより作成されたデータの復旧作業方法として質問してる？
それとも一般的にそういう方法ないかということ？
あるいはカラム追加やカラム名の変更があっても更新処理のSQLを修正しなくてもいいようにする方法を聞いてる？
>更新前のデータも参照したいので、
ここで言いってる”参照”は外部キーとして他のテーブルから参照するという意味？
それとも単に更新履歴が閲覧できればいいという意味？
427: 02/06(木)00:29 ID:4njYbkok(1) AAS
>>425
あるよ
selectしたものを使ってupdateすればいい
428: 02/07(金)21:07 ID:lNWVt+S0(1/2) AAS
>>425
トリガーというものがあります
429: 02/07(金)21:08 ID:lNWVt+S0(2/2) AAS
>>425
外部ﾘﾝｸ[html]:www.postgresql.jp
430: 02/07(金)22:21 ID:mS2jfvem(1) AAS
むしろトリガーの変更を忘れてバグったんじゃないの？
431(1): 02/07(金)23:13 ID:El81lTJA(1) AAS
> PostgreSQLでは、トリガ動作として、ユーザ定義関数の実行しか認めていません。
> 標準では、多数の他のSQLコマンドを実行させることができます。
> 例えば、トリガ動作としてCREATE TABLEを実行させることも可能です。
> この制限を回避する方法は簡単です。必要なコマンドを実行するユーザ定義関数を作成すればよいのです。
糞仕様杉ワロタ
432: 02/08(土)11:50 ID:+3qBIV3v(1) AAS
> この制限を回避する方法は簡単です。必要なコマンドを実行するユーザ定義関数を作成すればよいのです。
この方針は正しいと思うけどな
こういうセキュリティに敏感な場所は出入口を一ヶ所に絞るのは基本だよ
433: 02/08(土)12:46 ID:3VVdck+P(1) AAS
いや色々おかしいよお前、多分DB板出身だろうから帰れ
逆に質問者もDB屋ならDB板の方が合ってるとも思うが
434(1): 02/08(土)13:11 ID:fsW85FYF(1) AAS
正しいわけないだろｗ
Postgresの仕組み的に関数化が必要なら内部的にラップしとけばいいだけ
実行権限をトリガに対して設定できないとか非標準を維持し続けるほど大した意味はない
435: 02/09(日)03:19 ID:BAiRqfzU(1) AAS
ここの人らはNoSQLはどういう扱いなの
436(1): 02/09(日)12:18 ID:kD9FDD3o(1) AAS
俺個人としては同じDB枠の扱い
プライマリキーやインデックス等、DBとしての使い方は同じで、
それを設定する言語が、SQLか、或いは一般プログラミング言語か、という程度だから
だからこのスレも俺には「DBなら俺に訊け」でもいいんだが、このスレはテンプレないんだな
俺が主流派かどうかは分からない
SQLじゃないとヤダ、って奴が多ければスレを分けるべきだろうが、
正直分けるほど人いないし、NoSQLもここで聞いていいのでは？答える奴が居るかは知らんが
ただ、383も425も、SQLではなく、DBを分かってないから話がおかしくなってるので、
実質SQLではなくDBの質問になってるし、NoSQLでも結果的に同じだと思うよ
個別DBに特化した話等なら、DB板に行った方がいい
省3
437: 02/09(日)18:18 ID:qhqoX22r(1/2) AAS
>>431
トリガーそのものにロジックは必要ないとしてトリガーを仕様に取り込んだせいでそうなっただけ
438: 02/09(日)18:19 ID:qhqoX22r(2/2) AAS
>>434
Oracle以外はあとからOracleDBに追従したから、元のクソ仕様のせいで制限がたくさんある。
439: 02/09(日)18:31 ID:mMq7ancL(1) AAS
出た！
DB板の荒らし
通称ボラクル君w
440: 02/09(日)22:11 ID:uTje1YE2(1) AAS
>>436
おまえ>>383のやり取りで嘘ばっか書いてたやつじゃん
反省したのか？
441: 02/09(日)22:42 ID:JhqniwEL(1) AAS
ならお前が正しいと思うことを書けばよいだけでは？
442: 02/10(月)00:33 ID:VZ2XQokR(1) AAS
nosqlは独自に覚えなきゃいけないことが多すぎるうえに制約も多い
awsとazureで同じ設計が通じるわけでもないし
443: 02/10(月)11:53 ID:Z13/KCo3(1) AAS
KVSですね判ります
444: 02/10(月)12:41 ID:y2n5AJNm(1) AAS
ベンダー違っても中身は全部Redisという場合もあるし単純なセッション管理にKVSを使うとかならベンダー違っても基本的に同じ設計になるしユースケース次第でいろいろ
NoSQLって言うだけだとリレーショナルじゃないくらいの意味しかなくて広すぎるから細かい話は一括りにはできない
445(2): 05/11(日)23:41 ID:SmeYoeAy(1) AAS
ミックさんの達人SQLは名著だと思うんだけど、関係が体であるとしている点については、群ですらないというamazonレビューの指摘の方が正しいように思うんだよね。ただ自分は文系で群とかちゃんと勉強したことないのであまり自信はない。数学できる人教えて。
446: 05/12(月)19:12 ID:RxQ7/dSc(1) AAS
>>445
集合は数学とは違うよ
447: 05/13(火)14:41 ID:C/NhftFY(1) AAS
SQLで無限集合出来んかな
448: 05/14(水)00:52 ID:qxlPxgMn(1) AAS
なんで havingとwhereは使い分ける必要があるの？
全部whereで済むように仕様を直してほしい
449: 05/14(水)01:47 ID:tUJULNxS(1/2) AAS
意味違うと思うぞ。whereだけじゃ足りないんじゃね
450: 05/14(水)01:55 ID:tUJULNxS(2/2) AAS
評価対象が行とグループ
評価タイミングも違うとchatGPTが教えてくれた
451: 05/14(水)06:22 ID:qNLCsgAG(1) AAS
そんなこともAIに訊かなきゃわからないんかよｗ
452(1): 05/14(水)08:46 ID:e7a03hqN(1/2) AAS
スレ主じゃないので
LLM勉強になるぞ
453: 05/14(水)11:40 ID:Ran/8XYC(1/2) AAS
グループ化と関係なくHAVINGを使っているんだろうなw
454: 05/14(水)11:41 ID:Ran/8XYC(2/2) AAS
>>452
AIチャットは間違いを指摘してくれない
455: 05/14(水)12:56 ID:1iop83U8(1) AAS
LLMの勉強する前に対人会話の勉強しよう？
456: 05/14(水)13:29 ID:e7a03hqN(2/2) AAS
お前らもﾈﾗｰだからLLMと大差ないぞ
教科書レベルの話はLLMさんが正確さ
457: 05/15(木)09:52 ID:3t3KbsMR(1) AAS
結局、>>445ってどう？ 素人考えでは、群の条件のうち、「任意の元に対する逆元が存在する（逆元も関係の元である必要がある）」を、関係および関係上の演算は満たさないようにも思うんだけど。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 2.378s*