ここでは虹裏imgのかなり古い過去ログを閲覧することができます。
22/03/27(日)18:37:34 No.910786866
SQLアンチパターンをポチった これで俺もﾁﾖｯﾄﾃﾞｷﾙマンになれるかな
1 22/03/27(日)18:38:18 No.910787138
例えばどんなのが乗ってるの？
2 22/03/27(日)18:39:19 No.910787553
まだ届いてないから分からん
3 22/03/27(日)18:42:58 No.910788959
SQLアンチスレかと思った
4 22/03/27(日)18:43:41 No.910789236
実は読んだことないから俺も読もうかな
5 22/03/27(日)18:44:22 No.910789471
読んでみたいけど今までにやってきた事が否定されたら辛い
6 22/03/27(日)18:47:10 No.910790461
読んだような気がする 確かいい本だったような気がする
7 22/03/27(日)18:50:08 No.910791528
データベース初心者が勉強するのにオススメのSQLの参考書とかってある？ ちょっとやってみたい
8 22/03/27(日)18:51:43 No.910792093
読めば腕は上がると思う ただ人の書いたSQLにイライラすることも増える
9 22/03/27(日)18:53:21 No.910792693
>読めば腕は上がると思う >ただ人の書いたSQLにイライラすることも増える 自分がDB設計する立場にでもならなければどうにもならないこと多いよね…
10 22/03/27(日)18:54:02 No.910792943
>データベース初心者が勉強するのにオススメのSQLの参考書とかってある？ >ちょっとやってみたい ゼロからはじめるデータベース操作って奴は取っつきやすいと思う
11 22/03/27(日)18:54:43 No.910793202
>データベース初心者が勉強するのにオススメのSQLの参考書とかってある？ ウチは親友社員にSQLアンチパターンとプログラマのためのSQLを読ませてる
12 22/03/27(日)18:54:51 No.910793250
理論から学ぶデータベース実践入門は結構好きだった記憶がある なんか結構叩かれてた
13 22/03/27(日)18:55:33 No.910793493
バイナリデータをDBに格納するのはどうかと思うが推奨されてるんだよな
14 22/03/27(日)18:55:47 No.910793581
>自分がDB設計する立場にでもならなければどうにもならないこと多いよね… 正しく文句言ってたらそのうちテーブル書くようになるよ
15 22/03/27(日)18:57:37 No.910794234
>データベース初心者が勉強するのにオススメのSQLの参考書とかってある？ >ちょっとやってみたい データサイエンス100本ノックSQL編とか
16 22/03/27(日)18:57:56 No.910794336
それアンチパターンなんですけおおおおおお！！！！！！！ ってならないように注意しようね…
17 22/03/27(日)18:58:12 No.910794440
>バイナリデータをDBに格納するのはどうかと思うが推奨されてるんだよな そこはお好みでとしかいいようがない…
18 22/03/27(日)18:58:48 No.910794661
軽くググって評価見たけど結構いい内容書いてるね 自分もポチる
19 22/03/27(日)18:58:58 No.910794724
バイナリデータ含むテーブルがあるとテスト面倒なんだよな…
20 22/03/27(日)18:59:20 No.910794865
バイナリを入れるかは環境によるとしか… S3とかGCSとか使う前提ならそっちに入れた方がいいと思うな…
21 22/03/27(日)18:59:35 No.910794964
>それアンチパターンなんですけおおおおおお！！！！！！！ >ってならないように注意しようね… むしろそんな宗教的な内容はアンチパターンにならないよ…
22 22/03/27(日)19:00:04 No.910795159
>バイナリデータをDBに格納するのはどうかと思うが推奨されてるんだよな oracleアプリケーション表領域モデルに従って表領域は分けるようにしてる
23 22/03/27(日)19:00:54 No.910795474
>ゼロからはじめるデータベース操作って奴は取っつきやすいと思う >ウチは親友社員にSQLアンチパターンとプログラマのためのSQLを読ませてる >データサイエンス100本ノックSQL編とか ありがとう参考にするよ キリンさんの表紙のやつとかザ・初心者向けって感じで良さそうだ
24 22/03/27(日)19:01:01 No.910795519
EAVがアンチパターンなのはわかるけど業務内容がきれいに定義できないとああせざるをえなかったりする 業務内容を整理しろ！！
25 22/03/27(日)19:01:53 No.910795875
読んでないけど予備1,予備2,…予備10みたいな列つくるのやめろ的なことが書いてあると思う
26 22/03/27(日)19:03:07 No.910796349
>バイナリデータをDBに格納するのはどうかと思うが推奨されてるんだよな むしろ今時はblobあたり前に使うね 管理する点多くなると完全性壊れてバグになりうる
27 22/03/27(日)19:03:14 No.910796392
SQLウンチパターン
28 22/03/27(日)19:03:29 No.910796502
>読んでないけどhizuke char(8)みたいな列つくるのやめろ的なことが書いてあると思う
29 22/03/27(日)19:04:03 No.910796719
>EAVがアンチパターンなのはわかるけど業務内容がきれいに定義できないとああせざるをえなかったりする >業務内容を整理しろ！！ データ要件が開発中に変わり得るならJSONカラムで良くない？と思ったりする
30 22/03/27(日)19:04:47 No.910796986
>読んでないけどサブクエリ４段はやめろ的なことが書いてあると思う
31 22/03/27(日)19:05:12 No.910797143
>読んでないけど予備1,予備2,…予備10みたいな列つくるのやめろ的なことが書いてあると思う 大手ERPパッケージは実装されてるけど良いか悪いかは別だしな
32 22/03/27(日)19:05:21 No.910797193
>データ要件が開発中に変わり得るならJSONカラムで良くない？と思ったりする 若者のレス
33 22/03/27(日)19:05:53 No.910797387
>データ要件が開発中に変わり得るならJSONカラムで良くない？と思ったりする JSONのまま格納されると特定属性の検索が面倒だし…
34 22/03/27(日)19:05:54 No.910797394
100本ノックは入門と業務の中間埋めるやつだからオススメだよ
35 22/03/27(日)19:06:09 No.910797495
時代はWITH句だ ネストしたサブクエリは読む気がしない
36 22/03/27(日)19:07:12 No.910797884
100本ノックは手を動かしながら分かりたい人はおすすめかもしれない
37 22/03/27(日)19:07:54 No.910798174
痛くなければ覚えませぬ
38 22/03/27(日)19:07:58 No.910798206
>JSONのまま格納されると特定属性の検索が面倒だし… やっぱXMLでXPathだよな！
39 22/03/27(日)19:08:45 No.910798526
>やっぱXMLでXPathだよな！ 5年に一度くらい使う機会があってそのたびに使い方調べるやつ来たな…
40 22/03/27(日)19:09:09 No.910798674
まあ正直仕様変更恐れずにテーブルガンガン変える方式でいいと思うよ… 最初からデータ完全性そんなに重要ならそもそも変更するなって話だし
41 22/03/27(日)19:09:22 No.910798756
セルコって名前だけ覚えてたけどそれがプログラマのためのSQLか
42 22/03/27(日)19:09:58 No.910799042
>SQLアンチスレかと思った 誰が寄り付くんだよそんなスレ…
43 22/03/27(日)19:10:29 No.910799242
>まあ正直仕様変更恐れずにテーブルガンガン変える 方式でいいと思うよ… 俺もそう思う 最初から要件がガチガチに決められて変更がないなんて実際あり得ないし、そういう前提でもの作るのが辛すぎる…
44 22/03/27(日)19:11:09 No.910799533
>5年に一度くらい使う機会があってそのたびに使い方調べるやつ来たな… 実は今のブラウザ実装だと標準で使えて CSSセレクタの実装の弱さの問題で結構使う頻度あるんだよね… テキストのスクレイピング必要な時に今でもよく使ってるよ
45 22/03/27(日)19:11:16 No.910799583
>誰が寄り付くんだよそんなスレ… SQLアンチ、結構いない？
46 22/03/27(日)19:12:30 No.910800072
>誰が寄り付くんだよそんなスレ… エクセルの方が売上もシェアも高いから強いんですけお！！
47 22/03/27(日)19:13:02 No.910800279
>SQLアンチ、結構いない？ SQLアンチパターンアンチとか すごい効率悪いスパゲッティSQLアンチならしばしば見る 大体誰かの書いた後始末をさせられてる
48 22/03/27(日)19:13:12 No.910800347
>テキストのスクレイピング必要な時に今でもよく使ってるよ 根本的にスクレイピング自体が辛いからXPathが辛いのかスクレイピング辛いのかわから無くなるやつ来たな…
49 22/03/27(日)19:13:22 No.910800411
触れずにいられるなら触れたくないくらいにはアンチ！
50 22/03/27(日)19:14:38 No.910800934
まともに正規化されてないDBで運用してる案件とかごろごろあるからな
51 22/03/27(日)19:15:23 No.910801226
表形式データを扱うのにSELECT文の形式が優秀すぎるというか ほぼ必要最低限の書き方でデータ抽出できるから手放せない
52 22/03/27(日)19:15:53 No.910801438
正規化いる？
53 22/03/27(日)19:16:27 No.910801659
実行計画の読み方すぐ忘れる
54 22/03/27(日)19:16:40 No.910801763
SELECT文書くときに*のほかに* without nameみたいな構文が欲しい 大体全部の列ほしいけどこの列だけ弾きたい、みたいなことが多くて辛い
55 22/03/27(日)19:17:01 No.910801906
正規化は程々に要る
56 22/03/27(日)19:17:50 No.910802233
>根本的にスクレイピング自体が辛いからXPathが辛いのかスクレイピング辛いのかわから無くなるやつ来たな… まあそうなんだがXPathなら細かい条件複数付けられるしArrayでくれるし… querySelectorAllだと属性だけで取れるなら良いけど値とかテキストマッチはかなり辛い
57 22/03/27(日)19:18:07 No.910802351
プログラマのためのSQL渡して読める新入社員はうちには入ってきそうも無いわ…
58 22/03/27(日)19:18:44 No.910802613
「」は頭がいいから喧嘩しないと思うけど ナチュラルキーとサロゲートキーはどっちがいいの
59 22/03/27(日)19:18:46 No.910802631
>querySelectorAllだと属性だけで取れるなら良いけど値とかテキストマッチはかなり辛い アプリケーションレベルならquerySelectorAllしてfilterするのが一番手っ取り早そう
60 22/03/27(日)19:20:00 No.910803151
>プログラマのためのSQL渡して読める新入社員はうちには入ってきそうも無いわ… SQLだけなら習得すぐじゃない？ パフォーマンスは知らない
61 22/03/27(日)19:20:09 No.910803206
>ナチュラルキーとサロゲートキーはどっちがいいの 俺の名はナチュラルキーで外部キーにするマン
62 22/03/27(日)19:20:15 No.910803255
>SELECT文書くときに*のほかに* without nameみたいな構文が欲しい >大体全部の列ほしいけどこの列だけ弾きたい、みたいなことが多くて辛い カラム増やした時にその記法使ってるクライアント側で絶対事故の原因になるのでやめてくだち！ 順番がずれて意図しない値が変数に入るんでしょ？知ってるんだから！
63 22/03/27(日)19:21:04 No.910803540
手でのSQL発行ならともかく*は避けた方が無難だぞ！
64 22/03/27(日)19:21:04 No.910803542
SQLでないがORMがなんか受け付けない
65 22/03/27(日)19:21:27 No.910803699
あーもうRDB設計面倒くせえ！ NoSQLでいいですか？いいですよね？ でゴリ押ししたプロジェクトがいくつかある まあ問題なく動いてるのでセーフ！
66 22/03/27(日)19:21:30 No.910803722
>「」は頭がいいから喧嘩しないと思うけど >ナチュラルキーとサロゲートキーはどっちがいいの 一意に識別するための値が後から変更可能な前提でない限りはナチュラルキーかな…
67 22/03/27(日)19:21:35 No.910803754
汎用テーブルを作るのは止めてほしい どの行が何のデータなのかさっぱりわからん
68 22/03/27(日)19:22:27 No.910804092
必要ならSQLは書くけど性能とか全然分からないマン… 勉強しなきゃ…
69 22/03/27(日)19:22:42 No.910804197
>汎用テーブルを作るのは止めてほしい 汎用テーブルって何…？いや大体想像はつくんだがそれこそNoSQLにでもぶち込んどけばよさそうなあ
70 22/03/27(日)19:22:45 No.910804227
>あーもうRDB設計面倒くせえ！ >NoSQLでいいですか？いいですよね？ >でゴリ押ししたプロジェクトがいくつかある >まあ問題なく動いてるのでセーフ！ またNoSQLの意味勘違いしてる奴が出た！
71 22/03/27(日)19:23:04 No.910804360
実行計画取ってFullScanしてないヨシ！ チューニングなんてそれでいいんだよ…
72 22/03/27(日)19:23:17 No.910804455
>ナチュラルキーとサロゲートキーはどっちがいいの サロゲートキーをPKでナチュラルキーをユニークキーにする
73 22/03/27(日)19:23:29 No.910804536
性能なんざ物理で殴れ
74 22/03/27(日)19:23:30 No.910804546
NoSQL未だに使ったことないマン！
75 22/03/27(日)19:23:40 No.910804622
ゴリゴリにチューンするほどの性能が必要かっていうとない場合のほうが多い
76 22/03/27(日)19:23:52 No.910804705
弊社はWHERE句の条件が増えるたびにインデックスを追加する社！ 1テーブルで15個くらいインデックス付けてもINSERT意外と遅くならないな？
77 22/03/27(日)19:23:53 No.910804709
>手でのSQL発行ならともかく*は避けた方が無難だぞ！ 想定以外のSELECT列が必要な状況なんて普通はないからな…
78 22/03/27(日)19:24:07 No.910804795
チューニングなんてDBファイルとハードとインデックスさえ気をつければいいよ サブクエリやめろ
79 22/03/27(日)19:24:29 No.910804941
>性能なんざ物理で殴れ 業績が下がってるからOracleは安いのにします
80 22/03/27(日)19:24:42 No.910805040
>弊社はWHERE句の条件が増えるたびにインデックスを追加する社！ ちゃんとexplainしてIndex追加してて偉い！
81 22/03/27(日)19:24:50 No.910805108
hogehogeflagみたいな名前で値は整数値が入って0～3で意味が変わるみたいなのがあるとお前は何のために生まれてきたんだってなる まずフラグじゃないじゃん
82 22/03/27(日)19:24:54 No.910805132
nosqlはキャッシュでしか使ったこと無いなあ
83 22/03/27(日)19:24:58 No.910805155
>汎用テーブルって何…？いや大体想像はつくんだがそれこそNoSQLにでもぶち込んどけばよさそうなあ コード値入れる列の値でそれ以降の列の登録内容が変わるぞ！ いちいち設計するのめんどくさいから逃げた結果なんだと思ってる
84 22/03/27(日)19:25:08 No.910805244
Not Only SQLです！ No SQLではなく！
85 22/03/27(日)19:26:17 No.910805663
NoSQLのことをとりあえず何もテーブル定義しなくてもINSERTできるDBだと思ってるそこの君！ 大体合ってるけど主キー以外を絞り込み条件に使えるとは思わないことだな！
86 22/03/27(日)19:26:22 No.910805700
よくわからないけどお客さんがすっごい拘るからmongo使ったことあるけどよくわからない
87 22/03/27(日)19:26:40 No.910805827
大規模移行に伴うindexの付与と削除のタイミングを設計して顧客に説明すんのめんどくせぇ～…
88 22/03/27(日)19:26:44 No.910805857
意外とエンジニアあき多いのな
89 22/03/27(日)19:27:11 No.910806001
>意外とエンジニアあき多いのな 鯖依存語を投げるな
90 22/03/27(日)19:27:17 No.910806038
ﾁｮﾄﾃﾞｷﾙの理解がまず足りてないんじゃないか…？
91 22/03/27(日)19:27:24 No.910806078
DBがクソなパターンだいたい業務設計がクソ 設計時はこの条件で検索することないって言ってたけど嘘だったわめっちゃ検索するしレコードも想定の100倍入ってくるんだけど来週までによろしくとか言われる
92 22/03/27(日)19:27:36 No.910806150
マシンのスペックが今よりだいぶしょぼい頃に書かれてるやつだと逆にアンチパターンになっちゃってたりするから気をつけようね
93 22/03/27(日)19:27:48 No.910806240
>意外とエンジニアあき多いのな サーバー違いますよ
94 22/03/27(日)19:28:21 No.910806429
>鯖依存語を投げるな わろた
95 22/03/27(日)19:28:39 No.910806553
予備列作んなくてもいいけど仕様変更も絶対するんじゃねえぞ
96 22/03/27(日)19:28:50 No.910806629
JSONでくれ
97 22/03/27(日)19:28:56 No.910806666
>ﾁｮﾄﾃﾞｷﾙの理解がまず足りてないんじゃないか…？ ﾁｮﾄﾃﾞｷﾙの前段階の完全に理解した状態で止まっていることが多くてすまない…
98 22/03/27(日)19:29:08 No.910806748
ターミナルで複数タブ開いててちょっと操作するサーバ間違えちゃうのいいよね…
99 22/03/27(日)19:29:17 No.910806792
>>ﾁｮﾄﾃﾞｷﾙの理解がまず足りてないんじゃないか…？ >ﾁｮﾄﾃﾞｷﾙの前段階の完全に理解した状態で止まっていることが多くてすまない… 完全に理解できてるのはすげーよ・・・
100 22/03/27(日)19:29:17 No.910806801
>予備列作んなくてもいいけど仕様変更も絶対するんじゃねえぞ 仕様変更を謎の予備列で吸収しようとする開発の業務フローが頭おかしいとしか言えない
101 22/03/27(日)19:29:32 No.910806889
>鯖依存語を投げるな 方言とか何も分からない…… MySQLとPostgreSQLだけで生きている
102 22/03/27(日)19:29:35 No.910806904
>JSONでくれ .txtをくらえ！
103 22/03/27(日)19:30:09 No.910807121
>ターミナルで複数タブ開いててちょっと操作するサーバ間違えちゃうのいいよね… 昔本番のテーブルDROPしたことあってな… バックアップと差分のログから戻したよ 褒めて 職場でちょっとチビった
104 22/03/27(日)19:30:19 No.910807194
あるべき論だから現場じゃあんまり役に立たないよね メンバー全員が知ってたら別だけど
105 22/03/27(日)19:30:31 No.910807271
>>鯖依存語を投げるな >方言とか何も分からない…… >OracleとSQL Serverとあと何種類かだけで生きている
106 22/03/27(日)19:31:15 No.910807554
もうチューニングで時間かけるのは嫌なんだ… お金で解決することにしたよ
107 22/03/27(日)19:31:30 No.910807650
>あるべき論だから現場じゃあんまり役に立たないよね >メンバー全員が知ってたら別だけど それはそれとして勉強はしておいてもよい
108 22/03/27(日)19:31:33 No.910807675
>あるべき論だから現場じゃあんまり役に立たないよね >メンバー全員が知ってたら別だけど アンチパターンじゃね？って突っ込んでもこれ以外に実現方法ないし…で押し切られたりする
109 22/03/27(日)19:31:56 No.910807841
ぽまいらDB定義をエクセルで書きなさい
110 22/03/27(日)19:32:11 No.910807950
後になってからJSON入ってるテーブル同士で結合して検索したいとか馬鹿みたいなこと言わなきゃJSONで入れていいよ
111 22/03/27(日)19:32:20 No.910807998
>アンチパターンじゃね？って突っ込んでもこれ以外に実現方法ないし…で押し切られたりする 見事な解決法を提示すれば良いのだ
112 22/03/27(日)19:32:28 No.910808053
>完全に理解できてるのはすげーよ・・・ 学んだばかりの時は完全に理解したわ（してない）って気分にならない？
113 22/03/27(日)19:32:37 No.910808104
あるべき論って小手先が通じなくて上に報告して上が理解力あった時にしか発動しないよね
114 22/03/27(日)19:33:08 No.910808305
JSONで保持してるDBから一旦抽出して適当なRDBに放り込んでからお好きなようにすればいいんじゃないの？
115 22/03/27(日)19:34:11 No.910808718
>JSONで保持してるDBから一旦抽出して適当なRDBに放り込んでからお好きなようにすればいいんじゃないの？ DBサーバーを気軽に立てられる富者の発想！
116 22/03/27(日)19:34:18 No.910808759
>JSONで保持してるDBから一旦抽出して適当なRDBに放り込んでからお好きなようにすればいいんじゃないの？ なるほどその方法で頼む じゃあ今からリアルタイムに書き換えられているこの3TBのデータを今すぐRDBに入れて検索させてくれ
117 22/03/27(日)19:34:24 No.910808812
仕方なくアンチパターンを使うのはままあるので痛みと共に受け入れるしかない
118 22/03/27(日)19:34:31 No.910808880
代案無しでアンチパターンと言うだけではどうしようもないし
119 22/03/27(日)19:35:06 No.910809124
DBってのはそんなホイホイ簡単に動けないんだよ
120 22/03/27(日)19:35:12 No.910809158
>じゃあ今からリアルタイムに書き換えられているこの3TBのデータを今すぐRDBに入れて検索させてくれ まず必要なものとそうじゃないものを分けましょう
121 22/03/27(日)19:35:28 No.910809279
>じゃあ今からリアルタイムに書き換えられているこの3TBのデータを今すぐRDBに入れて検索させてくれ なにそのマウント…
122 22/03/27(日)19:35:34 No.910809318
検索だけElasticsearchでやるのがわりとよくある
123 22/03/27(日)19:35:40 No.910809344
>代案無しでアンチパターンと言うだけではどうしようもないし ケツは決まってるしより現在か将来がより楽になる提案ができなければな…
124 22/03/27(日)19:35:43 No.910809370
>まあ正直仕様変更恐れずにテーブルガンガン変える方式でいいと思うよ… >最初からデータ完全性そんなに重要ならそもそも変更するなって話だし でもねその方式の保守費用払う気がない客も多いんですよ… 結果的にかえって金かかることの方が多いのにね
125 22/03/27(日)19:35:54 No.910809457
>>じゃあ今からリアルタイムに書き換えられているこの3TBのデータを今すぐRDBに入れて検索させてくれ >なにそのマウント… アンマウントしろ
126 22/03/27(日)19:36:17 No.910809598
>検索だけElasticsearchでやるのがわりとよくある 賢いやり方
127 22/03/27(日)19:36:25 No.910809655
>なるほどその方法で頼む >じゃあ今からリアルタイムに書き換えられているこの3TBのデータを今すぐRDBに入れて検索させてくれ 今あるデータは移行期間設けるとして その後は注入両方にすればよくない？