21/12/22(水)22:20:59 テーブ... のスレッド詳細
削除依頼やバグ報告は メールフォーム にお願いします。個人情報、名誉毀損、侵害等については積極的に削除しますので、 メールフォーム より該当URLをご連絡いただけると助かります。
21/12/22(水)22:20:59 No.879030246
テーブル設計のセンスがほしい
1 21/12/22(水)22:22:18 No.879030763
なんでも入れられる魔法のカラムを作ろう
2 21/12/22(水)22:22:54 No.879031002
とりあえずサロゲートキーを付けるところからスタート
3 21/12/22(水)22:23:03 No.879031060
正規化しすぎないバランス力
4 21/12/22(水)22:23:44 No.879031350
>なんでも入れられる魔法のカラムを作ろう NoSQL使えよもう
5 21/12/22(水)22:24:15 No.879031558
拡張性考えたら検索項目はカラムにしてそれ以外はJSONで一つのカラムにぶっこむのがいいのではとか思い始めた
6 21/12/22(水)22:24:18 No.879031577
>なんでも入れられる魔法のカラムを作ろう ラジャー！JSON型！
7 21/12/22(水)22:25:09 No.879031916
変なアイデアは >NoSQL使えよもう で大体いいのでは？
8 21/12/22(水)22:25:13 No.879031952
SQLアンチパターンを読め あれは滅茶苦茶良い本
9 21/12/22(水)22:25:57 No.879032249
どうして構造化問合せ言語のスレッドが毎日立っているのですか
10 21/12/22(水)22:27:05 No.879032713
>どうして構造化問合せ言語のスレッドが毎日立っているのですか ふつうのプログラミングスレより伸びるから人気があるのだろう
11 21/12/22(水)22:27:44 No.879033002
後々の仕様変更に備えてyobiカラムを定義しておく
12 21/12/22(水)22:27:45 No.879033006
Reserve1 Reserve2 Reserve3
13 21/12/22(水)22:27:53 No.879033062
>拡張性考えたら検索項目はカラムにしてそれ以外はJSONで一つのカラムにぶっこむのがいいのではとか思い始めた それ以外のとこで検索したくなる日が来るんじゃない？
14 21/12/22(水)22:28:53 No.879033412
その日が来たらカラムに昇格するのだ…
15 21/12/22(水)22:29:02 No.879033483
ひたすら正規化しまくって業務上で使うなら参照はviewだけ見る 更新系が死ぬ
16 21/12/22(水)22:29:08 No.879033524
結合できなくてしぬ
17 21/12/22(水)22:29:20 No.879033607
del_flg
18 21/12/22(水)22:31:01 No.879034332
>del_flg 昨日のスレで話題に出てたけどそんなに悪くないと思ってる del_flgで論理削除しといてバッチで定期的に本削除するシステム作った事あるけど別に問題出てない
19 21/12/22(水)22:31:23 No.879034468
速度もメモリ使用量も抑えたSQL書いて下さい withとinner joinで具体的な使用量を答えて下さい そんなに問い合わせ無いのになんでそんなこと言うんですか…
20 21/12/22(水)22:32:26 No.879034881
何故か最近触ったシステムは論理削除フラグにnullが入ってた 0も入ってた
21 21/12/22(水)22:32:50 No.879035069
del_flgは情報が少なすぎるしインデックスと相性が悪いから deleted_atの方が良いと思ってる
22 21/12/22(水)22:33:33 No.879035356
昔GIS的な社内データベース作った …ほぼ誰も使わなかった
23 21/12/22(水)22:34:30 No.879035754
>>del_flg >昨日のスレで話題に出てたけどそんなに悪くないと思ってる >del_flgで論理削除しといてバッチで定期的に本削除するシステム作った事あるけど別に問題出てない 一度出現した主キーが再使用される可能性が無いなら問題ないと思う
24 21/12/22(水)22:36:21 No.879036540
業務で消したらまずいものありそうだなって思ったら自己保守のために論理削除にするってとこもありそう 論理削除のバッジは論理削除フラグが立ったところだけ過去ログ系のfoobar_bkに入れてdelete処理しないとか 今容量増えるのはそんな問題ないからね
25 21/12/22(水)22:36:21 No.879036543
昔COBOLしかわからない人でもスムーズに移行できるという触れ込みで導入されたフレームワークは 1つのバッチ処理中でSELECT文が1回しか発行できないという頭を抱える代物だった
26 21/12/22(水)22:37:45 No.879037094
>今容量増えるのはそんな問題ないからね 削除したはずの情報が消えないのはそれはそれで問題になるのでは？ プライバシーポリシーとかの関係で
27 21/12/22(水)22:38:19 No.879037296
効率重視もいいけど後々システムに手をいれるときにわかりやすい設計にするのって大事だよなぁって最近しみじみ思う
28 21/12/22(水)22:38:28 No.879037349
今の標準SQLはすげー高機能だからコーディングよりSQL頑張って高速化する方がいいよ！ って意見もあるけど作り込んでも読める人がいなそう デバッグしづらい
29 21/12/22(水)22:39:47 No.879037860
基本的にSQLにビジネスロジック入れちゃダメだと思う RDBMS他のやつに切り替えるってなったらどうすんの？
30 21/12/22(水)22:41:06 No.879038345
>削除したはずの情報が消えないのはそれはそれで問題になるのでは？ >プライバシーポリシーとかの関係で それは漏れた時にヤバそうだけど漏れたって時点でヤバい プライバシーポリシーの法律関係で削除求められたら物理削除とか論理削除って書かれていたっけ？ そこか焦点な気がする
31 21/12/22(水)22:42:36 No.879038924
>RDBMS他のやつに切り替えるってなったらどうすんの？ DB切り替えられるってなっていても 実際に切り替えることなくね？
32 21/12/22(水)22:46:29 No.879040353
過去バージョンいじることになってこの関数無いの！？ってなることはある
33 21/12/22(水)22:47:54 No.879040892
>基本的にSQLにビジネスロジック入れちゃダメだと思う >RDBMS他のやつに切り替えるってなったらどうすんの？ DB以降でSQL文そのまま使い回さないし…
34 21/12/22(水)22:50:20 No.879041775
>後々の仕様変更に備えてyobiカラムを定義しておく ALTER TABLE列追加で1時間システム止まった経験以来こうしてる
35 21/12/22(水)22:50:26 No.879041822
>実際に切り替えることなくね？ ある
36 21/12/22(水)22:51:39 No.879042262
無意味にテーブル名をT1とかにして難読化する輩が多すぎる
37 21/12/22(水)22:51:53 No.879042337
>>後々の仕様変更に備えてyobiカラムを定義しておく >ALTER TABLE列追加で1時間システム止まった経験以来こうしてる yobiカラムの型はどうするんですか
38 21/12/22(水)22:52:14 No.879042493
途中参加した開発プロジェクトが文字列結合でクエリ生成してるwebシステムでうわあってなった 案の定適当に攻撃したら割と好き放題出来たよ いくら顧客以外には非公開なシステムと言ってもさあ…
39 21/12/22(水)22:53:58 No.879043213
>ある 検証めちゃくちゃ辛く無い？
40 21/12/22(水)22:54:01 No.879043234
>yobiカラムの型はどうするんですか そりゃ適当な長さのvarcharでしょ ほんとやめて欲しいけど仕方ない所もなくはない
41 21/12/22(水)22:54:09 No.879043293
>いくら顧客以外には非公開なシステムと言ってもさあ… まあ社内でしか使わないならお客さんが良いって言ってるならいいんじゃない 攻撃者がいない社内でセキュリティコストかけても無駄に終わるし マルチテナントでそれとか外販予定があるとかだったらダメダメだけど
42 21/12/22(水)22:54:50 No.879043539
>>ある >検証めちゃくちゃ辛く無い？ もちろんめちゃくちゃ辛い
43 21/12/22(水)22:54:54 No.879043555
>途中参加した開発プロジェクトが文字列結合でクエリ生成してるwebシステムでうわあってなった 標準ライブラリだとIN句に配列入れるのに文字列処理するしかなくてビビる
44 21/12/22(水)22:57:01 No.879044357
>まあ社内でしか使わないならお客さんが良いって言ってるならいいんじゃない きょうびちゃんと対策する方が工数減るまであるしそういうことできないチーム抱えてると碌なことにはならないけどな そのうち社内で実績あるから公開しましょとか新アプリはネットに出しましょなんて平気で言ってくるぞ
45 21/12/22(水)22:59:18 No.879045284
>まあ社内でしか使わないならお客さんが良いって言ってるならいいんじゃない >攻撃者がいない社内でセキュリティコストかけても無駄に終わるし >マルチテナントでそれとか外販予定があるとかだったらダメダメだけど 大体そういうのってフレームワークもどきとして流用されがちだからこんなのは即刻捨てて既存の優秀なフレームワークに置き換えるべきだよ なんだがまあそうそうそんなことやれるわけもないので最低限穴だけ塞いでそのままだけど…
46 21/12/22(水)22:59:19 No.879045289
>>yobiカラムの型はどうするんですか >そりゃ適当な長さのvarcharでしょ >ほんとやめて欲しいけど仕方ない所もなくはない じっさいに必要になったのはtimestamp型のカラムで しかもA以降Bまって範囲検索もできるようにしろって言われた 俺は泣いた
47 21/12/22(水)22:59:29 No.879045344
不要になったカラムを消さなければなんでもいいよ それだけはマジでやめてほしい
48 21/12/22(水)23:00:09 No.879045634
bool型にインデックス貼ってもB木的にあんま意味あることにならないよねって理解であってる？
49 21/12/22(水)23:00:18 No.879045680
あとから拡張するときにどうしようかーってなるばっかりで そんな消すことが主題になることあるのか？あるんだろうな…
50 21/12/22(水)23:00:35 No.879045794
>DB切り替えられるってなっていても >実際に切り替えることなくね？ 「」くんちょっとサーバーが古くなってきたから新しくしたいんだけど サポート考えて別のDBに引っ越してもSQLは使えるし一緒だよね？
51 21/12/22(水)23:01:48 No.879046296
最近OracleからPostgreへの移行結構あるからな…
52 21/12/22(水)23:01:54 No.879046330
>「」くんちょっとサーバーが古くなってきたから新しくしたいんだけど >サポート考えて別のDBに引っ越してもSQLは使えるし一緒だよね？ タダで使えるDBに移行したいんだよね
53 21/12/22(水)23:02:47 No.879046657
コード中でINSERT文生成してる処理が超見づらいんだけどなんか対策あるのかな 1つのクエリ作るのに500行とか平気で超えてるのがゴロゴロしてて困る
54 21/12/22(水)23:02:47 No.879046658
>なんでも入れられる魔法のカラムを作ろう なんでも入れられるカラムと他のカラムで矛盾した情報が入っちまったーっ！
55 21/12/22(水)23:03:02 No.879046742
delete_flgも絶対に駄目ってわけじゃなくて運用を考えた上で計画的に設計するならよい
56 21/12/22(水)23:03:39 No.879047016
>最近OracleからPostgreへの移行結構あるからな… sqlserverなら理解できるけどそれ以外はちょっと引くわ
57 21/12/22(水)23:04:07 No.879047213
>コード中でINSERT文生成してる処理が超見づらいんだけどなんか対策あるのかな SQL生成できるフレームワーク使う
58 21/12/22(水)23:04:13 No.879047238
しゃーねえじゃん Oracleお高いんだもの
59 21/12/22(水)23:04:43 No.879047424
>コード中でINSERT文生成してる処理が超見づらいんだけどなんか対策あるのかな >1つのクエリ作るのに500行とか平気で超えてるのがゴロゴロしてて困る ヒアドキュメント系の機能と変数使ってクエリを一箇所で書くようにすればいい
60 21/12/22(水)23:05:26 No.879047661
>>最近OracleからPostgreへの移行結構あるからな… >sqlserverなら理解できるけどそれ以外はちょっと引くわ 同じOracleだしMySQLにしよう
61 21/12/22(水)23:05:48 No.879047793
弊社などはSQLserverExpressで間に合う案件ばかりなのでアレだ… 古いデータ？CSVに定期的に吐き出して消しといて
62 21/12/22(水)23:06:05 No.879047898
めっちゃ長いクエリーを書けるのすごいよね
63 21/12/22(水)23:07:37 No.879048547
怖いよね予備カラムがintとvarcharそれぞれ３つずつ全部のテーブルに用意されてるの
64 21/12/22(水)23:07:38 No.879048551
>めっちゃ長いクエリーを書けるのすごいよね 照れる～
65 21/12/22(水)23:07:50 No.879048635
新人の頃読んだ数百行のselect文が未だにトラウマ with句はもう一生見たくない
66 21/12/22(水)23:07:55 No.879048667
褒めてないんだけど
67 21/12/22(水)23:08:28 No.879048874
>めっちゃ長いクエリーを書けるのすごいよね こうやるしか思いつかなくて長いのかいた後にすごーい！とか言われるのは馬鹿にされてるのでいいのかな…
68 21/12/22(水)23:08:34 No.879048928
必須項目ガチガチに固めると融通が利かなくなるという…
69 21/12/22(水)23:08:36 No.879048949
oracle高いしそんなにoracle必要か？ってとこがあるから いやまあサポート部分を全部俺らがやるハメになること考えたらあれではあるんだけど結局サポートにもそんな投げたりしないしな…
70 21/12/22(水)23:09:21 No.879049274
ここですらSQLにロジック組み込むの普通にやるし読めないほうが悪いってスタンスの「」いるからこれはもうわかりあえない
71 21/12/22(水)23:09:22 No.879049285
ちゃんとしたところではSQLもレビューするのかな
72 21/12/22(水)23:10:32 No.879049802
>ちゃんとしたところではSQLもレビューするのかな インデックス使ってるかどうかとかそもそも新しくインデックスはるとかも含めてやるね
73 21/12/22(水)23:10:47 No.879049893
ビッグデータ分析基盤のSQLっぽい分析用クエリはクソ長いの書くよね クエリの中で正規表現とかも書いていて読むのつらい…
74 21/12/22(水)23:11:09 No.879050036
>SQL生成できるフレームワーク使う >ヒアドキュメント系の機能と変数使ってクエリを一箇所で書くようにすればいい リファクタリングするときに参考にしてみるありがとう
75 21/12/22(水)23:11:41 No.879050252
>インデックス使ってるかどうかとかそもそも新しくインデックスはるとかも含めてやるね そういう職場に転職してえなあ！
76 21/12/22(水)23:11:50 No.879050317
>ビッグデータ分析基盤のSQLっぽい分析用クエリはクソ長いの書くよね >クエリの中で正規表現とかも書いていて読むのつらい… Bigquery用のクエリがJSON_EXTRACTが乱舞していて辛い でもフルスキャンなのにクソ速いBQ凄いと思う
77 21/12/22(水)23:12:27 No.879050587
>ここですらSQLにロジック組み込むの普通にやるし読めないほうが悪いってスタンスの「」いるからこれはもうわかりあえない どのレベルのロジックを想定してるのかわからないけどSQL側じゃないと非機能的に実現できない要件も結構あるしなぁ
78 21/12/22(水)23:14:37 No.879051461
このストアドプロシージャってのを使うと引数を取って条件分岐やループを仕込んだクエリを書けちまうんだ！ いっぱいロジック書くね…
79 21/12/22(水)23:14:53 No.879051564
oracleがpostgresに明確に勝ってる点あるの
80 21/12/22(水)23:14:58 No.879051595
>このストアドプロシージャってのを使うと引数を取って条件分岐やループを仕込んだクエリを書けちまうんだ！ >いっぱいロジック書くね… 永遠にお前がメンテするならいいけどさあ！
81 21/12/22(水)23:15:13 No.879051676
ストアドプロシージャは使用禁止です!
82 21/12/22(水)23:15:16 No.879051710
>oracleがpostgresに明確に勝ってる点あるの お高い
83 21/12/22(水)23:15:21 No.879051736
遅いからなんとかしてくれって丸投げるのやめて欲しい
84 21/12/22(水)23:15:42 No.879051851
>oracleがpostgresに明確に勝ってる点あるの 得られたサポート
85 21/12/22(水)23:15:44 No.879051862
>ストアドプロシージャは使用禁止です! ファック！
86 21/12/22(水)23:15:52 No.879051903
>oracle高いしそんなにoracle必要か？ってとこがあるから >いやまあサポート部分を全部俺らがやるハメになること考えたらあれではあるんだけど結局サポートにもそんな投げたりしないしな… Oracleはいるだけで基盤設計から変えないといけなくなったりするのでインフラ屋としてはマジでやめてほしい 仮想基盤全台分のCPUライセンスとか正気かてめえ
87 21/12/22(水)23:15:53 No.879051910
>>oracleがpostgresに明確に勝ってる点あるの >お高い 勝ち…？
88 21/12/22(水)23:15:59 No.879051935
>oracle高いしそんなにoracle必要か？ってとこがあるから PL/SQLが最強だから…
89 21/12/22(水)23:16:08 No.879051993
>>このストアドプロシージャってのを使うと引数を取って条件分岐やループを仕込んだクエリを書けちまうんだ！ >>いっぱいロジック書くね… >永遠にお前がメンテするならいいけどさあ！ バグが追いにくいクソゴミを量産するテロ行為やめろ
90 21/12/22(水)23:16:16 No.879052044
だからSQLアンチパターンとプログラマのためのSQLを読めって
91 21/12/22(水)23:16:33 No.879052148
>oracleがpostgresに明確に勝ってる点あるの ユーザーから買った恨み
92 21/12/22(水)23:16:45 No.879052229
メインフレームで動かすDBのうちOracleはまともな方だから
93 21/12/22(水)23:17:33 No.879052535
メインフレームで動かすDBというじてんで近寄りたくない
94 21/12/22(水)23:17:34 No.879052540
オラクルマスター持ってる人ならどんなプロシージャも余裕でメンテしてくれる
95 21/12/22(水)23:17:47 No.879052623
>仮想基盤全台分のCPUライセンスとか正気かてめえ なんとOracleVMならvCPU毎の課金でいいんですよ！ しばくぞてめえ
96 21/12/22(水)23:18:01 No.879052717
メインフレームでOracle動くんだ…へー…怖…
97 21/12/22(水)23:18:16 No.879052805
やはりSQLServer…
98 21/12/22(水)23:18:31 No.879052911
>だからSQLアンチパターンとプログラマのためのSQLを読めって 後者はもう厚くなりすぎてDBエンジニアってわけでもない人には勧めづらい…
99 21/12/22(水)23:18:43 No.879053003
稼働環境異様に豊富だよねOracle
100 21/12/22(水)23:19:10 No.879053207
AWSやAzureが使えなくてOracleのクラウド縛りなのはキツイ
101 21/12/22(水)23:19:24 No.879053315
plsqlきらい…
102 21/12/22(水)23:19:45 No.879053454
>やはりSQLServer… NTFSでしか動かないDB呼ばわりだったのにいつの間にかLinuxで動くし何だったらWindowsコンテナ版が開発中止でLinux版だけになった…