24/01/29(月)20:26:24 SELECT ... のスレッド詳細
削除依頼やバグ報告は メールフォーム にお願いします。個人情報、名誉毀損、侵害等については積極的に削除しますので、 メールフォーム より該当URLをご連絡いただけると助かります。
画像ファイル名:1706527584517.jpg 24/01/29(月)20:26:24 No.1151728901
SELECT USER_NAME FROM IMG_USERS WHERE HAGE_FLAG='1';
1 24/01/29(月)20:27:17 No.1151729369
4379件のレコードがあります
2 24/01/29(月)20:27:57 No.1151729719
「」
3 24/01/29(月)20:29:14 No.1151730444
>HAGE_FLAG='1'; HAGE_STATUSにしなさい FLAGにするならBoolにしなさいハゲ
4 24/01/29(月)20:30:05 No.1151730917
フラグ項目はBoolean型にしろ お前をBLOB型に突っ込むぞ
5 24/01/29(月)20:30:06 No.1151730923
>select USER_NAME >from IMG_USERS >where HAGE_FLAG = TRUE;
6 24/01/29(月)20:33:37 No.1151732929
>4379件のレコードがあります 全員ハゲてんのかよ...
7 24/01/29(月)20:33:39 No.1151732952
SELECT USER_NAME FROM IMG_USERS WHERE JOB IS NULL;
8 24/01/29(月)20:34:54 No.1151733694
HAGEが1なら生えてるみたいじゃん0にしなさい
9 24/01/29(月)20:35:03 No.1151733759
SELECT DISTINCT USER_NAME FROM IMG_USERS;
10 24/01/29(月)20:36:12 No.1151734382
USER_NAME=''で集計してみたい
11 24/01/29(月)20:36:25 No.1151734492
HAIR = 0
12 24/01/29(月)20:36:28 No.1151734528
SELECT USER_NAME FROM IMG_USERS INNER JOIN MAY_USERS ON IMG_USERS.USER_NAME = MAY_USERS.USER_NAME;
13 24/01/29(月)20:36:34 No.1151734587
>SELECT count(USER_NAME) >FROM IMG_USERS >WHERE JOB <>’’;
14 24/01/29(月)20:37:18 No.1151734936
「」は''かNULLなのか？
15 24/01/29(月)20:37:44 No.1151735154
何で仕事終わったのにクエリ眺めなきゃいけないんだクソもうimgなんて嫌だ
16 24/01/29(月)20:38:44 No.1151735653
>「」は''かNULLなのか？ RDMSによる？
17 24/01/29(月)20:38:50 No.1151735706
SELECT COUNT(*) FROM IMG_USER WHERE TOUHATU IS NOT NULL; 結果:0
18 24/01/29(月)20:39:00 No.1151735804
SELECT USER_NAME FROM IMG_USERS WHERE DEBU_FLAG='DEBU';
19 24/01/29(月)20:40:09 No.1151736432
そもそもboolにできるフラグはflagじゃなくてisなんちゃらにしたい気持ちがある 3択とか四択とかある奴ならflgつけるかも
20 24/01/29(月)20:40:16 No.1151736514
select USER_NAME from IMG_USERS where IMG_START_YMD <= '2000-01-01';
21 24/01/29(月)20:40:16 No.1151736516
>「」は''かNULLなのか？ Oracleだと等価なの…
22 24/01/29(月)20:41:49 No.1151737377
>WHERE DEBU_FLAG='DEBU'; だから一種類しかない状態要素を作るなって…
23 24/01/29(月)20:42:05 No.1151737495
>SELECT USER_NAME >FROM IMG_USERS >WHERE DEBU_FLAG='DEBU'; テーブル作ったやつどつき上げろ
24 24/01/29(月)20:42:18 No.1151737617
「」.isHaged = true;
25 24/01/29(月)20:42:20 No.1151737633
スレッドを立てた人によって削除されました https://twitter.com/CYAKA_MUNOO
26 24/01/29(月)20:42:27 No.1151737697
USER_NAMEをNULL許可することある？
27 24/01/29(月)20:42:28 No.1151737710
なぜimgとmayでテーブルをわけているのですか？ 差分だけ別テーブルに持たせてはどうでしょうか？
28 24/01/29(月)20:43:02 No.1151738107
>USER_NAMEをNULL許可することある？ 「」がユーザーの場合とか…
29 24/01/29(月)20:43:11 No.1151738192
DELETEしろ
30 24/01/29(月)20:43:13 No.1151738203
YOBI1 = 'DEBU' AND YOBI2 = 'HAGE'
31 24/01/29(月)20:43:34 No.1151738408
ゴミみたいな設計のテーブルを見ると世界を滅ぼしたくなる
32 24/01/29(月)20:43:39 No.1151738466
SELECT USER_NAME FROM IMG_USERS WHERE YOBI1 = '1';
33 24/01/29(月)20:44:04 No.1151738709
HAIR IS NOT NULL
34 24/01/29(月)20:44:44 No.1151739114
書き込みをした人によって削除されました
35 24/01/29(月)20:45:06 No.1151739310
>HAIR IS NOT NULL この要素はNUMBER型なのか？ それともVARCHAR型なのか？
36 24/01/29(月)20:45:13 No.1151739396
>ゴミみたいな設計のテーブルを見ると世界を滅ぼしたくなる まだ見ぬDBより動いているDBが正義みたいなとこある
37 24/01/29(月)20:45:18 No.1151739439
1' or '1' = '1';--
38 24/01/29(月)20:46:01 No.1151739814
SELECT * FROM IMG_USERS WHERE NUM_OF_HAIRS = 0;
39 24/01/29(月)20:46:15 No.1151739943
業務アプリと密結合しているクソデータベースあるんだけど アプリ側に見せてるテーブルを徐々にビューに置き換える方針で大丈夫かな
40 24/01/29(月)20:46:17 No.1151739960
hair_typeでいいよ
41 24/01/29(月)20:46:35 No.1151740156
>業務アプリと密結合しているクソデータベースあるんだけど >アプリ側に見せてるテーブルを徐々にビューに置き換える方針で大丈夫かな いいよ
42 24/01/29(月)20:46:42 No.1151740235
>ゴミみたいな設計のテーブルを見ると世界を滅ぼしたくなる 昔はもっとstateの種類があって…運用してる内にフラグみたいになっててて…
43 24/01/29(月)20:47:06 No.1151740531
SELECT COUNT(HAIR)
44 24/01/29(月)20:47:51 No.1151741023
>アプリ側に見せてるテーブルを徐々にビューに置き換える方針で大丈夫かな 未来にVIEWのネストされてチューニングで死ぬのが見える
45 24/01/29(月)20:48:12 No.1151741251
こんにちは私の名前は’; drop table img_users;’です
46 24/01/29(月)20:48:23 No.1151741385
密結合で何が困ってるのかによる
47 24/01/29(月)20:48:25 No.1151741401
基本フロントしか書かないんだけどオライリーのSQLアンチパターンが気になってる 古すぎてもう役に立たないんしゃろうか
48 24/01/29(月)20:48:49 No.1151741630
>こんにちは私の名前は’; drop table img_users;’です 気軽にインジェクション
49 24/01/29(月)20:48:53 No.1151741667
NULL許容は百害あって一利なし
50 24/01/29(月)20:49:20 No.1151741928
>HAIR IS NOT NULL nullはhageって事でいいですよね
51 24/01/29(月)20:49:47 No.1151742200
>基本フロントしか書かないんだけどオライリーのSQLアンチパターンが気になってる >古すぎてもう役に立たないんしゃろうか あの本は滅茶苦茶良い本だよ 確かに今古い部分はあるけどほぼ使える
52 24/01/29(月)20:49:58 No.1151742284
>基本フロントしか書かないんだけどオライリーのSQLアンチパターンが気になってる >古すぎてもう役に立たないんしゃろうか 読んで損はないと思うよ だってこないだあのアンチパターンそのまんまのテーブル持ってこられたもん
53 24/01/29(月)20:50:00 No.1151742309
>NULL許容は百害あって一利なし joinしたらnullになっちゃって...
54 24/01/29(月)20:50:37 No.1151742653
今まで見た中で最悪のテーブル設計だと300カラム超えてた
55 24/01/29(月)20:50:38 No.1151742663
「欲しい結果が取れれば過程はどうでもいい」みたいなクエリやめてくれんかアレ つか開発工程で実行計画とか取らないの？
56 24/01/29(月)20:51:21 No.1151743147
>SELECT COUNT(HAIR) >FROM IMG_USERS >WHERE DEBU_FLAG='DEBU' AND STATUS_NOT_HAGE <> FALSE;
57 24/01/29(月)20:51:29 No.1151743217
>「欲しい結果が取れれば過程はどうでもいい」みたいなクエリやめてくれんかアレ >つか開発工程で実行計画とか取らないの？ 開発環境にはデータ件数少ないからサクサク返ってくるんですよ
58 24/01/29(月)20:51:39 No.1151743330
データは必要があってその形をしています
59 24/01/29(月)20:52:01 No.1151743530
USER_NAME null
60 24/01/29(月)20:52:14 No.1151743650
DELETE FROM IMGUSER WHERE ID=(SELECT ID FROM IMGUSER WHERE JOB IS NULL)
61 24/01/29(月)20:52:32 No.1151743776
Nullであることに意味があるんだ！
62 24/01/29(月)20:52:52 No.1151743977
ハゲはカッパとかデコとかクレーターは無いけどスカスカとか区別する必要有る？
63 24/01/29(月)20:53:09 No.1151744151
>WHERE ID=(SELECT ID FROM IMGUSER WHERE JOB IS NULL) サブクエリ怖くない？
64 24/01/29(月)20:53:45 No.1151744528
バーコードはハゲフラグ立つ？
65 24/01/29(月)20:53:50 No.1151744591
>>WHERE ID=(SELECT ID FROM IMGUSER WHERE JOB IS NULL) >サブクエリ怖くない？ EXISTS使って欲しい
66 24/01/29(月)20:53:50 No.1151744600
ここのユーザー取得にdistinctかけたらパターン少ないからだいぶ減りそう
67 24/01/29(月)20:54:01 No.1151744719
>>「欲しい結果が取れれば過程はどうでもいい」みたいなクエリやめてくれんかアレ >>つか開発工程で実行計画とか取らないの？ >開発環境にはデータ件数少ないからサクサク返ってくるんですよ クエリの速度差とかわからないし…取れればOK！
68 24/01/29(月)20:54:01 No.1151744722
>ハゲはカッパとかデコとかクレーターは無いけどスカスカとか区別する必要有る？ だからhage_flagではなくhage_statusにする必要がある
69 24/01/29(月)20:54:29 No.1151744998
人間のセンシティブな属性は政治的な要因によって種類が増えるから考慮して設計してね♡
70 24/01/29(月)20:54:30 No.1151745016
>あの本は滅茶苦茶良い本だよ >読んで損はないと思うよ 買うかー... しかし今でも通用するとは驚いたSQLって他の言語とかに比べると基礎的な考え方は昔から大きく変わってないってことか あるいはどれだけ言われても同じ過ちが繰り返され続けているのか
71 24/01/29(月)20:54:39 No.1151745112
hage専用ステータス用意する必要ある？
72 24/01/29(月)20:54:49 No.1151745211
こういうのどこで覚えるの？ 大学でオラクル一通り勉強したけど実務でのテーブルの定義の仕方とか全くやらなかったぞ
73 24/01/29(月)20:55:08 No.1151745364
SQLアンチパターンの中で明確に古くなったと言えるのは カラムにJSON突っ込むなってところぐらいだ
74 24/01/29(月)20:55:16 No.1151745436
ハゲてることを判定するタイミングある？みんなフサフサってことにした方が良くない？
75 24/01/29(月)20:55:29 No.1151745572
>hage専用ステータス用意する必要ある？ hageは一般と違う道を進むから分けておくとわかりやすい
76 24/01/29(月)20:55:31 No.1151745595
create table common_tbl ( value_001 VARCHAR(1000), value_002 VARCHAR(1000), value_003 VARCHAR(1000), ： ： value_100 VARCHAR(1000) );
77 24/01/29(月)20:55:38 No.1151745659
教科書より実務の方が酷い
78 24/01/29(月)20:55:39 No.1151745667
>あるいはどれだけ言われても同じ過ちが繰り返され続けているのか こっちですね…
79 24/01/29(月)20:55:52 No.1151745785
>create table common_tbl >( > value_001 VARCHAR(1000), > value_002 VARCHAR(1000), > value_003 VARCHAR(1000), > ： > ： > value_100 VARCHAR(1000) >); 野村総研かよ
80 24/01/29(月)20:56:08 No.1151745915
>create table common_tbl >( > value_001 VARCHAR(1000), > value_002 VARCHAR(1000), > value_003 VARCHAR(1000), > ： > ： > value_100 VARCHAR(1000) >); 頼むから死んでくれ
81 24/01/29(月)20:56:12 No.1151745946
>人間のセンシティブな属性は政治的な要因によって種類が増えるから考慮して設計してね♡ (フリーカラムにJSON突っ込むか…)
82 24/01/29(月)20:56:24 No.1151746054
>人間のセンシティブな属性は政治的な要因によって種類が増えるから考慮して設計してね♡ じゃあもう肌の色とか65536色用意しておくか！
83 24/01/29(月)20:56:35 No.1151746150
>HAGEが1なら生えてるみたいじゃん0にしなさい それだとHAIRの方が良くない？
84 24/01/29(月)20:56:48 No.1151746308
例えばimgマスタがあったとしてプライマリキーをimg_idとするかidとするかって人によるの？
85 24/01/29(月)20:56:58 No.1151746396
「」が思う芸術的なテーブルってどこの顧客管理システム？ 実名出してもいいよ 俺が許す
86 24/01/29(月)20:57:06 No.1151746476
>こういうのどこで覚えるの？ >大学でオラクル一通り勉強したけど実務でのテーブルの定義の仕方とか全くやらなかったぞ 勉強苦手だから実践でしか学んだこと無いわ ググってたら適当に知識ついたけど正しい知識とは思ってない
87 24/01/29(月)20:57:06 No.1151746483
開発者なんて大体動けばいいばっかで性能なんて軽視してるかそもそも観点にないだろ
88 24/01/29(月)20:57:12 No.1151746539
>人間のセンシティブな属性は政治的な要因によって種類が増えるから考慮して設計してね♡ 都度カラム追加してやるぜ
89 24/01/29(月)20:57:45 No.1151746818
どうしてもハゲフラグ作りたいならhas_hairでbool型にしてほしい 1がフサフサ0がハゲで直感的だ
90 24/01/29(月)20:57:48 No.1151746837
>勉強苦手だから実践でしか学んだこと無いわ >ググってたら適当に知識ついたけど正しい知識とは思ってない 関数とか自分で組んだりはしない？
91 24/01/29(月)20:58:00 No.1151746941
IMG USERテーブルではNAMEはUNIQUE制約付いてないどころかNULLABLE
92 24/01/29(月)20:58:00 No.1151746944
性能試験出来る環境無いんじゃないの
93 24/01/29(月)20:58:15 No.1151747090
>例えばimgマスタがあったとしてプライマリキーをimg_idとするかidとするかって人によるの？ img_idだとimg.img_idになってめっちゃ気持ち悪いぞ
94 24/01/29(月)20:58:36 No.1151747296
>IMG USERテーブルではNAMEはUNIQUE制約付いてないどころかNULLABLE それどころかIDも別にプライマリキーじゃなくない？
95 24/01/29(月)20:58:38 No.1151747317
>開発者なんて大体動けばいいばっかで性能なんて軽視してるかそもそも観点にないだろ 問題になるくらい遅かったら修正するけどユーザーは思ったより我慢強い
96 24/01/29(月)20:58:52 No.1151747462
>どうしてもハゲフラグ作りたいならhas_hairでbool型にしてほしい それだとヅラのやつが1入れようと粘りだすからだめ
97 24/01/29(月)20:58:58 No.1151747519
よくわかんあいからORMが吐き出したのそのままなげる
98 24/01/29(月)20:58:59 No.1151747538
俺が今まで見た中でクソなテーブルは申請出した後取り下げて申請出し直すと一意制約違反になる
99 24/01/29(月)20:59:22 No.1151747758
>例えばimgマスタがあったとしてプライマリキーをimg_idとするかidとするかって人によるの？ imgのidならidにするかな img.id参照するカラムはimg_idにする
100 24/01/29(月)20:59:22 No.1151747761
SQLよく分かってないけど エクセルの表となにか違うの？
101 24/01/29(月)20:59:27 No.1151747808
>開発者なんて大体動けばいいばっかで性能なんて軽視してるかそもそも観点にないだろ 開発終わったらさようならって言われるし
102 24/01/29(月)20:59:29 No.1151747835
ここのNoもそうだけど連番は辛いものなのに使いたがる人多すぎ
103 24/01/29(月)20:59:31 No.1151747857
毎日触ってるけど設計業務に回ったこと無いから拡張性とか考えて作るの大変だろうなあとは思ってる JSONブチ込むやつは死んでしまえ
104 24/01/29(月)20:59:57 No.1151748085
>SQLよく分かってないけど >エクセルの表となにか違うの？ 5000万レコードとかを扱える
105 24/01/29(月)21:00:06 No.1151748152
>どうしてもハゲフラグ作りたいならhas_hairでbool型にしてほしい >1がフサフサ0がハゲで直感的だ 髪がある状態ってのが曖昧すぎるからよくない 波平みたいなのも1でフサフサになる
106 24/01/29(月)21:00:10 No.1151748193
img_idの方がgrepし易いのでimg_idの方が良いよ
107 24/01/29(月)21:00:12 No.1151748209
論理削除用のフラグあるのにDELETE文流すのやめてほしい
108 24/01/29(月)21:00:24 No.1151748318
WITHで縦にたくさん繋げて整形して最後に必要な部分だけJOINするのと それぞれテーブル毎にSELECT投げてAPIサーバー側でくっつけて整形するのどっちの方が無難なのかいまだに判断つかない
109 24/01/29(月)21:00:31 No.1151748364
>SQLよく分かってないけど >エクセルの表となにか違うの？ VLOOKUPの強化版を使いまくる
110 24/01/29(月)21:00:48 No.1151748563
NAMEがNULLABLEならPKは何で指定するんだ？年齢？SEQ？
111 24/01/29(月)21:00:54 No.1151748631
>論理削除用のフラグあるのにDELETE文流すのやめてほしい ユーザーに連打されたらレコードいっぱい出来ちゃったから消すね…
112 24/01/29(月)21:00:55 No.1151748649
>論理削除やめてほしい
113 24/01/29(月)21:01:08 No.1151748764
>5000万レコードとかを扱える なるほど つまり共同編集できて動作が軽くて高機能なエクセル？
114 24/01/29(月)21:01:18 No.1151748862
BASE64エンコードされたデータがつっこまれたテーブルみたことあるけどこれってよくやることなんです？
115 24/01/29(月)21:01:29 No.1151748952
フラグカラムはVARCHAR(10)ぐらいで作っておくと 後からの要件追加でヅラの人たちを切り分けて管理したいときに便利だぜ！
116 24/01/29(月)21:01:36 No.1151749009
論理削除ってレコード数の増加どうしてんの？
117 24/01/29(月)21:01:40 No.1151749038
>WITHで縦にたくさん繋げて整形して最後に必要な部分だけJOINするのと >それぞれテーブル毎にSELECT投げてAPIサーバー側でくっつけて整形するのどっちの方が無難なのかいまだに判断つかない 後者だとselect複数投げてる間に更新されると整合性ぶっ壊れない？
118 24/01/29(月)21:01:42 No.1151749056
現在の最適解だすことは不毛
119 24/01/29(月)21:01:43 No.1151749062
まずエクセルで理解しようとするのをやめろ
120 24/01/29(月)21:01:58 No.1151749219
>NAMEがNULLABLEならPKは何で指定するんだ？年齢？SEQ？ 同姓同名が存在するのにNAMEをPKに入れなくない？
121 24/01/29(月)21:01:59 No.1151749228
>俺が今まで見た中でクソなテーブルは申請出した後取り下げて申請出し直すと一意制約違反になる 取り下げたと見せかけて削除フラグ立てただけとかだとそうなるね…
122 24/01/29(月)21:02:02 No.1151749254
>BASE64エンコードされたデータがつっこまれたテーブルみたことあるけどこれってよくやることなんです？ そんなの現場に寄るとしか
123 24/01/29(月)21:02:07 No.1151749272
>論理削除ってレコード数の増加どうしてんの？ DBに耐えてもらう
124 24/01/29(月)21:02:07 No.1151749273
indexはりようなくねこのクエリ
125 24/01/29(月)21:02:12 No.1151749336
>HAGEが1なら生えてるみたいじゃんhair=0にしなさい
126 24/01/29(月)21:02:15 No.1151749365
>WITHで縦にたくさん繋げて整形して最後に必要な部分だけJOINするのと >それぞれテーブル毎にSELECT投げてAPIサーバー側でくっつけて整形するのどっちの方が無難なのかいまだに判断つかない ケースバイケースだ ストアドプロシージャだけは使うな死亡フラグだ
127 24/01/29(月)21:02:16 No.1151749375
>>5000万レコードとかを扱える >なるほど >つまり共同編集できて動作が軽くて高機能なエクセル？ まずエクセルをデータベースとして捉えるのをやめろ
128 24/01/29(月)21:02:31 No.1151749559
>BASE64エンコードされたデータがつっこまれたテーブルみたことあるけどこれってよくやることなんです？ ファイルサーバーのパスとか格納した方が管理しやすい気がする
129 24/01/29(月)21:02:34 No.1151749574
>現在の最適解だすことは不毛 （髪の毛のことだろうか…？）
130 24/01/29(月)21:02:34 No.1151749576
>フラグカラムはVARCHAR(10)ぐらいで作っておくと >後からの要件追加でヅラの人たちを切り分けて管理したいときに便利だぜ！ それならカラム追加してヅラ判定用Boolあったほうがいいんじゃ…
131 24/01/29(月)21:02:38 No.1151749606
俺は雰囲気でindexを貼っている……
132 24/01/29(月)21:02:44 No.1151749662
>つまり共同編集できて 正しく使えば >動作が軽くて 正しく使えば >高機能な 正しく使えば >エクセル？ ではない
133 24/01/29(月)21:02:49 No.1151749724
職場が変わったらACCESSの使用許可が降りなくてパワークエリでM言語触り始めたけど結構違うなコレ GUIは優秀だけど言語に戸惑う
134 24/01/29(月)21:02:51 No.1151749745
実行計画読める奴は少ないというかそもそも実行計画の存在すら知らないのはおま環なのか？
135 24/01/29(月)21:02:53 No.1151749780
>まずエクセルをデータベースとして捉えるのをやめろ いや表計算ソフトなんだからエクセルで例えるのは間違っちゃいない
136 24/01/29(月)21:03:01 No.1151749877
エクセルなんて重い奴筆頭格じゃねえか
137 24/01/29(月)21:03:06 No.1151749921
>論理削除ってレコード数の増加どうしてんの？ 日次バッチで保有期限より過去になったら物理削除
138 24/01/29(月)21:03:15 No.1151750045
>WITHで縦にたくさん繋げて整形して最後に必要な部分だけJOINするのと >それぞれテーブル毎にSELECT投げてAPIサーバー側でくっつけて整形するのどっちの方が無難なのかいまだに判断つかない 可読性は上がるのはデカい 速度は殆どのDBで変化しないけど
139 24/01/29(月)21:03:20 No.1151750093
>いや表計算ソフトなんだからエクセルで例えるのは間違っちゃいない わかった殺す
140 24/01/29(月)21:03:36 No.1151750267
集計処理はストアドでやったほうが良いよ
141 24/01/29(月)21:03:50 No.1151750390
ACCESSをどうぞよろしく！
142 24/01/29(月)21:03:54 No.1151750410
>後者だとselect複数投げてる間に更新されると整合性ぶっ壊れない？ 言われてみればそうである 俺1人しか動かさないから気づかなかったぜー！！
143 24/01/29(月)21:03:55 No.1151750423
db触るような仕事をこの時間までやってる「」はお疲れ様だ
144 24/01/29(月)21:03:57 No.1151750442
>日次バッチで保有期限より過去になったら物理削除 論理削除フラグいらねえじゃん
145 24/01/29(月)21:03:57 No.1151750451
書き込みをした人によって削除されました
146 24/01/29(月)21:04:30 No.1151750705
>>BASE64エンコードされたデータがつっこまれたテーブルみたことあるけどこれってよくやることなんです？ >ファイルサーバーのパスとか格納した方が管理しやすい気がする バイナリデータをそのまま突っ込むのは バックアップデータの管理がし辛いしいざというときの復旧に時間が掛かるしで後悔することが多いね
147 24/01/29(月)21:04:32 No.1151750723
>いや表計算ソフトなんだからエクセルで例えるのは間違っちゃいない 顧客側の不勉強なやつにすらこんなこと言い出すやつまず居ないから最底辺のクズだよ
148 24/01/29(月)21:04:38 No.1151750774
>ACCESSをどうぞよろしく！ 方言が強過ぎる
149 24/01/29(月)21:04:38 No.1151750775
>>日次バッチで保有期限より過去になったら物理削除 >論理削除フラグいらねえじゃん 必要のないデータと消していいデータは違うのよ
150 24/01/29(月)21:04:42 No.1151750810
俺はデータベース初心者 SQLって普通のデータも格納できるの？（xlsxとかdwgとか） それともあくまでテーブルには文字しか格納できない？ 例えばファイルをしまいたいならファイルサーバーを別に用意して データベースにはファイルのパスを入れるとか？
151 24/01/29(月)21:04:46 No.1151750851
DATA string[]
152 24/01/29(月)21:04:46 No.1151750852
>>BASE64エンコードされたデータがつっこまれたテーブルみたことあるけどこれってよくやることなんです？ >ファイルサーバーのパスとか格納した方が管理しやすい気がする 中身はSystem.Data.DatasetをBinaryFormatterでシリアル化したものでやんした…
153 24/01/29(月)21:04:56 No.1151750947
>俺はデータベース初心者 >SQLって普通のデータも格納できるの？（xlsxとかdwgとか） データそのものを仕舞い込めなくはない 絶対パス仕舞い込んだ方が楽
154 24/01/29(月)21:05:11 No.1151751103
「業務を意識したインデックス」ってテーブル設計の段階でわかるものなの？ 言われても画面もできてないのに正しい検索条件に貼れ言われても俺わからないんだけど？
155 24/01/29(月)21:05:24 No.1151751223
>>俺はデータベース初心者 >>SQLって普通のデータも格納できるの？（xlsxとかdwgとか） >データそのものを仕舞い込めなくはない >絶対パス仕舞い込んだ方が楽 BLOBはマジおすすめしないよな…
156 24/01/29(月)21:05:39 No.1151751380
>SQLって普通のデータも格納できるの？（xlsxとかdwgとか） >それともあくまでテーブルには文字しか格納できない？ >例えばファイルをしまいたいならファイルサーバーを別に用意して >データベースにはファイルのパスを入れるとか？ なせばなるけど一生そのクソDBの面倒見てくれよな
157 24/01/29(月)21:05:48 No.1151751462
>俺はデータベース初心者 >SQLって普通のデータも格納できるの？（xlsxとかdwgとか） >それともあくまでテーブルには文字しか格納できない？ >例えばファイルをしまいたいならファイルサーバーを別に用意して >データベースにはファイルのパスを入れるとか？ BLOBというデータ突っ込める機能あるけど使わない方が良い ファイルパスを入れるのはとても良いやり方
158 24/01/29(月)21:05:50 No.1151751482
>俺はデータベース初心者 >SQLって普通のデータも格納できるの？（xlsxとかdwgとか） ほかは知らんけどORACLEならBLOB形式で保存できるしどれでもできるんじゃない？ 他サーバーでアップしたファイルを使用するときに楽なくらいだけど
159 24/01/29(月)21:05:54 No.1151751523
日付を数値型カラムで保存するのはまだ許す Nullの代わりに0を入れた奴は殺す
160 24/01/29(月)21:06:06 No.1151751621
>それともあくまでテーブルには文字しか格納できない？ バイナリは文字にできるんだ 文字はバイナリに戻せるんだ
161 24/01/29(月)21:06:08 No.1151751646
>「業務を意識したインデックス」ってテーブル設計の段階でわかるものなの？ >言われても画面もできてないのに正しい検索条件に貼れ言われても俺わからないんだけど？ せいぜいよく使われる外部キーに貼っとくぐらいだろその段階
162 24/01/29(月)21:06:11 No.1151751679
>「業務を意識したインデックス」ってテーブル設計の段階でわかるものなの？ >言われても画面もできてないのに正しい検索条件に貼れ言われても俺わからないんだけど？ まず業務ロジックの整理から始めます 現行の業務に精通してる人は誰だい？
163 24/01/29(月)21:06:20 No.1151751759
>「業務を意識したインデックス」ってテーブル設計の段階でわかるものなの？ >言われても画面もできてないのに正しい検索条件に貼れ言われても俺わからないんだけど？ 画面設計と同時にDB設計しない？ 逆にDB設計だけ先行してできるものなの
164 24/01/29(月)21:06:24 No.1151751796
BLOB系はもう皆S3とかに雑に投げる所多いイメージ
165 24/01/29(月)21:06:59 No.1151752088
>現行の業務に精通してる人は誰だい？ 先月辞めました！
166 24/01/29(月)21:07:10 No.1151752176
TRUNCATE TABLE IMG
167 24/01/29(月)21:07:11 No.1151752187
>Nullの代わりに0を入れた奴は殺す insertするときにnull入れるのって微妙にめんどいから0入れるほうが楽…
168 24/01/29(月)21:07:13 No.1151752215
ハゲで遊んでたのに真面目な話が始まってついていけない！！
169 24/01/29(月)21:07:17 No.1151752259
インデックスは張り過ぎもよくないので 一度設計して遅くて困ったらその実行計画を見てインデックス張るのがええ
170 24/01/29(月)21:07:21 No.1151752298
>まず業務ロジックの整理から始めます >現行の業務に精通してる人は誰だい？ ……
171 24/01/29(月)21:07:28 No.1151752385
BLOBそんな駄目なのか…
172 24/01/29(月)21:07:32 No.1151752428
ファイル扱う場合なんてどうせその中身をDBでどうこうすることないだろうから…ないよね？
173 24/01/29(月)21:08:06 No.1151752775
ING_USERSテーブルは今までのスレ立て回数とかもらったdel数が格納されてそうで嫌だ
174 24/01/29(月)21:08:07 No.1151752790
設計段階で完璧なINDEX張れって言う方が無茶だろ
175 24/01/29(月)21:08:09 No.1151752807
>BLOBそんな駄目なのか… DBがすぐにギガ単位に膨らむ ディスクが足りなくなって汲々とする
176 24/01/29(月)21:08:10 No.1151752818
>インデックスは張り過ぎもよくないので >一度設計して遅くて困ったらその実行計画を見てインデックス張るのがええ 本番始まってデータ増えてやっと遅いって発覚する事もあるし難しいね
177 24/01/29(月)21:08:14 No.1151752853
・SQL上で実行する関数 ・指定したレコードのデータをファイルサーバーから引っ張り出してくる ・APIと連携してデータを編集したあと再度元の場所に上書き保存する ってタスクを今日投げられたんだけど どう考えても俺のスキルに見合ってなくてお酒美味しい
178 24/01/29(月)21:08:20 No.1151752900
>インデックスは張り過ぎもよくないので >一度設計して遅くて困ったらその実行計画を見てインデックス張るのがええ インデックス張ってないと遅いから張りまくるぜー！
179 24/01/29(月)21:08:23 No.1151752931
>>Nullの代わりに0を入れた奴は殺す >insertするときにnull入れるのって微妙にめんどいから0入れるほうが楽… お前のような奴がいるから日付変換でエラーが出るんだこの野郎！！！
180 24/01/29(月)21:08:38 No.1151753048
俺はMySQL5.7マン！ 8.0でめっちゃ新しい構文増えてる…
181 24/01/29(月)21:08:43 No.1151753089
データベースはハードディスクではないからな…
182 24/01/29(月)21:09:08 No.1151753303
>BLOBそんな駄目なのか… DBの容量それだけ食うしSELECT結果も重くなるしでいいことない
183 24/01/29(月)21:09:10 No.1151753328
インデックスの容量設計難しい…
184 24/01/29(月)21:09:20 No.1151753409
仕事じゃなければAIくんそれっぽく書いてって言った方が楽なんだが…
185 24/01/29(月)21:09:32 No.1151753501
主キーはナチュラルとサロゲートどっちが良いのか サロゲートならオートインクリメントとuuidどっちがいいのか
186 24/01/29(月)21:09:42 No.1151753596
とりあえずインデックスを効かせればいいんだろ？了解！追加追加！
187 24/01/29(月)21:10:11 No.1151753827
>・SQL上で実行する関数 ストアドプロシージャのこと？
188 24/01/29(月)21:10:16 No.1151753865
>データベースはハードディスクではないからな… ちょっと前のRDBはファイルシステムの特殊な形式なのかそれとも逆なのかって議論あったの思い出した
189 24/01/29(月)21:10:22 No.1151753928
select * from hage where 1=1
190 24/01/29(月)21:10:29 No.1151754001
SQL何度挫折したか
191 24/01/29(月)21:10:31 No.1151754012
SELECT hanji_night_cnt FROM img_users
192 24/01/29(月)21:10:47 No.1151754166
>主キーはナチュラルとサロゲートどっちが良いのか >サロゲートならオートインクリメントとuuidどっちがいいのか 宗教論争になるけど 大体の場合は時系列順に並べておいたほうが効率いいからオートインクリメントがええ！
193 24/01/29(月)21:10:49 No.1151754194
DB読み込む側の言語でも違うんだろうけど1行の容量増えるとGBとかメモリ周り怪しくなることがちょくちょくあるんだよな
194 24/01/29(月)21:11:11 No.1151754377
>SQL何度挫折したか 構文覚えるより集合論を先に勉強するのが早いと思う
195 24/01/29(月)21:11:25 No.1151754507
>主キーはナチュラルとサロゲートどっちが良いのか どっちの方がいいとか無い気がする どっちも使ってるわ
196 24/01/29(月)21:11:30 No.1151754553
SQLハンブンクライワカル
197 24/01/29(月)21:11:33 No.1151754583
件数多すぎて処理結果が帰ってこないなんて話をなんで今の段階になって言うんだ！！！
198 24/01/29(月)21:11:54 No.1151754761
>DB読み込む側の言語でも違うんだろうけど1行の容量増えるとGBとかメモリ周り怪しくなることがちょくちょくあるんだよな n倍のパワーを感じる
199 24/01/29(月)21:12:06 No.1151754870
型変換とか表の整形とか可能な限りDBMS側でやった方が速いのはわかるんだ でもめんどくさいからアプリ側でループ回してコネコネするね…うわ遅ッ！
200 24/01/29(月)21:12:43 No.1151755197
主キーをuuidにするときは気をつけろよ！ https://techblog.raccoon.ne.jp/archives/1627262796.html
201 24/01/29(月)21:12:55 No.1151755287
>ING_USERSテーブルは今までのスレ立て回数とかもらったdel数が格納されてそうで嫌だ レスの要旨と関係ない話ごめんなんだけど カラムとかテーブルのスペルミスって運用開始したら諦めるしかないよね 忘れた頃の保守作業でselect文叩いてエラーなるのムカつく！
202 24/01/29(月)21:12:59 No.1151755333
狂ったように長いカラム名になるくらいならローマ字を使った方がいいのでは？と思ったこと幾星霜
203 24/01/29(月)21:13:04 No.1151755375
vimは至高
204 24/01/29(月)21:13:07 No.1151755400
このスレ文で真面目な話になるとは
205 24/01/29(月)21:13:08 No.1151755406
>SQLハンブンクライワカル 超人か？
206 24/01/29(月)21:13:10 No.1151755435
INSERT文が無いのは「」が童貞だから？
207 24/01/29(月)21:13:28 No.1151755623
>select * from hage where 1=1 where句いらねえ
208 24/01/29(月)21:13:38 No.1151755719
(なんだこの数百行を超えるクエリは…どこからチューニングすればいいのだ…)
209 24/01/29(月)21:13:39 No.1151755726
num_hairs_headはtinyint…いやbitで十分だな…
210 24/01/29(月)21:14:10 No.1151755946
>n倍のパワーを感じる 前に1レコードの項目ごとのbyte数を計算したことがあってクソがよぉ…ってなったの思い出した
211 24/01/29(月)21:14:13 No.1151755983
truncate img_users
212 24/01/29(月)21:14:13 No.1151755990
>SQLハンブンクライワカル 神は急に降臨しないでくれ
213 24/01/29(月)21:14:13 No.1151755993
>>SQL何度挫折したか >構文覚えるより集合論を先に勉強するのが早いと思う 完成済みのを数多く見て理解するのが一番早い 自分で考えるより引き出しを増やす方が楽だ…
214 24/01/29(月)21:14:14 No.1151756003
>(なんだこの数百行を超えるクエリは…どこからチューニングすればいいのだ…) （しかもインデントがめちゃくちゃだ…）
215 24/01/29(月)21:14:16 No.1151756023
>ストアドプロシージャのこと？ DBMS上でデータ処理を行いたいらしい 一回ダウンロードしてからコネコネしてもそんな違わないだろ…って思ってる たかが数秒…
216 24/01/29(月)21:14:23 No.1151756074
datagripというGUIクライアントを愛用してるけど 使っている人が少ない…便利なのに
217 24/01/29(月)21:14:36 No.1151756174
>たかが数秒… 数千ミリ秒をたかが！？
218 24/01/29(月)21:14:39 No.1151756195
>大体の場合は時系列順に並べておいたほうが効率いいからオートインクリメントがええ！ >どっちも使ってるわ 結局用途に応じて使い分けか どっち採用するか判断できるようになるのはいつになることやら...
219 24/01/29(月)21:14:59 No.1151756358
>たかが数秒… おっそ！
220 24/01/29(月)21:15:00 No.1151756369
次のデスペは合格するから…
221 24/01/29(月)21:15:03 No.1151756385
>狂ったように長いカラム名になるくらいならローマ字を使った方がいいのでは？と思ったこと幾星霜 実際もう漢字使っていいよ SQLの視認性がめっちゃよくなるぜ
222 24/01/29(月)21:15:06 No.1151756404
日本の用語なら普通に日本語使ったほうがいいの多々ある
223 24/01/29(月)21:15:07 No.1151756421
pgadmin4はなんであんなに情報少ないの…需要ないの…
224 24/01/29(月)21:15:08 No.1151756431
てか今更だけどIDって何と紐づいてるんだろうね
225 24/01/29(月)21:15:11 No.1151756445
SQLは文法的に入れ子の入れ子になるから見づらくてかなわん
226 24/01/29(月)21:15:30 No.1151756601
>狂ったように長いカラム名になるくらいならローマ字を使った方がいいのでは？と思ったこと幾星霜 ローマ字ならまだいい カラム名→KARAMUMEI→KRMMIとかやられると後から使う時わけわかんねえんだ
227 24/01/29(月)21:15:34 No.1151756640
>>>SQL何度挫折したか >>構文覚えるより集合論を先に勉強するのが早いと思う >完成済みのを数多く見て理解するのが一番早い >自分で考えるより引き出しを増やす方が楽だ… (この世の終わりみたいなDB)
228 24/01/29(月)21:15:44 No.1151756728
>>n倍のパワーを感じる >前に1レコードの項目ごとのbyte数を計算したことがあってクソがよぉ…ってなったの思い出した 全銀システムがぶっ壊れた理由もこんな感じだったのかな
229 24/01/29(月)21:15:44 No.1151756736
>>狂ったように長いカラム名になるくらいならローマ字を使った方がいいのでは？と思ったこと幾星霜 >実際もう漢字使っていいよ >SQLの視認性がめっちゃよくなるぜ SQLServerの時は日本語カラム名にしてるな
230 24/01/29(月)21:15:54 No.1151756820
>てか今更だけどIDって何と紐づいてるんだろうね IDからまたなんかに紐付いてるのいやだ…
231 24/01/29(月)21:16:09 No.1151756964
俺はCOUNTの代わりにCUNTを使うマン！ いまのところばれてない
232 24/01/29(月)21:16:19 No.1151757065
KBN
233 24/01/29(月)21:16:20 No.1151757079
バッチ処理ならいいんじゃないの 画面でやるなら0.2秒止まると人間は認識できるので操作ごとにちょくちょく止まると俺はストレスで発狂する
234 24/01/29(月)21:16:37 No.1151757218
JOIN句あれ見づらくない？みんなよく普通に読めるな
235 24/01/29(月)21:16:38 No.1151757232
>俺はCOUNTの代わりにCUNTを使うマン！ >いまのところばれてない そこまで来るならcntでいいのでは？
236 24/01/29(月)21:16:39 No.1151757239
>俺はCOUNTの代わりにCUNTを使うマン！ >いまのところばれてない CUNTでググったら茶吹いたぞ
237 24/01/29(月)21:16:43 No.1151757269
こんな書き方できんの！？みたいなマニュアルに乗ってない文法がたまにあるのなんなの
238 24/01/29(月)21:16:44 No.1151757282
1秒超えるとつらい
239 24/01/29(月)21:16:48 No.1151757316
SQLというかテーブルデータで難しいのってJOIN関係くらいな気がする あとはフィルタリングするだけだし
240 24/01/29(月)21:16:56 No.1151757416
>そこまで来るならcntでいいのでは？ 違うそうじゃない
241 24/01/29(月)21:17:04 No.1151757483
>そこまで来るならcntでいいのでは？ cunt＝女性器
242 24/01/29(月)21:17:22 No.1151757657
>>そこまで来るならcntでいいのでは？ >cunt＝女性器 さいていすぎる…
243 24/01/29(月)21:17:29 No.1151757724
influxだったか時系列DBがまったく理解できないし使い道も想像できない エクセルで例えると何の何？
244 24/01/29(月)21:17:40 No.1151757824
>SQLは文法的に入れ子の入れ子になるから見づらくてかなわん 使えるときはWITH使うんだけど繰り返し使わないのに使うのもなあ…ってちょっと考えちゃう
245 24/01/29(月)21:17:41 No.1151757830
>>俺はCOUNTの代わりにCUNTを使うマン！ >>いまのところばれてない >CUNTでググったら茶吹いたぞ https://www.infiniteloop.co.jp/tech-blog/2021/09/unko/ これ思い出した
246 24/01/29(月)21:17:45 No.1151757871
select tegaki_data from img_db where enable_flag=1 and category='openis'
247 24/01/29(月)21:17:55 No.1151757967
>influxだったか時系列DBがまったく理解できないし使い道も想像できない >エクセルで例えると何の何？ 年表
248 24/01/29(月)21:18:32 No.1151758324
>influxだったか時系列DBがまったく理解できないし使い道も想像できない 時系列データ、例えばログやメトリクスを突っ込むのに向いている >エクセルで例えると何の何？ 何でもエクセルに例えるのをやめろ
249 24/01/29(月)21:18:33 No.1151758336
じゃあ「」はER図引いてくれるのかよ
250 24/01/29(月)21:18:33 No.1151758343
開いてないけどうんこ 開いてうんこ
251 24/01/29(月)21:18:37 No.1151758381
update 「」 set touhatu =null;
252 24/01/29(月)21:19:05 No.1151758610
FLAGとFLGがテーブルによってバラバラ…！ ENABLEとENABLEDがテーブルによってバラバラ…！
253 24/01/29(月)21:19:13 No.1151758679
joinは楽しい
254 24/01/29(月)21:19:15 No.1151758692
FROM句から書かせてくれっていつも思ってる
255 24/01/29(月)21:19:19 No.1151758729
>じゃあ「」はER図引いてくれるのかよ えっあれって人力で作るものなの...？
256 24/01/29(月)21:19:22 No.1151758755
>じゃあ「」はER図引いてくれるのかよ なんで匿名掲示板に来てまで仕事しなきゃいけないんだよ
257 24/01/29(月)21:19:24 No.1151758773
CASE文使いにくいし読みにくいから改善されてくれないかなあ CASEの入れ子とかもう読めないんだよ
258 24/01/29(月)21:19:58 No.1151759126
>CASE文使いにくいし読みにくいから改善されてくれないかなあ >CASEの入れ子とかもう読めないんだよ ふえーんってなるよね
259 24/01/29(月)21:20:02 No.1151759164
>じゃあ「」はER図引いてくれるのかよ じゃあ要件確認は任せた！
260 24/01/29(月)21:20:10 No.1151759237
>じゃあ「」はER図引いてくれるのかよ メンテしなくていいなら…
261 24/01/29(月)21:20:12 No.1151759254
img_usersだのimg_dbだの似たようなテーブルがサーバー分並んでると思うときついわあ
262 24/01/29(月)21:20:59 No.1151759638
CASE文は縦列と横列逆にしてくれって言われた時に役に立つ
263 24/01/29(月)21:21:07 No.1151759729
where 1=1;
264 24/01/29(月)21:21:08 No.1151759744
業務的にいろんなDB渡り歩くけど これが整理されてる会社は偉いなって思う
265 24/01/29(月)21:21:12 No.1151759799
>CASE文使いにくいし読みにくいから改善されてくれないかなあ >CASEの入れ子とかもう読めないんだよ CASE文サポートしてないDBで同じもん書いたらマジ死ぬから全然楽な方だよ…
266 24/01/29(月)21:21:21 No.1151759905
大抵の書き方はもう受け入れるけど文字列連結でSQL書くのだけはやめてくれないかな…
267 24/01/29(月)21:21:24 No.1151759942
WITHさえ使いこなせば訳のわからん黒魔術の殆どは駆逐できるはずなんだ
268 24/01/29(月)21:21:46 No.1151760152
やっぱDBやクエリイジるの好きなんだなとスレ見て改めて実感してしまった…
269 24/01/29(月)21:21:58 No.1151760274
コードを綺麗に書く方法的なの何冊か読んで実践した結論として その方法を認めさせる根回しが一番大事
270 24/01/29(月)21:22:00 No.1151760289
>FLAGとFLGがテーブルによってバラバラ…！ >ENABLEとENABLEDがテーブルによってバラバラ…！ FLUGとかタイポするぐらいならFLGでいいから…！
271 24/01/29(月)21:22:02 No.1151760316
truncate table hair
272 24/01/29(月)21:22:13 No.1151760428
>WITHさえ使いこなせば訳のわからん黒魔術の殆どは駆逐できるはずなんだ カレンダーとか一発で作れて便利だよね
273 24/01/29(月)21:22:36 No.1151760632
時間がないので既存の流用します！バグりました！
274 24/01/29(月)21:22:39 No.1151760666
>WITHさえ使いこなせば訳のわからん黒魔術の殆どは駆逐できるはずなんだ WITHの時点で適切にフィルター掛けられないとあれって重くなるんじゃないの？ 怖くて全然使えないわ
275 24/01/29(月)21:22:41 No.1151760693
>WITHさえ使いこなせば訳のわからん黒魔術の殆どは駆逐できるはずなんだ うちだとWITHなんかわかりにくいって忌避されるんだけどそんな悪いもんかねアレ？
276 24/01/29(月)21:22:53 No.1151760812
>img_usersだのimg_dbだの似たようなテーブルがサーバー分並んでると思うときついわあ ここにユーザー情報を管理するテーブルがあるとは思えない
277 24/01/29(月)21:23:01 No.1151760874
SQLって条件Aかつ条件Bかつ…って続く場合ぜんぶ律儀に書かなきゃだめ？なんか楽する方法ない？
278 24/01/29(月)21:23:16 No.1151761004
WITHで黒魔術が駆逐されるかはわからないけどないよりあったほうが絶対いい
279 24/01/29(月)21:23:28 No.1151761131
select name from user_tbl; name --- 'Hoge' Null 'null'
280 24/01/29(月)21:23:31 No.1151761159
入れ子よりは遥かにマシかなWITH ストレートに書くと書いてる方も訳分かんなくなるからね
281 24/01/29(月)21:23:48 No.1151761317
union all←これきらい
282 24/01/29(月)21:23:59 No.1151761446
>うちだとWITHなんかわかりにくいって忌避されるんだけどそんな悪いもんかねアレ？ ネストするより可読性高くて良いと思う
283 24/01/29(月)21:24:16 No.1151761612
NULLを駆逐せよ
284 24/01/29(月)21:24:33 No.1151761752
大文字のほうが早いのって都市伝説？
285 24/01/29(月)21:24:38 No.1151761796
if文がネストしてたら関数分けるじゃん？ そんぐらいカジュアルにWITHに切り出して良いかと
286 24/01/29(月)21:24:47 No.1151761870
WITH RECURSIVE使えるようになるとウヒョーってなる
287 24/01/29(月)21:24:49 No.1151761889
>union all←これきらい むしろallつかないunion使ったことないな
288 24/01/29(月)21:25:06 No.1151762051
>truncate table hair exception rollback; end