SQLなら俺に訊け [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/07/14(金) 07:40:53.63

さあ

**デフォルトの名無しさん** · 2024/09/23(月) 07:02:58.03

いや「初歩的な」と言ってるんだし、
SQLではなく、テーブル作成時の間違いで、

crete table mytable (id INTEGER

とかやれと言った方がいいのでは

**デフォルトの名無しさん** · 2024/09/23(月) 08:28:16.45

>>268さん
ありがとうございます！記述は異なりますが、キャストというヒントから実現できました！
助かります！

>>269さん
ありがとうございます。都合上文字列のカラムなので困っていました。
ありがとうございます！

**デフォルトの名無しさん** · 2024/09/23(月) 09:03:31.51

>>270
> 都合上文字列のカラムなので
嘘だね
でもそのidをTEXTにするのは設計が間違ってるから、早い段階で直しておかないと頓挫する
でなければ壮絶クソコードの山になり、何とか動かせるだけのゴミにしかならないよ

設計的に正しい場合は、そのidが7,5,41,11とソートされて何も問題ないはず
他者の担当部分等の理由で変更出来ないのなら、つまり仕事としてやってるんだろうから、そいつや上司に聞け、ここで聞くのは悪手
(Zは同僚や上司に聞いたら恥とでも思ってるようだが、そうではなく、
部下がどの程度の技術レベルでどこまで仕事振れるかも管理範囲なのだから、分からない事は聞くべきだし、
逆にこの程度の初歩的部分すら分からないのに聞く事も許さないというのは、仕事場/上司に見切り付けるべき
そしてどうしても変更出来ないならCREATE VIEWで誤魔化した方がまだましな気もするが、まあ先に相談だろうね)

だから実際は自分でやってるんだろ、ならさっさとtable定義を直すべき

**デフォルトの名無しさん** · 2024/09/25(水) 13:39:54.41

バカは放っとこうよ

**デフォルトの名無しさん** · 2024/10/14(月) 03:33:42.65

>>267
それは文字の照合順序の問題
自分でそうしたのか、他人がそうしたのか書いてないが、一文字目だけで並び替えているだけ。

**デフォルトの名無しさん** · 2024/10/14(月) 03:34:54.50

>>270
少なくとも製品名くらいは書こうぜ

**デフォルトの名無しさん** · 2024/10/14(月) 12:40:53.49

>>273
新手のバカが現れたw

**デフォルトの名無しさん** · 2024/10/14(月) 12:49:16.73

>>275
文字列は文字コード順になるのが普通

桁数の違う数字列を比較したから、どういう結果になるかは照合順序による

数字列と数値は別物

**デフォルトの名無しさん** · 2024/10/14(月) 12:50:50.99

>>275
彼は7、5、4、1の順になってしまうと書いているが、アスキー文字の数字は1が先で9が後に配置されている。

**デフォルトの名無しさん** · 2024/10/14(月) 14:18:28.43

日本語が読めないのかSQLを全く知らないのかわからんが救いようのないバカなのは間違いない

**デフォルトの名無しさん** · 2024/10/14(月) 16:02:24.13

11を11、41を41、5を05、7を07という風にしないと結果は不明。

**デフォルトの名無しさん** · 2024/10/27(日) 09:13:31.20

良い感じのSQLのGUIクライアントある？
たとえばカラムに連番と画像（画像元のパスなど）があって、
全てのがぞうを表示するようなものを求めてる
殆どのGUIクライアントはそういうDBだ画像は表示されなくてその画像部分のフィールドをクリックしたときに1枚だけ表示されるけど、
そうじゃなくてずらっと並んでる画像パスの入ったフィールド全ての画像を表示したいのだが

**デフォルトの名無しさん** · 2024/10/27(日) 09:41:04.89

自分で作るか人が作ったアプリのDB構造に合わせるかしないと無理だろ
いずれにしろSQL関係ない

**デフォルトの名無しさん** · 2024/10/27(日) 15:56:39.28

>>281
ふーん、やっぱそうなるんだ
それを知りたかったんでね
あと何かむかつくからここから俺がこのスレ乗っ取ることにするわ
日記帳がわりにする

**デフォルトの名無しさん** · 2024/10/28(月) 15:33:24.71

>>280
MS-Access

**デフォルトの名無しさん** · 2024/10/28(月) 16:27:15.25

>>283
63bitで最大4Gまでしか扱えないものはノーサンキュ

**sage** · 2024/10/28(月) 17:18:52.43

これが条件後出しカッコ悪いというやつか

**デフォルトの名無しさん** · 2024/10/28(月) 17:25:09.25

63bit　63bit　63bit　63bit
最大4G　最大4G　最大4G　最大4G

**デフォルトの名無しさん** · 2024/10/30(水) 02:07:11.28

evo tech ωωω

**デフォルトの名無しさん** · 2024/10/30(水) 02:37:36.07

>>283,285
accessは他の追随を一切赦さぬDBMS覇権（性能、機能的な意味で）だろ
事実上普及してる全てのDBMSにコネクトできる万能クライアントだし
つまり表向きの売りであるGUIガン無視したとてしても最強
GUIでポチポチした履歴と生成されるクエリ突き合わせて解読をつづけれりゃあSQL資料すら見ずともSQL書きの中の上には成れる

惜しむらくはそれだけ優れててもMSに干されそうなとこか…
OfficeからAccess抜いて別売とか正気とは思えんよ、AccessがOfficeに同梱された時は狂喜乱舞してたなあ…

他のAccessフォロワRDBMS環境はOpen/Libre（とその派生）のBaseだけれども、正
直言って...α版の域すら出てないレベルでCLI叩いててSQL直打ちの方がマシ

**デフォルトの名無しさん** · 2024/10/30(水) 10:40:48.68

DBのGUIでつまいこういうことをやりたい
（ただ表示する画像はもっと多い）

https://i.imgur.com/e5UznLk.png

**デフォルトの名無しさん** · 2024/10/30(水) 19:37:59.35

>289
自分で作っちゃえばええやん
sqlでselectしてアプリケーション経由して（phpでもjavaでもTypeScriptでも何でもおけ）適当にhtmlブラウザで表示させればええやん
複雑なjoinとか無くて一つのテーブルで済むなら30分も掛からず出来るっしょ

**デフォルトの名無しさん** · 2024/10/30(水) 19:51:27.08

>>290
結局最終的にはhtmlで出力しかないのか
DBのGUIでずらっと画像だしてくれるものだとおもってた

**デフォルトの名無しさん** · 2024/10/30(水) 19:57:39.75

>291
マルチやめなさい。そしてhtml表示は一つの手段でしか無い。他にも方法なんぞ幾らでもあるわ。ただし、開発環境を一切書いてないから助言が出来るわけもなく
あくまで一般的な方法で手っ取り早いのを伝えただけ。
Excelのマクロ組んでもいいだろうし、cuiでコマンド叩いてDBからローカルの画像パス取ってきてホストPCに表示するバッチ組んでも良いだろうし…
「結局最終的にはhtmlで表示するしかない」なんて一言も書いてないぞ
繰り返すが「開発環境を一切書いてないから助言が出来るわけもなくあくまで一般的な方法で手っ取り早いのを伝えただけ。」だぞ

**デフォルトの名無しさん** · 2024/10/30(水) 20:01:18.39

>>292
そもそもphpでもjavaでもまたひと手間かよと思ったら泣きたくなってよー
とらいえずExcelでのデータベースはできたんだ
ただ数万の画像表示でクッソ重いからファイルパスに変えたけど
でも画像べらーって表示したいじゃん
これを試しに画像だけでもHTMLでやったらどうなるかと思ったら数万枚数十万のサムネ画像べらーっとはったら重いわ
そうなんだよな、htmlしばりするわけじゃねーもんな
とりあえず、EXCELでデータベース作って、SQliteにぶち込んでそれで様子みてる
そっから先は何でどうするか選択肢がおおすぎてわけわからなくなってんだわ
マツリポストは後生やからさぁ、いまのところかんべんしてつかーさい

**デフォルトの名無しさん** · 2024/10/30(水) 20:04:46.88

マルチポストとかこんなところにそんなのが存在するのか？

**デフォルトの名無しさん** · 2024/10/30(水) 20:07:31.52

良く考えたら風俗嬢とかのサイトでも女の子すべてずらーっと見せるの無いよな
数十毎にくぎってページ１とか２にしてるわけだし

**デフォルトの名無しさん** · 2024/10/30(水) 21:20:15.49

ガイジ大暴れ

**デフォルトの名無しさん** · 2024/10/31(木) 13:02:50.98

馬鹿には無理

**デフォルトの名無しさん** · 2024/11/01(金) 00:10:42.00

>>291
そんな付加をかけまくるツール、人間が少しだけ見るためのツールに需要はない。

**デフォルトの名無しさん** · 2024/11/01(金) 09:10:10.59

>>298
色々なサイトでサムネを1ページの中に限定して表示してるのは数を無限や数万数十万にすると負荷がかかるからか
なるほどなあ

**デフォルトの名無しさん** · 2024/11/01(金) 19:58:15.69

つ<img loading="lazy">

てか結局何がしたいの？
explorer＋特大アイコンで駄目な理由は？

**デフォルトの名無しさん** · 2024/11/01(金) 19:58:32.10

twitterのフォロワー整理ツールとか参考になるわ

**デフォルトの名無しさん** · 2024/11/03(日) 17:55:14.49

>>300
画像がDBに入っていると、エクスプローラーでは見れないんだよね

**デフォルトの名無しさん** · 2024/11/03(日) 18:18:24.25

>>302
それはそうだが、そもそも画像をDBに入れる意味がない
ただ初心者あるあるらしく、「(画像掲示板では)そうじゃなくてファイル名だけDBに入れてapacheに直接配信させるんだ」と
説明してたサイトがあったがすぐには出てこない

なおSQLiteはBLOBにもインデックス張れるらしいが、そんな使い方しないだろ

**デフォルトの名無しさん** · 2024/11/03(日) 18:54:12.64

>>303
上級者でもあるあるだけどね
デメリット大きいけどDBに入れたら入れたで便利なことも多いんだよね
もっと良かったこと探しをしろ

**デフォルトの名無しさん** · 2024/11/03(日) 20:08:56.01

ないと思うが、まあ上級者なら自分で何とかしろ
なお293なら画像をDBに入れてなければ解決してる

**デフォルトの名無しさん** · 2024/11/03(日) 22:39:10.72

何も解決してないだろｗｗ

**デフォルトの名無しさん** · 2024/11/04(月) 14:37:07.62

ずっとBAD GATEWAY

**デフォルトの名無しさん** · 2024/11/04(月) 14:37:49.34

っつーのは書けるのか　なんてこった

解決しなきゃいけない案件じゃねーだろ　画面いっぱいに数万もの大量な画像をずらーっと表示したいなんて要望は
そも、それをしてからその先どうしたいんだ？　それを一向に書こうとしない相談者に難がある
表示したらそれで満足なんか？
ランダムに表示するようにでもしなきゃ、毎回その数万の画像のうち特定の一部だけを目撃することに成る　それに意味は？
小アイコンサイズで画面いっぱいに貼ったとしてFHDモニタで250枚程度だ　もっとちっさくした画像でも貼ろうってのか
いろんな画像が次々湧いてくるようなエフェクト掛けて、とかならDBだのSQLだのほぼほぼ関係ねーわ

**デフォルトの名無しさん** · 2024/11/04(月) 14:52:26.31

>>308
何も解決していないのに「なお293なら画像をDBに入れてなければ解決してる(ｷﾘｯ)」みたいな痛いレスが面白かっただけだよ

**デフォルトの名無しさん** · 2024/11/06(水) 08:23:55.64

>>299
RDBでデータ型が画像データというデータ型は聞いたことがない。

RDBは画像データのバイナリデータか、画像データファイル形式に近いラージオブジェクト型。
単に画像データファイルへのリンクが入っているだけという設計もある。

**デフォルトの名無しさん** · 2024/11/06(水) 08:54:43.24

INNER JOINとEXISTSどっちがいいんだ？

**デフォルトの名無しさん** · 2024/11/06(水) 10:46:12.80

使い途がちがう　EXISTSはture/falseを返すだけ

**デフォルトの名無しさん** · 2024/11/06(水) 11:02:31.90

INNER JOINでもWHERE EXISTSでも、テーブルBのデータを使ってテーブルAのデータを絞り込んでSELECTするができるじゃん
性能的にどっちがいいんだっていう

**デフォルトの名無しさん** · 2024/11/06(水) 12:00:06.03

>>313
そもそも実行計画・実行プランくらいは見ろよ
書き方がどうとかいい加減にしろ！

**デフォルトの名無しさん** · 2024/11/06(水) 12:02:25.42

>>313
対象レコードの存在有無を判定するのに内部結合をするのは意図がわからないのでやめなさい。

しかも処理コストが高くなるのが普通だ。

**313** · 2024/11/07(木) 08:53:30.88

>>314-315
はい、ごめんなさい……

**デフォルトの名無しさん** · 2024/11/12(火) 08:43:58.73

PostgreSQL 17 を使ってるんですが

SELECT shohin_bunrui AS aaa
FROM shohin
where aaa = '衣服';

↑実行順序を考えると当然エラーになります。
エラー: 列"aaa"は存在しません

SELECT shohin_bunrui AS aaa
FROM shohin
GROUP BY aaa;

↑エラーになりません。SELECTよりGROUP BYの方が実行順が先なのになぜですか？

警備員[Lv.1][新芽] · 2024/11/12(火) 09:07:16.39

抽出条件で行の絞り込みをするのは、SELECTでなく WHEREかと
行を絞ってからグループ化するのはそうかもしれないけど、
統一感はあった方がいいとは思いますね

**デフォルトの名無しさん** · 2024/11/12(火) 11:00:57.73

>>317
GROUP BYでもcolumn aliasが使えるようPostgresが拡張してるから
集約関数とかを両方に書かないといけないの面倒でしょ？

**317** · 2024/11/12(火) 12:30:43.18

>> 319
Postgresさんが気を利かせてくれてるわけですね？
ありがとうございます。

**317** · 2024/11/12(火) 12:30:43.35

>> 319
Postgresさんが気を利かせてくれてるわけですね？
ありがとうございます。

**317** · 2024/11/12(火) 12:30:44.59

>> 319
Postgresさんが気を利かせてくれてるわけですね？
ありがとうございます。

**デフォルトの名無しさん** · 2024/11/12(火) 12:31:48.29

すみません。ブラウザの反応がなかったので何回も書込み押してしまいました

**デフォルトの名無しさん** · 2024/11/12(火) 15:44:40.37

view造って先にaaaのみにするんじゃね

警備員[Lv.4][新芽] · 2024/11/12(火) 16:45:36.43

WHEREによるフィルタが先で、SELECTによるマップがあとなのかな

**デフォルトの名無しさん** · 2024/11/12(火) 17:29:22.04

>>322
そんなに列別名を使いたい理由がわからない。

集合演算のSELECTでテーブルによって列名が異なるならやらないといけないが、そういうSELECTでないのにテーブル別名メリットが大きいが、列別名を使うメリットなんてほとんどないよ。

**デフォルトの名無しさん** · 2024/11/12(火) 17:31:02.65

>>325
SQLの構文解析エンジンの仕様によるような書き方をするのがそもそもの間違いだよね。

警備員[Lv.6][新芽] · 2024/11/12(火) 18:00:22.86

>>327
ですね

警備員[Lv.6][新芽] · 2024/11/12(火) 18:13:14.69

LINQを最初に見たとき、なんでこんな順序なんだ? と思ったけど、自然な順序なのかもね
FROM→WHERE→SELECT

しばらくLINQやってないから、うろ覚えで見当違いだったらごめんなさい

**デフォルトの名無しさん** · 2024/11/12(火) 19:58:46.82

>>329
SQLは自然言語に近い表現で作られた
英語の語順になっているから、日本人には変な順番に見えるだけ

**デフォルトの名無しさん** · 2024/12/20(金) 16:41:43.73

テーブルごと全てのカラムにまとめて別名付けるとかできないのかな
以下のような場合に別名付けるとき
テーブルA
id
name
description

テーブルB
id
name
description

select
A.id as A_id,
A.name as A_name,
A.description as A_description,
B.id as B_id,
B.name as B_name,
B.description as B_description
from
みたいに書かないといけないのを
A.* as A_*
みたいに書けたら便利なのに

**デフォルトの名無しさん** · 2024/12/21(土) 11:36:41.92

うちはそのまま A.name のまま扱ってるよ

**デフォルトの名無しさん** · 2024/12/21(土) 19:55:23.41

>>331
またそのネタかよw

**デフォルトの名無しさん** · 2024/12/21(土) 20:43:39.23

SQLを出力するプログラム位かけるやろ

**313** · 2024/12/23(月) 08:20:37.09

>>330
クエリ式であってSQLじゃねぇだろ
SQLの語順ならSELECTが最初だ

**デフォルトの名無しさん** · 2024/12/23(月) 10:17:08.30

>>333
また、って言うくらいには結構求められている機能だと思う

**デフォルトの名無しさん** · 2024/12/23(月) 18:35:45.31

>>329
LINQはそもそも.NETのコードの物だから
メソッドチェーンで書く時の順番がそのままになってるだけよ

HogeList.Where().Select()って書き方になるからクエリ式もそうなる。

**デフォルトの名無しさん** · 2024/12/24(火) 09:46:38.33

>>331
すべてのカラムに最初からそういう名前をつけているよ
テーブルA
A_id
A_name
A_description

テーブルB
B_id
B_name
B_description

select
A_id,
A_name,
A_description,
B_id,
B_name,
B_description
from
とシンプルに書けて良いよ

**デフォルトの名無しさん** · 2024/12/24(火) 12:30:30.62

>338
>331を読むに、別名（エイリアス）でテーブル名付けたいって事でしょ
確かに長ったらしいテーブル名は一括で一文字のエイリアス名を付けたいな…の思う事もあるから>338の言わんとしてることも分かる

**デフォルトの名無しさん** · 2024/12/24(火) 22:39:03.73

>>335
標示SQLではSELECTよりもWITHが先

**デフォルトの名無しさん** · 2024/12/24(火) 22:40:09.34

>>338
同じカラム名なのに意味が異なるという狂った設計なのが間違い

**デフォルトの名無しさん** · 2024/12/25(水) 01:30:11.46

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”でアクセスするんだから表示調整くらい簡単にできそうだけどな

**デフォルトの名無しさん** · 2024/12/25(水) 08:15:20.48

誰もWITHの話なんかしとらんのに突然の主張ｗ

**デフォルトの名無しさん** · 2024/12/25(水) 12:26:11.92

日本語SQLスズラン

**デフォルトの名無しさん** · 2024/12/25(水) 15:26:23.80

be with you

**デフォルトの名無しさん** · 2024/12/25(水) 17:53:18.64

>>343
SELECT句よりも先にWITH句を書くので、SELECT句が先ではない。

**デフォルトの名無しさん** · 2024/12/25(水) 17:56:53.42

>>342
根本的に同じカラム名なのに別のカラムという設計がおかしい

どちらかのテーブルにしかないカラムなら、修飾そのものがいらない

それはあんたはSQLの話ではなくて、別の製品の仕様の話をしている

それに同じ名前のカラム名なら別名を定義するべきだ

**デフォルトの名無しさん** · 2024/12/25(水) 17:58:44.64

　
SQLを適当に書く人間が増えて、めちゃくちゃなシステムだらけになった。

同じカラムが、同じカラムがというなら、結合したビューでも用意しとけよw

**デフォルトの名無しさん** · 2024/12/25(水) 18:33:32.24

元の話も読めないようなヤツはWITHがどうのと主張しとらんと黙っといた方がいいよｗ

**デフォルトの名無しさん** · 2024/12/25(水) 18:36:08.08

>>346
誰もWITHの話なんかしとらんのに突然の主張ｗ

**デフォルトの名無しさん** · 2024/12/25(水) 19:42:44.67

>>350
335 313 sage 2024/12/23(月) 08:20:37.09 ID:hrYrd+aN
>>330
クエリ式であってSQLじゃねぇだろ
SQLの語順ならSELECTが最初だ

**デフォルトの名無しさん** · 2024/12/25(水) 19:44:16.65

>>349
SQLの構文仕様を調べたことがあるのか？

SQLそのものは自然言語の英語の語順になっているだけ

**デフォルトの名無しさん** · 2024/12/25(水) 19:47:55.88

「クエリ式」はSQLの世界の話ではなく、SQLを組み立てる側のライブラリの世界の話。

使われる方が使う方を意識するという発想で設計書を書かせようとする人間がいるが、それだと延々とドキュメントを修正することになる。

世界中の人間に聞いて回ってドキュメントを修正するなど無理だし、無意味。

**デフォルトの名無しさん** · 2024/12/25(水) 21:03:35.85

ダメだわこの頭でっかちｗ

**デフォルトの名無しさん** · 2024/12/26(木) 13:44:41.34

>>341
うれしい副産物として、違うカラム名にできるというメリットもある

**デフォルトの名無しさん** · 2024/12/30(月) 02:42:59.39

>>354
SQLを書きたくないという理由を聞きたい
他人にぶん投げられれば気が済むのか？

**デフォルトの名無しさん** · 2024/12/30(月) 02:44:55.46

なぜ「データベース」板を無視して「プログラム」板に書いているのも謎

**デフォルトの名無しさん** · 2024/12/30(月) 14:22:49.66

SQLなんて一回描いたら何度も描き治すもんでもないからな
面倒臭がるのは怠慢

**デフォルトの名無しさん** · 2024/12/30(月) 19:29:38.65

>>358
なおすでーー

**デフォルトの名無しさん** · 2025/01/01(水) 21:42:25.49

>>359
そう何度も直すことは無いよ

**デフォルトの名無しさん** · 2025/01/01(水) 23:12:26.15

へぼかったら治すでーー

**デフォルトの名無しさん** · 2025/01/05(日) 10:38:54.01

単にテキストエディタの機能を使いこなせずに毎度、すべてキー入力している初心者は案外、多い。

**デフォルトの名無しさん** · 2025/01/05(日) 10:48:34.28

ORMなんていらん

**デフォルトの名無しさん** · 2025/01/05(日) 19:51:54.27

サブクエリ難しい

**デフォルトの名無しさん** · 2025/01/05(日) 19:52:23.20

息をするようにSQLを書きたい

**デフォルトの名無しさん** · 2025/01/05(日) 20:49:47.84

>>364
当該処理がクエリを2回以上発行することを許されてる仕様や環境なら、無理にサブクエリ１発で処理しようとせず2回以上に分けて処理するのも手だよ
サブクエリって見づらいしメンテナンスしづらいし

**デフォルトの名無しさん** · 2025/01/05(日) 22:36:32.88

CTEのおかげてサブクエリの出番はめっきり少なくなったよね

**デフォルトの名無しさん** · 2025/01/06(月) 12:33:31.51

>>367
ＣＴＥってなに？