18/06/16(土)22:27:52 みんな... のスレッド詳細
削除依頼やバグ報告は メールフォーム にお願いします。個人情報、名誉毀損、侵害等については積極的に削除しますので、 メールフォーム より該当URLをご連絡いただけると助かります。
画像ファイル名:1529155672303.png 18/06/16(土)22:27:52 No.512212703
みんな大好きな言語
1 18/06/16(土)22:29:26 No.512213124
大好き
2 18/06/16(土)22:30:03 No.512213333
コーディング自体は大好きなんだけどその他全てがにくいよぉ…
3 18/06/16(土)22:30:21 No.512213423
でも運用中のDBをいじくるのは勘弁な！
4 18/06/16(土)22:31:24 No.512213756
運用は知らない
5 18/06/16(土)22:32:13 No.512213993
いいかんじのクエリ閃くと気持ちいい
6 18/06/16(土)22:32:18 No.512214016
SQLServerとOracleの壁は深い
7 18/06/16(土)22:32:35 No.512214087
この仕事しててプログラミングのスーパーマンには何人かあったけど 画像のスーパーマンには一人もあったことがない
8 18/06/16(土)22:32:38 No.512214097
いいですよね 100行近いSQL文
9 18/06/16(土)22:32:46 No.512214138
複雑なSQL書いて想定通りのデータがスパッと一発で取れると気持ちいよね だいたいそんな都合良くはいかない
10 18/06/16(土)22:33:04 No.512214216
パフォーマンスでハマる
11 18/06/16(土)22:33:23 No.512214315
集合の概念が立ちはだかる！
12 18/06/16(土)22:33:29 No.512214354
だいたいOracleが悪い
13 18/06/16(土)22:33:30 No.512214361
>画像のスーパーマンには一人もあったことがない 単価お高いから凄く深いところに潜ってたりする
14 18/06/16(土)22:33:34 No.512214375
DBスペシャリスト取ったけどSQLコーディングよりデータモデリングとDB設計の方が倍ぐらい難しい
15 18/06/16(土)22:33:39 No.512214404
まぁALTER TABLEなんか実際には使わんのやけどもな ブヘヘヘ
16 18/06/16(土)22:33:54 No.512214465
小規模なアプリだけ組んでフレームワークが用意したマッパーだけ使ってこいつを忘れたい
17 18/06/16(土)22:34:17 No.512214562
PIVOTがよく分からないまま10年くらいDBの担当をしてる
18 18/06/16(土)22:34:22 No.512214584
>パフォーマンスでハマる どうしてインデックスを貼ってないカラムをキーに使うのですか？
19 18/06/16(土)22:34:42 No.512214704
>DBスペシャリスト取ったけどSQLコーディングよりデータモデリングとDB設計の方が倍ぐらい難しい SQLコーディング悩まないといけないようなのは設計がクソなんだろうなってなるし・・・
20 18/06/16(土)22:34:45 No.512214717
MySQL PostgreSQL
21 18/06/16(土)22:34:55 No.512214775
すとあどぷろしーじゃ（スパゲッティの一種）
22 18/06/16(土)22:35:07 No.512214847
ツリーを区間で表現するの最初に思いついたやつすげー
23 18/06/16(土)22:35:16 No.512214888
>DBスペシャリスト取ったけどSQLコーディングよりデータモデリングとDB設計の方が倍ぐらい難しい DB設計はミスると修正の機会が無いしね…
24 18/06/16(土)22:35:25 No.512214942
最近ようやくサロゲートキーの存在意義をなんとなく理解できて来た
25 18/06/16(土)22:35:36 No.512214984
SQLできない新人が多い
26 18/06/16(土)22:36:32 No.512215234
識別子は100文字くらい使わせて欲しい
27 18/06/16(土)22:36:48 No.512215310
>最近ようやくサロゲートキーの存在意義をなんとなく理解できて来た 原則全部サロゲートキーで設計してるよ 骨太のルール作っとくとやっぱ楽だなって
28 18/06/16(土)22:36:52 No.512215326
SQLバリバリの新人がいたらそれはそれで怖いよ…
29 18/06/16(土)22:37:08 No.512215393
パソコン使える？と同じレベルで困る SQLできる？って質問
30 18/06/16(土)22:37:15 No.512215423
大文字派と小文字派と混在派の壁は厚い
31 18/06/16(土)22:37:35 No.512215505
>最近ようやくサロゲートキーの存在意義をなんとなく理解できて来た IDとコードは別に設けるべきだと思うわ
32 18/06/16(土)22:37:53 No.512215586
>どうしてインデックスを貼ってないカラムをキーに使うのですか？ 了解！HINT句いっぱい書く！
33 18/06/16(土)22:38:16 No.512215702
1000行オーバーを書く現場がありましたよ なぜ業務ロジックをすべてSQLに寄せる判断をしたのです 誰がしたのです
34 18/06/16(土)22:38:37 No.512215770
データベースってテキストにズラッとデータ並んでるようなのとはどう違うの？ ピンポイントで読めるから軽いとか？
35 18/06/16(土)22:38:52 No.512215839
うちのdbがtriggerだらけでよくわからなくなってきた
36 18/06/16(土)22:39:03 No.512215876
>パソコン使える？と同じレベルで困る >SQLできる？って質問 抽出できればいいのか更新できればいいのか それともDB設計ができればいいのかでだいぶ違うからなぁ お題を出して「これ出来る？」って聞いたほうがお互いのためだと思う
37 18/06/16(土)22:39:17 No.512215932
>なぜ業務ロジックをすべてSQLに寄せる判断をしたのです すとあどぷろしーじゃ？がべんりだなって…
38 18/06/16(土)22:39:25 No.512215961
マスタテーブルにどんどんカラム追加されて順番ぐちゃぐちゃで気持ち悪いから テーブルドロップさせて作り直したら滅茶苦茶怒られた… 問題なく動いてるからいいじゃん…
39 18/06/16(土)22:39:29 No.512215976
CASE(DECODE)とEXISTS使いこなせれば中級でいい？
40 18/06/16(土)22:39:55 No.512216081
>テーブルドロップさせて作り直したら滅茶苦茶怒られた… 本番か？ 本番環境でやったのか？
41 18/06/16(土)22:40:15 No.512216185
むしろ複雑怪奇なSQLが書けるのはなんの自慢にもならない
42 18/06/16(土)22:40:27 No.512216254
なんでもかんでもSQLでやろうとするな！
43 18/06/16(土)22:40:33 No.512216275
なんの相談もなくドロップしたら怒るよ
44 18/06/16(土)22:40:33 No.512216276
適当にMySQLでテーブルを作って室温を自動計測してDBに放り込むソフトをかれこれ10年位動かしてるんだけど そろそろ更新しなきゃいけない SQLはほとんど覚えてない…
45 18/06/16(土)22:40:33 No.512216277
>マスタテーブルにどんどんカラム追加されて順番ぐちゃぐちゃで気持ち悪いから >テーブルドロップさせて作り直したら滅茶苦茶怒られた… >問題なく動いてるからいいじゃん… 勝手にやったら怒られて当たり前だよ！
46 18/06/16(土)22:40:44 No.512216331
うるせえTRUNCATEしてやる
47 18/06/16(土)22:40:48 No.512216349
了解！MariaDB！
48 18/06/16(土)22:40:49 No.512216358
>マスタテーブルにどんどんカラム追加されて順番ぐちゃぐちゃで気持ち悪いから >テーブルドロップさせて作り直したら滅茶苦茶怒られた… >問題なく動いてるからいいじゃん… どんな状況でやったのか知らんが 場合によっては殺されても仕方がないぞ
49 18/06/16(土)22:40:54 No.512216382
>テーブルドロップさせて作り直したら滅茶苦茶怒られた… バックアップとってあればまあ...
50 18/06/16(土)22:41:13 No.512216463
自己判断でやらかすPGいいよね
51 18/06/16(土)22:41:23 No.512216514
>適当にMySQLでテーブルを作って室温を自動計測してDBに放り込むソフトをかれこれ10年位動かしてるんだけど 面白いデータ取ってるな
52 18/06/16(土)22:41:25 No.512216524
>うるせえTRUNCATEしてやる すいません…それで本番○兆円分の取引データ消しました…
53 18/06/16(土)22:41:27 No.512216534
ローカルの開発環境でやってどうです？って提案して怒られたならそりゃ相手が悪い 本番環境で無断でやったらぶち転がすぞ・・・
54 18/06/16(土)22:41:32 No.512216557
>なんの相談もなくドロップしたら怒るよ 怒るだけで済まされたらまだいいほうじゃん！
55 18/06/16(土)22:41:34 No.512216572
>なんでもかんでもSQLでやろうとするな！ 検索系画面のSQL以外はサブクエリ禁止くらいでいいよ…
56 18/06/16(土)22:41:35 No.512216577
>データベースってテキストにズラッとデータ並んでるようなのとはどう違うの？ >ピンポイントで読めるから軽いとか？ プログラマのためのSQLに似たような話があったけど忘れた
57 18/06/16(土)22:41:49 No.512216621
テーブル設計を考えていくとオブジェクト指向RDBが欲しくなってくるよね？ ポスグレしかないけど
58 18/06/16(土)22:41:50 No.512216626
プログラミング初学者なんだけどSQLってやっといた方がいい？ ちなみに今勉強してるのはCとpython
59 18/06/16(土)22:42:06 No.512216695
>マスタテーブルにどんどんカラム追加されて順番ぐちゃぐちゃで気持ち悪いから >テーブルドロップさせて作り直したら滅茶苦茶怒られた… >問題なく動いてるからいいじゃん… この仕事向いてないよ…
60 18/06/16(土)22:42:18 No.512216757
>>うるせえTRUNCATEしてやる >すいません…それで本番○兆円分の取引データ消しました… バックアップは面倒だからね...
61 18/06/16(土)22:42:20 No.512216763
無断ではあるけど本番でシステム動いてない時にバックアップ取ってやった
62 18/06/16(土)22:42:31 No.512216821
>プログラミング初学者なんだけどSQLってやっといた方がいい？ DB使わないならええよ
63 18/06/16(土)22:42:42 No.512216873
やめなよ気軽に俺天案件
64 18/06/16(土)22:42:55 No.512216940
>プログラミング初学者なんだけどSQLってやっといた方がいい？ 基幹に関わるなら嫌でもやる
65 18/06/16(土)22:42:57 No.512216950
>データベースってテキストにズラッとデータ並んでるようなのとはどう違うの？ 扱うデータが数百万件だったりする 必要なデータだけ0.1秒で絞り込んでとってきな！
66 18/06/16(土)22:42:59 No.512216962
なんで無断なの！？
67 18/06/16(土)22:43:02 No.512216978
派遣だったら次の日に居なくなるやつだ…
68 18/06/16(土)22:43:13 No.512217021
>プログラミング初学者なんだけどSQLってやっといた方がいい？ >ちなみに今勉強してるのはCとpython 一般常識だけど別に必要がなければ覚えなくて良いのでは？
69 18/06/16(土)22:43:23 No.512217064
今どきDBつかわないシステム設計ってあるのかな
70 18/06/16(土)22:43:36 No.512217128
>プログラミング初学者なんだけどSQLってやっといた方がいい？ >ちなみに今勉強してるのはCとpython pythonやってるなら統計データ取るとかで必要になるんじゃない？ pythonやったこと無いけど
71 18/06/16(土)22:43:49 No.512217200
いなくなるどころか賠償云々言われるだろ
72 18/06/16(土)22:44:05 No.512217271
>プログラミング初学者なんだけどSQLってやっといた方がいい？ >ちなみに今勉強してるのはCとpython 初学者なら必要になったところ順に覚えていけばいいよ どうせそのうちぶつかる
73 18/06/16(土)22:44:15 No.512217321
必要に駆られてからお勉強したっていいんだ 無料で自分のPCに環境作れるし
74 18/06/16(土)22:44:20 No.512217339
部下に居たら頭抱えそうな「」が2人くらいいるな…
75 18/06/16(土)22:44:41 No.512217429
ちなみにプログラムの実装によってはDBのカラムの順番違えると動作不良起こす場合がある…
76 18/06/16(土)22:44:51 No.512217476
no!sql!
77 18/06/16(土)22:44:56 No.512217501
アプリじゃなくてインフラとか基盤寄りのお仕事だとDBは触らなかったりする
78 18/06/16(土)22:45:03 No.512217535
正規形を突き詰めていくとNULLを許さなくなるらしく 1表当たりの列数が減って表の数が多くなるらしいな
79 18/06/16(土)22:45:04 No.512217537
SQLiteいいよね… ACCESSはほろべ…ってくらい扱いやすい
80 18/06/16(土)22:45:11 No.512217586
>プログラミング初学者なんだけどSQLってやっといた方がいい？ というかプログラムで何にしたいかによって…
81 18/06/16(土)22:45:15 No.512217598
夜間集計処理をRDBから辞めたい
82 18/06/16(土)22:45:16 No.512217614
>部下に居たら頭抱えそうな「」が2人くらいいるな… そんなやつに本番の管理者権限渡すほうが悪いのだ…
83 18/06/16(土)22:45:19 No.512217626
>DB使わないならええよ >基幹に関わるなら嫌でもやる >一般常識だけど別に必要がなければ覚えなくて良いのでは？ >初学者なら必要になったところ順に覚えていけばいいよ なるほど必要が出てきたときに覚えればいいか thx
84 18/06/16(土)22:45:19 No.512217629
DB使わないシステムってあんまり無いから システム開発やってればそのうち必要になる
85 18/06/16(土)22:45:21 No.512217642
>ちなみにプログラムの実装によってはDBのカラムの順番違えると動作不良起こす場合がある… 分からんでもないけど それはプログラム側の実装が悪いのでは？
86 18/06/16(土)22:45:36 No.512217722
DBのインフラレイヤ設計って良い勉強元ないかな パフォーマンスやバックアップやら考えないといけないのに何みればいいのか分かんない
87 18/06/16(土)22:45:59 No.512217828
>分からんでもないけど >それはプログラム側の実装が悪いのでは？ 何番目のカラムからとる~の方がらくだからね・・・
88 18/06/16(土)22:46:01 No.512217845
>正規形を突き詰めていくとNULLを許さなくなるらしく >1表当たりの列数が減って表の数が多くなるらしいな 左様 でもテーブル結合が多くなりすぎるとパフォーマンスが落ちるので正規化はほどほどで妥協する
89 18/06/16(土)22:46:08 No.512217872
>ちなみにプログラムの実装によってはDBのカラムの順番違えると動作不良起こす場合がある… ウチだわ 古い資産があるからしゃーないけど
90 18/06/16(土)22:46:25 No.512217958
ちょっとした抽出文書けるくらいなんだけど確かにDBって IT関わってるとホントどこでも出てくるから飯のタネに ちゃんとした資格取ろうかなと思ってるんだがやっぱ安定なのはOracleかな？ 独自実装割とあるみたいではあるけど大手だし食いっぱぐれなさそう
91 18/06/16(土)22:46:27 No.512217967
>1表当たりの列数が減って表の数が多くなるらしいな JOIN面倒だから1表に全データつけとくね…
92 18/06/16(土)22:46:37 No.512218010
>それはプログラム側の実装が悪いのでは？ 例えプログラム側の作りが悪かろうが プログラム側に影響可能性のある修正を勝手にやるのはアウトだよ
93 18/06/16(土)22:46:39 No.512218025
>それはプログラム側の実装が悪いのでは？ そうだね！！！！ でも直せないの直すのにもお金かかるから！！！ 書いたやつぶち転がすぞ……
94 18/06/16(土)22:46:41 No.512218041
すげーな…現場によっては出禁レベルのことやってるのに効率化した自分が正しい偉いって思ってらっしゃる
95 18/06/16(土)22:46:42 No.512218045
FILLER
96 18/06/16(土)22:46:55 No.512218110
>正規形を突き詰めていくとNULLを許さなくなるらしく >1表当たりの列数が減って表の数が多くなるらしいな 正規化ってそんなもんじゃないかな
97 18/06/16(土)22:47:11 No.512218197
NOSQLって完全に非正規化したRDBと一緒なんでしょー
98 18/06/16(土)22:47:15 No.512218215
どんなときもexplainだとは言うけど explainのことそんなによくわかってない
99 18/06/16(土)22:47:21 No.512218241
性能が劣るから非性器系にするとか垂直分割するとか言われてもどれくらい違うのかわからんくてピンと来ない
100 18/06/16(土)22:47:25 No.512218255
スクリプトかSQLどちらを覚えるべきかと聞かれたら SQLからDBの設計思想を学べと応える
101 18/06/16(土)22:47:35 No.512218308
NULLとブランクと半角スペース一個（このカラムは何もデータが入ってないよ！）
102 18/06/16(土)22:47:43 No.512218344
やらかしそうな「」はAWS RDS使え PITR機能を使えばデータベースの中身を秒単位指定で巻き戻せるから たとえDROPしようとUPDATEにWHERE付け忘れても 首の皮一枚繋がるぞ！
103 18/06/16(土)22:47:52 No.512218395
>>分からんでもないけど >>それはプログラム側の実装が悪いのでは？ >何番目のカラムからとる~の方がらくだからね・・・ プログラムに影響出ない取り方ってカラム名で指定すんの？
104 18/06/16(土)22:47:55 No.512218416
>NOSQLって完全に非正規化したRDBと一緒なんでしょー JSON型のDBとかもあるんよ
105 18/06/16(土)22:48:13 No.512218491
私オブジェクトブラウザ嫌い！
106 18/06/16(土)22:48:15 No.512218499
>ちゃんとした資格取ろうかなと思ってるんだがやっぱ安定なのはOracleかな？ 基本→応用→DBスペシャリストのほうが安くて使える
107 18/06/16(土)22:48:17 No.512218509
思い込みって怖いよね
108 18/06/16(土)22:48:25 No.512218549
>どんなときもexplainだとは言うけど >explainのことそんなによくわかってない クソみたいに遅いとき使えば良い 意外とゴロゴロ変わるからそれで一喜一憂することはない
109 18/06/16(土)22:48:26 No.512218552
学校じゃ教えない言語だし …今でも教えてないよね？
110 18/06/16(土)22:48:30 No.512218576
資格よりもちゃんと正規化を学んでtable設計できる人間が欲しい
111 18/06/16(土)22:48:31 No.512218583
explainして見たところでどこが遅いか分からんし 分かっても改善出来ない・・・
112 18/06/16(土)22:48:31 No.512218584
資格では評価され辛い気もする…
113 18/06/16(土)22:48:34 No.512218598
>>何番目のカラムからとる~の方がらくだからね・・・ >プログラムに影響出ない取り方ってカラム名で指定すんの？ システム開発やっていれば常識では…
114 18/06/16(土)22:48:42 No.512218627
NOSQLでお手軽に高速化できるんでしょ？
115 18/06/16(土)22:48:43 No.512218639
>何番目のカラムからとる~の方がらくだからね・・・ 何も知らない人が来たときにとっつきづらいとか思わないの？
116 18/06/16(土)22:48:44 No.512218641
今開発中のシステムindex一切使ってないな 開発が終わったらパフォーマンス見てチューニングするとかわけのわからないことを言ってる
117 18/06/16(土)22:48:55 No.512218700
Auroraとか実績ないからうちじゃつかえないし…
118 18/06/16(土)22:48:56 No.512218705
ぼく小売業のシステム部門のプロパー社員 ぼく以外の社員はSELECTすら書けない どうしろっていうんですか
119 18/06/16(土)22:48:59 No.512218727
後からnotNULLのカラム足すのめどいね
120 18/06/16(土)22:49:01 No.512218734
>性能が劣るから非性器系にするとか垂直分割するとか言われてもどれくらい違うのかわからんくてピンと来ない 数千万件ぐらいのダミーデータ作って遊んでみるのがいいよDBについての理解が深まる まあだいたいは本番トラブルで泣いて痛い目みつつ覚えるわけだが…
121 18/06/16(土)22:49:06 No.512218761
>何も知らない人が来たときにとっつきづらいとか思わないの？ そんなレベルの人が来られても困るって業界では？
122 18/06/16(土)22:49:09 No.512218776
Oracleは近年ちょっと引くくらいライセンスが外道 もうPostgreSQLに移行しちゃった
123 18/06/16(土)22:49:19 No.512218828
>何番目のカラムからとる~の方がらくだからね・・・ やめろや！
124 18/06/16(土)22:49:20 No.512218833
>explainのことそんなによくわかってない 実行計画では安くても時間かかることありがちだしね
125 18/06/16(土)22:49:24 No.512218847
運用始まって半年くらい経って 突然遅くなった！って言われるからな 普段から統計情報とっとくのは大事
126 18/06/16(土)22:49:24 No.512218849
遅い？index追加だオラッ！ そして他のSQLが遅くなるなった
127 18/06/16(土)22:49:32 No.512218877
MySQLのsqlmodeで制約弱める設定をして マスタデータテーブルのNOTNULLなカラムにNULLが入っているシステムまだ元気に動いているよやったね
128 18/06/16(土)22:49:33 No.512218884
>>なぜ業務ロジックをすべてSQLに寄せる判断をしたのです >すとあどぷろしーじゃ？がべんりだなって… 実際DBの中の事はDBにやらせるのが早い selectしてきてjavaがごねごねしてupdateとかを全部やるより DBの中で処理して終わったかどうか聞く方が 通信のやりとりが不要になる
129 18/06/16(土)22:49:45 No.512218934
Oracle-PRO-Cを1回やっただけでSQLのPROにさせられ12年 いやまぁわかりやすいし組むの楽だからいいんだけれども
130 18/06/16(土)22:49:46 No.512218935
可読性重視（糞見たいな長さの名前の変数）
131 18/06/16(土)22:49:49 No.512218950
>Oracleは近年ちょっと引くくらいライセンスが外道 >もうPostgreSQLに移行しちゃった SQLServerは使いやすくていいぞ！
132 18/06/16(土)22:49:53 No.512218967
12000行のストアドプロシージャをメンテする地獄
133 18/06/16(土)22:49:55 No.512218977
>基本→応用→DBスペシャリストのほうが安くて使える そういや今はIPAでもDBの資格あるんだったか 確かにそっちの方が大手を振ってDB分かりますって言えそうだな
134 18/06/16(土)22:49:58 No.512218990
更新日 char(8) 更新時間 char(6)
135 18/06/16(土)22:50:08 No.512219032
>どうしろっていうんですか 逃げてプロパーに危機感を与えてみたら？ 次の新しい奴隷が連れて来られるだけだろうけども
136 18/06/16(土)22:50:10 No.512219046
SQLアンチパターン読んで第三正規化くらいまではちゃんと考えて欲しいマジで... IDに意味をもたせるやつ死んで欲しい
137 18/06/16(土)22:50:25 No.512219111
>>>何番目のカラムからとる~の方がらくだからね・・・ >>プログラムに影響出ない取り方ってカラム名で指定すんの？ >システム開発やっていれば常識では… 古代言語と古代フレームワークの現場なんで… 自動生成ソースがカラム位置指定で取ってたりする
138 18/06/16(土)22:50:32 No.512219146
>>何番目のカラムからとる~の方がらくだからね・・・ >何も知らない人が来たときにとっつきづらいとか思わないの？ そら保守性とか可読性のことを考えてプログラムメンテナンスしとくのは理想だけど いつでもどんなプロジェクトでもそうできるとは限らないよねって話では
139 18/06/16(土)22:50:39 No.512219173
>SQLServerは使いやすくていいぞ！ 私サーバにwin使うの嫌い！（ﾊﾞｱｱｱﾝ
140 18/06/16(土)22:50:42 No.512219188
このSQLの性能でないから直して！！って持ち込まれるSQLの殆どがDB設計がクソすぎて手の施しようがないものばっかりで困る
141 18/06/16(土)22:50:49 No.512219214
こいつどうやって勉強したらいいかわかんない…
142 18/06/16(土)22:50:57 No.512219238
オラクル犬愛でたいんだけどまだ居るのかな？
143 18/06/16(土)22:51:00 No.512219257
>ぼく以外の社員はSELECTすら書けない >どうしろっていうんですか 逆にそれなら首の心配ないじゃんよかったじゃん …糞大変そうなのは分かる
144 18/06/16(土)22:51:09 No.512219298
ORACLEライセンス体系はやばいねあれなんであんな極悪な体系とれるの
145 18/06/16(土)22:51:09 No.512219300
>ぼく小売業のシステム部門のプロパー社員 >ぼく以外の社員はSELECTすら書けない >どうしろっていうんですか さっきのバグ直したんでリリースするからハンコください
146 18/06/16(土)22:51:22 No.512219356
SQLを性能重視して設計するのってどうすればいいの
147 18/06/16(土)22:51:25 No.512219375
>こいつどうやって勉強したらいいかわかんない… とにかく正規化を学んで欲しい
148 18/06/16(土)22:51:37 No.512219408
必要になったら覚えればいいというか 基本的に必要になってどうにかするために取り組まないと身に付かない感じだとおもう
149 18/06/16(土)22:51:41 No.512219424
text型の複合インデックスつけるね
150 18/06/16(土)22:51:42 No.512219435
正規形は絶対に崩さないんですけお！！１！！！１１！ 性能はインフラで確保してくだち！！！１１１！！！
151 18/06/16(土)22:51:48 No.512219462
>SQLを性能重視して設計するのってどうすればいいの いいマシンを買う
152 18/06/16(土)22:51:54 No.512219502
>数千万件ぐらいのダミーデータ作って遊んでみるのがいいよDBについての理解が深まる >まあだいたいは本番トラブルで泣いて痛い目みつつ覚えるわけだが… ああそっか実際にやってみればいいのか
153 18/06/16(土)22:52:05 No.512219548
pgsqlでxml型めっちゃ使ってて検索がめどい
154 18/06/16(土)22:52:09 No.512219572
設計仕事してるのにSQL読めすらできないってすげーな…
155 18/06/16(土)22:52:11 No.512219585
>>SQLを性能重視して設計するのってどうすればいいの >いいマシンを買う ストレージをSSDにする
156 18/06/16(土)22:52:18 No.512219618
正規化！ 正規化解除！
157 18/06/16(土)22:52:22 No.512219643
ライセンスは会社が勝手に買うから何も気にしてなかったけど Oracleそんなヤバイの
158 18/06/16(土)22:52:25 No.512219659
DynamoDB使い始めたけど障害対応とかで予期せぬ列でソートや絞り込みしようとするとつらい
159 18/06/16(土)22:52:27 No.512219670
Mongoの中身はほぼJSONだな 索引の仕方がよくわからない
160 18/06/16(土)22:52:38 No.512219716
>>SQLを性能重視して設計するのってどうすればいいの >いいマシンを買う 富豪的解決法来たな… あまりにも古いシステムは実際それで上手く行ったりするのが困る
161 18/06/16(土)22:52:39 No.512219720
NULL絶対殺すマン VS 安易にNULL入れるマン の戦争が職場で起きてる
162 18/06/16(土)22:52:40 No.512219727
>SQLアンチパターン読んで第三正規化くらいまではちゃんと考えて欲しいマジで... >IDに意味をもたせるやつ死んで欲しい 絶対に値が変わらないと確定してるマスタ系のテーブルなら良いよ …いや、やっぱり微妙だな そんなことあるわけがねぇ
163 18/06/16(土)22:52:59 No.512219808
私RDBのカラムにjsonそのまま突っ込むの好き！
164 18/06/16(土)22:53:06 No.512219852
お国のシステムやってた時は国民全員分の件数扱う必要あるから スペシャリストみたいな人がひたすら性能改善ばっかやってたな
165 18/06/16(土)22:53:06 No.512219854
>SQLを性能重視して設計するのってどうすればいいの お客を説得して過去データの保持期間をとにかく短くする
166 18/06/16(土)22:53:08 No.512219863
メモリを8G→96Gにしたら解決しました チューニングとはこうやるんだ
167 18/06/16(土)22:53:09 No.512219874
>>数千万件ぐらいのダミーデータ作って遊んでみるのがいいよDBについての理解が深まる >>まあだいたいは本番トラブルで泣いて痛い目みつつ覚えるわけだが… >ああそっか実際にやってみればいいのか いろんなSQL書いて実行計画取ってみると何行のデータにアクセスしてCPUどんだけ使って所要時間何秒みたいなのが出てくるので眺めて楽しむのだ
168 18/06/16(土)22:53:18 No.512219917
>逆にそれなら首の心配ないじゃんよかったじゃん >…糞大変そうなのは分かる SQLが書ける＝DBのこと何でもわかると思われているフシがある そのシステムのデータ構造なんてしらねーよ
169 18/06/16(土)22:53:18 No.512219918
社長が「AS400は高いからSQLServerにしよう！」 って既存システム全置換えが動き始めたけど絶対同じスピードでなくてやらなきゃよかったってなるやつで逃げたい
170 18/06/16(土)22:53:22 No.512219936
絶対よくねぇ！
171 18/06/16(土)22:53:28 No.512219959
>設計仕事してるのにSQL読めすらできないってすげーな… 今はもう存在してないような飛沫DB製品でSQL覚えちゃったせいで 矯正が面倒でたまらない
172 18/06/16(土)22:53:37 No.512220006
>更新日 char(8) >更新時間 char(6) 今やってるのが更新日+更新時間でvarcharなんだ…
173 18/06/16(土)22:53:39 No.512220011
>NULL絶対殺すマン VS 安易にNULL入れるマン >の戦争が職場で起きてる スペース入れるマンよりはNULLマンの方がマシだ
174 18/06/16(土)22:53:43 No.512220027
OracleのExadataはいいぞ！
175 18/06/16(土)22:53:57 No.512220082
>富豪的解決法来たな… >あまりにも古いシステムは実際それで上手く行ったりするのが困る メモリ増し増しで対象データがキャッシュに全部乗ったらパフォーマンス数百倍とか上がるしね
176 18/06/16(土)22:54:03 No.512220114
とりあえずslow query onにしてN+1をログから探して解決するだけでだいぶマシになる 頼むから動かすだけでわかるN+1を入れないでくれ
177 18/06/16(土)22:54:06 No.512220122
>IDに意味をもたせるやつ死んで欲しい IDはGUIDにして意味を持たせないし絶対に見せない！
178 18/06/16(土)22:54:10 No.512220140
>社長が「AS400は高いからSQLServerにしよう！」 >って既存システム全置換えが動き始めたけど絶対同じスピードでなくてやらなきゃよかったってなるやつで逃げたい 今からでもPostgresに変えてください！って言おう！
179 18/06/16(土)22:54:10 No.512220142
>NULL絶対殺すマン VS 安易にNULL入れるマン >の戦争が職場で起きてる テストで正にばく起きてるわ どっちが悪いっつーか機能感の連携ができてない…
180 18/06/16(土)22:54:25 No.512220216
>NULL絶対殺すマン VS 安易にNULL入れるマン >の戦争が職場で起きてる NULLは邪悪なので絶対に許してはいけないぞ 絶対に許すなよ
181 18/06/16(土)22:54:35 No.512220262
Oracleは殿様商売やりすぎて死にそうって話は５年位前にきいたけど今どうなってるんだ
182 18/06/16(土)22:54:35 No.512220265
ある程度までは大容量メモリとSSDで何とかなる でもクソSQLは結局直さないとどうにもならん
183 18/06/16(土)22:54:47 No.512220317
いつになったら業界からAS/400消え失せるの…？
184 18/06/16(土)22:54:49 No.512220324
SQLはなんであんなに融通きかないの…ケンカ売ってのかテメー！
185 18/06/16(土)22:55:04 No.512220386
>IDに意味をもたせるやつ死んで欲しい うちの会社でもようやくキーそのものに意味を持たせるのは非効率的だし メンテも大変だし世間一般的な作り方とも逸脱してるのでやめましょう！って呼びかけがあったけど あっただけで終わった
186 18/06/16(土)22:55:11 No.512220415
null許容項目に半角スペースをフル桁で突っ込む！
187 18/06/16(土)22:55:32 No.512220497
nullが許されないからってint型の最小値が入ってる…
188 18/06/16(土)22:55:34 No.512220504
そりゃメモリ積めるだけ積んで実データを全部乗っけたらはやいだろうよ
189 18/06/16(土)22:55:35 No.512220506
簡単なクエリ書くくらいなら出来ても 実行計画とか統計情報とかの話になってくるとお手上げだ
190 18/06/16(土)22:55:37 No.512220520
必ずしも正規化が必要とは限らんけどな 費用対効果があるのかってところも含めて考えると
191 18/06/16(土)22:55:42 No.512220541
了解！NULL許容のint！
192 18/06/16(土)22:55:44 No.512220546
今はノートでもPCIe接続SSDでメモリ32GBくらいつめて HT8スレッドとかできるから 本番の奴より早かったりしてやばい
193 18/06/16(土)22:56:07 No.512220642
>>IDに意味をもたせるやつ死んで欲しい これどういう意味？
194 18/06/16(土)22:56:10 No.512220651
>null許容項目に半角スペースをフル桁で突っ込む！ 下位のプログラムでバグの原因になるからトリムしなきゃいけなくなる奴だコレ
195 18/06/16(土)22:56:11 No.512220658
勉強て…実践だよ！
196 18/06/16(土)22:56:29 No.512220731
パーティション切るといい
197 18/06/16(土)22:56:31 No.512220743
oracleは優しい顔して導入させてから数年後にライセンス契約変えたから次更新するときはこのライセンス料金でよろしくって2桁くらい上がった見積もり出してくるよ
198 18/06/16(土)22:56:33 No.512220753
DBの勉強は実践と失敗だよ
199 18/06/16(土)22:56:35 No.512220765
blobに画像突っ込む設計をした前任者を○したい
200 18/06/16(土)22:56:38 No.512220774
AS400は半角全角切り替えのシフトコードの問題で通信先とのレコード長通りに文字が入らなくて揉めるのがめんどい でも安定性とスピードは捨てがたい
201 18/06/16(土)22:56:48 No.512220814
現場で炎上した数だけエンジニアは成長するのだ
202 18/06/16(土)22:56:49 No.512220820
>null許容項目に半角スペースをフル桁で突っ込む！ その行為にNULL示すもどき的な意味以外の意味があるなら許す そうでないなら今すぐその綺麗なスペースを吹っ飛ばしてNULLにしてやる！
203 18/06/16(土)22:56:53 No.512220842
DBによって文字列型にnullや空文字入れたらどうなるか変わったりするので nullは許さないマン
204 18/06/16(土)22:56:59 No.512220869
そこでこのoracle database in-memory
205 18/06/16(土)22:57:34 No.512221009
>blobに画像突っ込む設計をした前任者を○したい 仕様ドキュメントだけ見るとやりたくなるよねえ…運用上は絶対にノゥ！だけど
206 18/06/16(土)22:57:42 No.512221040
今ならクラウドでちょっと試して消すとかできるからな
207 18/06/16(土)22:57:47 No.512221055
いいですよねプログラム側の空文字チェックがNULL考慮してないのにNULL入る項目
208 18/06/16(土)22:58:01 No.512221110
>現場で炎上した数だけエンジニアは成長するのだ 耐えられなかったやつは退職するじゃねーか！
209 18/06/16(土)22:58:13 No.512221166
>これどういう意味？ キーが文字列で 文字列の先頭3桁が会社とかを意味する文字列になってる とかじゃね
210 18/06/16(土)22:58:13 No.512221168
うちのDBにもPDFが保存されてるよ
211 18/06/16(土)22:58:13 No.512221169
>これどういう意味？ ヒトの性
212 18/06/16(土)22:58:16 No.512221189
やっぱ文字列にしといてFillerが最強だよ
213 18/06/16(土)22:58:25 No.512221217
項目に波ダッシュ入れるけど許してくれるだろうか許してくれるね グッド全角チルダ
214 18/06/16(土)22:59:04 No.512221380
抽出の命令文も書けないんだ俺…
215 18/06/16(土)22:59:17 No.512221423
>これどういう意味？ たぶん三桁の数値項目のカラムとかあるとするじゃん？ その中でも001は特別な数字だから社長用とかにするとか 100みたいに頭が1**で始まる人は部長以上の偉い人とか ただの無差別な番号として扱うべきデータそれぞれに意味持たせるなボケってこと なんでそれがダメかはぐぐってみよう
216 18/06/16(土)22:59:22 No.512221445
>これどういう意味？ http://nippondanji.blogspot.com/2013/12/id.html https://qiita.com/matsuhisa_h/items/4ab907c936db0b345b3e SQLアンチパターンを一回読むといい
217 18/06/16(土)22:59:22 No.512221446
LOBは難しいな…
218 18/06/16(土)22:59:26 No.512221462
いつ滅びるのDB2
219 18/06/16(土)22:59:54 No.512221598
なんでバイナリ型なんて許容するんです…
220 18/06/16(土)22:59:55 No.512221601
>キーが文字列で >文字列の先頭3桁が会社とかを意味する文字列になってる >とかじゃね あー でも伝票番号とか 会社番号+伝票日付+納品場所コード+連番とかやるよね・・・
221 18/06/16(土)22:59:56 No.512221603
Oracleは空文字をnullと解釈するけどSQLServerは空文字とnullを別に扱う 15万行くらいのデータ検証しててこれで一晩使ってしまった
222 18/06/16(土)23:00:12 No.512221675
>いつ滅びるのDB2 最近Db2になりました
223 18/06/16(土)23:00:26 No.512221734
>会社番号+伝票日付+納品場所コード+連番とかやるよね・・・ 別々のカラムにバラせバラせ
224 18/06/16(土)23:00:31 No.512221755
ひとのコード読んでるとこんな書き方できんの！？って文法がたまにある 教科書に載ってないんですけお
225 18/06/16(土)23:00:36 No.512221780
IDはIDであってそれ以上のものではない bit演算とかでそれそのものに意味をもたせるのは正規化できてない証拠だしバグの温床
226 18/06/16(土)23:00:39 No.512221799
アプリ側メインでやってたからそっちの作りがクソでアホみたいにselectで取りにいってDB殺す事案が前の現場ではよくあった ORマッパーは罪深いよ
227 18/06/16(土)23:00:44 No.512221831
他社から工事費用が金額だけくれるテーブルがあるんだけど なんでうちで明細に分けないといけないの…？ 明細くだち！それか明細に工事費用だけでいいでしょ！ よくない㌧
228 18/06/16(土)23:00:50 No.512221856
>抽出の命令文も書けないんだ俺… どんな時でもSELECTとLEFT JOINだぞ 今でも結合演算子使ってる人は滅びてください ついでにNULL弾くのにCOALESCE使わない人も爆発してください
229 18/06/16(土)23:00:54 No.512221871
>会社番号+伝票日付+納品場所コード+連番とかやるよね・・・ やめて...頼むからやめて
230 18/06/16(土)23:00:57 No.512221891
条件連ねれば連ねるほどクエリが不細工になる現象どうにかならないんですか
231 18/06/16(土)23:01:00 No.512221914
>なんでバイナリ型なんて許容するんです… バイナリ許さないからファイルのパス書く！ 参照先チェック処理増えた！
232 18/06/16(土)23:01:04 No.512221928
>会社番号+伝票日付+納品場所コード+連番とかやるよね・・・ そういうことだ 全部別のカラムか表にすべきなんだがな
233 18/06/16(土)23:01:11 No.512221948
>会社番号+伝票日付+納品場所コード+連番とかやるよね・・・ 個別に項目わけておいて出力のタイミングでくっつける分にはいいいんじゃない
234 18/06/16(土)23:01:18 No.512221989
>会社番号+伝票日付+納品場所コード+連番とかやるよね・・・ すぞ…
235 18/06/16(土)23:01:26 No.512222006
>>会社番号+伝票日付+納品場所コード+連番とかやるよね・・・ >別々のカラムにバラせバラせ それこそSQL文で結合すればいいだけだしな
236 18/06/16(土)23:01:44 No.512222094
>会社番号+伝票日付+納品場所コード+連番とかやるよね・・・ 殺...ぞ
237 18/06/16(土)23:01:51 No.512222123
別カラムにして取ってくるときくっつけろや！！
238 18/06/16(土)23:02:10 No.512222211
主キーを連番にして見せてると ユーザーはいつしか登録順番だとみなしちゃうしな
239 18/06/16(土)23:02:11 No.512222214
>会社番号+伝票日付+納品場所コード+連番とかやるよね・・・ 新しいVerの実装の時に組み込まれる新テーブルへの自動変換
240 18/06/16(土)23:02:20 No.512222255
いいよねconcat使ってDB内のデータと突き合わせるの やべえ全然結果返ってこねえ…
241 18/06/16(土)23:02:24 No.512222268
外部キー制約は付けない方がいいの？
242 18/06/16(土)23:02:25 No.512222270
郵便番号マスタは郵便番号自体をキーにする？IDカラム付ける？
243 18/06/16(土)23:02:25 No.512222273
>会社番号+伝票日付+納品場所コード+連番とかやるよね・・・ 主キーがそれで辛い
244 18/06/16(土)23:02:27 No.512222278
なぜSQLは非エンジニアでもいじらなければならぬのだ…
245 18/06/16(土)23:02:41 No.512222354
バイナリに画像入れないなら入れないでファイル管理のめどさが・・・
246 18/06/16(土)23:03:00 No.512222437
派遣が無限にupdateする状態のプログラム走らせてAS400殺したことがあったな トランザクション処理を物理ファイルのジャーナルに記録してて容量いっぱいになったら次を作って一つ前を消すんだけど トランザクションの途中だから前の消せずに無限にジャーナル作ってHDD容量限界まで使ってシステム落ちた 再起動しても消せないジャーナルがパンパンで起動用の領域も確保できなくてAS400が起きなくなった その派遣はその日のうちにいなくなった
247 18/06/16(土)23:03:07 No.512222465
時代はAccessですぞー！！！
248 18/06/16(土)23:03:11 No.512222485
DBエンジニア「」の怨念集まってきた！
249 18/06/16(土)23:03:24 No.512222536
>新しいVerの実装の時に組み込まれる新テーブルへの自動変換 旧プログラムで分解処理をやっていたので そこでコケるようになるレガシーシステム おい「」！なんで勝手に変えた！！！の声
250 18/06/16(土)23:03:25 No.512222542
>郵便番号マスタは郵便番号自体をキーにする？IDカラム付ける？ 郵便番号は一意じゃない
251 18/06/16(土)23:03:27 No.512222551
>なぜSQLは非エンジニアでもいじらなければならぬのだ… パソコンできるでしょ？
252 18/06/16(土)23:03:36 No.512222594
>その派遣はその日のうちにいなくなった よくあるよね
253 18/06/16(土)23:03:38 No.512222599
今思ったんだけど各DB架空のテーブルからデータ持ってくる時の記述法いい加減統一してくんねーかな…DUALだのSYS?だの
254 18/06/16(土)23:03:38 No.512222602
Amazonの購入履歴を2008年より前までさかのぼると とつぜんシステムがオラクルなんたらってでて 表示形式が違うシステムが立ち上がるのいいよね…
255 18/06/16(土)23:03:47 No.512222642
>派遣が無限にupdateする状態のプログラム走らせてAS400殺したことがあったな コワイ！
256 18/06/16(土)23:03:55 No.512222676
>外部キー制約は付けない方がいいの？ つけなくていい不具合で補正するとき面倒だからな
257 18/06/16(土)23:03:56 No.512222678
>派遣が無限にupdateする状態のプログラム走らせてAS400殺したことがあったな 当時でおいくらまんえんくらいしたんですか…？
258 18/06/16(土)23:04:01 No.512222708
>殺...ぞ 俺が設計したわけじゃないし！！！
259 18/06/16(土)23:04:15 No.512222771
>会社番号+伝票日付+納品場所コード+連番とかやるよね・・・ 会社ごと日付ごとの件数知りたいってなると性能が出ないのでやめろ と言われるのだ なんで性能が出ないかっていうとデータ取ってこないと会社と日付がわからんからで 別々なら会社がいくつで伝票日付がいつのデータ取ってこいで済む
260 18/06/16(土)23:04:22 No.512222796
実際画像データ扱う場合 テーブルとしてはどう持つのが無難なのかね？ パスは微妙な気がするけど
261 18/06/16(土)23:04:36 No.512222868
インフラ屋さんやってるんだけど覚えた方がいいのかなー インストールしてはいどうぞくらいしか今までしたことない
262 18/06/16(土)23:04:40 No.512222880
SQL分と直接関係ないログパーティション設計が狂っててDB全体が死ぬって割とある
263 18/06/16(土)23:04:45 No.512222907
>外部キー制約は付けない方がいいの？ 基本的には絶対つけたほうがいい いいんだけどO/R mapperとかの制限でつけないほうがテストが書きやすいとかいうケースが稀にある(railsとか） 十分にチームメンバーのレベルが高いならそういうときはつけない選択肢も出てくる(ちゃんとテスト書いてくれるし、データの整合性も考慮される）
264 18/06/16(土)23:04:53 No.512222944
>外部キー制約は付けない方がいいの？ 原則つけるべきだけど 統制の取れてない開発現場なら外してもいい なあに数年は問題なく動き続けてくれるさ！
265 18/06/16(土)23:04:56 No.512222962
>外部キー制約は付けない方がいいの？ それも難しい問題なんだ 理想は付けるべきと思ってはいるが
266 18/06/16(土)23:05:10 No.512223005
>会社ごと日付ごとの件数知りたいってなると性能が出ないのでやめろ >と言われるのだ それが不思議なことにウチは会社番号や 伝票日付はそれはそれで別のカラムで持っている
267 18/06/16(土)23:05:44 No.512223150
付けないなら付けないなりのテストをしろ！ってなるので付けてプリーズ♡
268 18/06/16(土)23:05:51 No.512223180
>実際画像データ扱う場合 >テーブルとしてはどう持つのが無難なのかね？ >パスは微妙な気がするけど 画像サイズによる・・・？ めちゃデカイ画像が大量に入るならファイルパス持つくらいしか出来ないんじゃ
269 18/06/16(土)23:06:00 No.512223217
テストってなんですか？
270 18/06/16(土)23:06:05 No.512223249
>それが不思議なことにウチは会社番号や >伝票日付はそれはそれで別のカラムで持っている よくある話だ… 九龍城の如くだな
271 18/06/16(土)23:06:10 No.512223278
外部キー制約がっちりつけて機能改修とか 期間内でまともにできるんですか……？
272 18/06/16(土)23:06:26 No.512223322
railsというかActiveRecord
273 18/06/16(土)23:06:26 No.512223324
>テストってなんですか？ この会社の未来を憂うわ
274 18/06/16(土)23:06:39 No.512223377
だって本番のデータ使ってテストした方が手っ取り早いし
275 18/06/16(土)23:06:42 No.512223400
>テストってなんですか？ 日本語で言ってみろ！
276 18/06/16(土)23:06:57 No.512223459
画像データをバイナリで持つなんてあるの…？
277 18/06/16(土)23:07:02 No.512223477
>>テストってなんですか？ >日本語で言ってみろ！ ほんばん！
278 18/06/16(土)23:07:09 No.512223509
>外部キー制約がっちりつけて機能改修とか >期間内でまともにできるんですか……？ だからこうしてうまく動くテストデータで誤魔化す
279 18/06/16(土)23:07:17 No.512223552
Teradataはクソって思ってごめんなさい …いややっぱり糞だよ！なんでCount結果が数値じゃねえんだよこれ！
280 18/06/16(土)23:07:18 No.512223560
>当時でおいくらまんえんくらいしたんですか…？ CDブート→HDD初期化OS再インストールで復活したから費用はかかってない 中身はテープバックアップから戻したけど業務は丸2日止まった！
281 18/06/16(土)23:07:20 No.512223563
>それが不思議なことにウチは会社番号や >伝票日付はそれはそれで別のカラムで持っている RDBMSとは...
282 18/06/16(土)23:07:21 No.512223569
>実際画像データ扱う場合 >テーブルとしてはどう持つのが無難なのかね？ >パスは微妙な気がするけど 画像データの使い方にもよるだろうけどlobを使うべきかな よーく考えて設計するんだ
283 18/06/16(土)23:07:21 No.512223572
>テストってなんですか？ テストなんてぱぱってできますよね？ スケジュール厳しかったらやらなくてもいいっしょ？ なに？上手く動かないようなもの作るわけ君たちは？
284 18/06/16(土)23:07:33 No.512223633
>実際画像データ扱う場合 >テーブルとしてはどう持つのが無難なのかね？ >パスは微妙な気がするけど ベストプラクティスは無いけど パス保存なら画像データだけサーバ分けたりするのも楽になる
285 18/06/16(土)23:07:36 No.512223650
phpのLaravelとかもそうだねActiveRecord
286 18/06/16(土)23:07:42 No.512223678
>テストってなんですか？ こわいよ…
287 18/06/16(土)23:07:44 No.512223692
テストなんかせずともバグが出たらそんとき直せばいいんだよ！
288 18/06/16(土)23:07:53 No.512223726
>中身はテープバックアップから戻したけど業務は丸2日止まった！ 2日分の営業被害額が気になるやつだこれ
289 18/06/16(土)23:08:00 No.512223766
DB有識者いないのに何故かサーバー保守してるけど テーブルに2億件レコード溜まってるのはやっぱ多すぎるのかな 数値に対する感覚が分からなくて何から手をつけたものやら
290 18/06/16(土)23:08:07 No.512223799
>画像データをバイナリで持つなんてあるの…？ Androidでsqlite3だけど電話帳データに設定するアイコンとかはそうだったはず
291 18/06/16(土)23:08:36 No.512223943
>テーブルに2億件レコード溜まってるのはやっぱ多すぎるのかな 業務次第では普通だよ
292 18/06/16(土)23:08:48 No.512224004
>テーブルに2億件レコード溜まってるのはやっぱ多すぎるのかな >数値に対する感覚が分からなくて何から手をつけたものやら パーティション化しろ してて性能が十分でストレージに余裕あるならいいんじゃね
293 18/06/16(土)23:08:48 No.512224010
こんなリカバリできるか不明なシステムでDBA名乗るなんて各方面に失礼だよね
294 18/06/16(土)23:09:00 No.512224060
そういやSQL書いて長いけど実戦で覚えた事ばかりで正規の勉強した事無いな ブロンズとかシルバーを取った方がいいのかな？
295 18/06/16(土)23:09:00 No.512224062
火狐のブックマークアイコンって sqliteにバイナリで保存されてないっけ
296 18/06/16(土)23:09:18 No.512224149
>>画像データをバイナリで持つなんてあるの…？ >Androidでsqlite3だけど電話帳データに設定するアイコンとかはそうだったはず アイコン画像程度の少数の固定リソースならDBに一括管理でいいね
297 18/06/16(土)23:09:21 No.512224155
>テーブルに2億件レコード溜まってるのはやっぱ多すぎるのかな 性能出ないよって文句が出てくるなら多すぎる 出てこないなら大丈夫
298 18/06/16(土)23:09:24 No.512224173
>実際画像データ扱う場合 DBにはcloudinaryのIDだけ入れて使ってる CDN対応が出てくることを考えるとDBには画像IDだけってのが基本になると思う
299 18/06/16(土)23:09:29 No.512224202
>なに？上手く動かないようなもの作るわけ君たちは？ 流石にもうこんなシステム設計屋はいないとおもいたい
300 18/06/16(土)23:09:39 No.512224246
>そういやSQL書いて長いけど実戦で覚えた事ばかりで正規の勉強した事無いな >ブロンズとかシルバーを取った方がいいのかな？ 正規化とかの勉強ならそれこそDBスペシャリストでいいんでないの
301 18/06/16(土)23:09:54 No.512224302
>そういやSQL書いて長いけど実戦で覚えた事ばかりで正規の勉強した事無いな >ブロンズとかシルバーを取った方がいいのかな？ そこらへんは製品知識しか出ないんじゃないの
302 18/06/16(土)23:09:56 No.512224313
こわい！「」がまともなこと言い始めてる！
303 18/06/16(土)23:10:03 No.512224341
>流石にもうこんなシステム設計屋はいないとおもいたい 営業や顧客じゃなくて設計屋がこんなこと言ってたらぶん殴られるよぉ！
304 18/06/16(土)23:10:17 No.512224392
派遣の兄ちゃんが作ったアクセスのツールがめっちゃ便利だから全社展開したい！みたいな闇の深い案件ばっかり転がり込んでくるのでアクセスはこの世から消えてほしい
305 18/06/16(土)23:10:17 No.512224394
>数値に対する感覚が分からなくて何から手をつけたものやら 過去何年分ってわりきり決めて ここ10年アクセスがない顧客データはわりきって削除とか
306 18/06/16(土)23:10:20 No.512224402
開発規模に対して圧倒的に不足する試験項目数 ねえこれテストじゃなくてビルド後のかるいチェックなのでは…？
307 18/06/16(土)23:10:51 No.512224533
>郵便番号は一意じゃない >流石にもうこんなシステム設計屋はいないとおもいたい エンドユーザかな…未だにいるよ
308 18/06/16(土)23:11:07 No.512224592
>こわい！「」がまともなこと言い始めてる！ 土曜日で精神に余裕があるからな… 日曜日だと壊れる
309 18/06/16(土)23:11:24 No.512224652
うちが技術力が高いからテストなんて必要無い って上司がいってた
310 18/06/16(土)23:11:31 No.512224679
>パーティション化しろ >してて性能が十分でストレージに余裕あるならいいんじゃね パーティション化してないわ ググって見る･･･
311 18/06/16(土)23:11:31 No.512224680
理想と現実の狭間で不満と愚痴が溜まっているのだ
312 18/06/16(土)23:11:39 No.512224712
>ねえこれテストじゃなくてビルド後のかるいチェックなのでは…？ 不満があるなら客から金もらってきてくだち
313 18/06/16(土)23:11:40 No.512224716
>うちが技術力が高いからテストなんて必要無い >って上司がいってた その上司どうなった？
314 18/06/16(土)23:11:57 No.512224781
時間なくて開発したものを即STにぶち込むような状況だけど許してくれるだろうか 許してくれるね
315 18/06/16(土)23:11:58 No.512224784
郵便番号はAPIで取ろうぜ！
316 18/06/16(土)23:11:59 No.512224788
ソシャゲ屋やってると shardingまでしないといけない
317 18/06/16(土)23:12:04 No.512224812
ホスト由来のデータを取り扱うトラン一個の最悪なAccessシステムメンテしてたけど 保守性考えるとクエリで正規化するしかなくてマスタテーブルはむしろ綺麗に揃ってしまって複雑な気分になったな…
318 18/06/16(土)23:12:13 No.512224842
今すべきテストをめんどいってやらないでいると後で100倍返し高んな！ってあるよね
319 18/06/16(土)23:12:31 No.512224925
パーテションしてあると4億超えてもカウントは数秒で戻ってくる してないとどんだけかかるんだろこれ…
320 18/06/16(土)23:12:43 No.512224981
技術力ってテストも含めた品質が高いことだと思うんですけお
321 18/06/16(土)23:12:50 No.512225016
>ソシャゲ屋やってると >shardingまでしないといけない トランザクション多すぎ問題
322 18/06/16(土)23:12:50 No.512225017
その会社番号だのひづけだのを連結するIDってのは昔のDBだと絡む増やせないから生まれた文化なの？
323 18/06/16(土)23:12:52 No.512225024
>テーブルに2億件レコード溜まってるのはやっぱ多すぎるのかな >数値に対する感覚が分からなくて何から手をつけたものやら データのライフサイクルを決めるんだ
324 18/06/16(土)23:13:00 No.512225058
>開発規模に対して圧倒的に不足する試験項目数 >ねえこれテストじゃなくてビルド後のかるいチェックなのでは…？ それ通ったら検収印貰えるんだろう？ あとは野となれ山となれだ！
325 18/06/16(土)23:13:01 No.512225060
>パーテションしてあると4億超えてもカウントは数秒で戻ってくる >してないとどんだけかかるんだろこれ… マジかすげえな
326 18/06/16(土)23:13:05 No.512225081
Accessを一方的に悪くいうシステム屋は嫌いだな…
327 18/06/16(土)23:13:14 No.512225125
>>実際画像データ扱う場合 >DBにはcloudinaryのIDだけ入れて使ってる >CDN対応が出てくることを考えるとDBには画像IDだけってのが基本になると思う データ大きかったりするとやっぱりそうなるかね...
328 18/06/16(土)23:13:18 No.512225138
外部制約キーは結局1度も付けたことない･･･
329 18/06/16(土)23:13:26 No.512225164
基本は現地調整するだろうしテストしなくてもいいんじゃないかなはわかる
330 18/06/16(土)23:13:38 No.512225200
>今すべきテストをめんどいってやらないでいると後で100倍返し高んな！ってあるよね 100倍で済めばいい方 リリース後100万倍くらいされる
331 18/06/16(土)23:13:44 No.512225235
>その会社番号だのひづけだのを連結するIDってのは昔のDBだと絡む増やせないから生まれた文化なの？ どっちかっていうと紙で管理してたのをそのまま同じ気分でぶっ込んでるんじゃないか
332 18/06/16(土)23:13:44 No.512225236
初めてMyISAMで作られてるテーブル触ってうん億レコードが入ってるテーブルのcountが即返ってきてすげーってなった それいがい困ることしかないけどMyISAM
333 18/06/16(土)23:13:56 No.512225280
>マジかすげえな 1データしか返さないからね…全レコード返すとなったらそら時間かかるけどそこはクライアント側のスペックも必要だし
334 18/06/16(土)23:14:02 No.512225308
AWS Auroraのdb.r4.16xlarge使ってるけど超早いし ストレージも64TBまで自動拡張されるから凄いいいよ CPU64コアメモリ488GB積んでる 1台月90万円ぐらいだけど性能考えたら安い
335 18/06/16(土)23:14:04 No.512225320
カラムナーDBしゅごい もう全部これでやりたい
336 18/06/16(土)23:14:11 No.512225357
公共系とオープン系で客のテストの考え方が違って困る…
337 18/06/16(土)23:14:11 No.512225363
>トランザクション多すぎ問題 multiDB transactionマジでしんどい しんどいからほんとに疎結合にしてマイクロサービス化進めてるけどつらい ほんとに辛い 今が辛い
338 18/06/16(土)23:14:12 No.512225364
テストの考え方をちゃんと教えてる学校も資格も無いからね 現場で覚えるしかない
339 18/06/16(土)23:14:18 No.512225396
>その会社番号だのひづけだのを連結するIDってのは昔のDBだと絡む増やせないから生まれた文化なの？ 単に昔からある表記方法ってだけだね… データを管理するのが人だったときの名残
340 18/06/16(土)23:14:25 No.512225425
>その上司どうなった？ 取締役になったよ
341 18/06/16(土)23:14:26 No.512225427
いやあ怖いですよねデッドロック！
342 18/06/16(土)23:14:26 No.512225430
>100倍で済めばいい方 >リリース後100万倍くらいされる (そのとき当時担当してたエンジニアはもういない)
343 18/06/16(土)23:14:40 No.512225474
>実際画像データ扱う場合 クラウドのオブジェクトストレージのパスだけ保存しておくのオススメ
344 18/06/16(土)23:14:45 No.512225492
>その会社番号だのひづけだのを連結するIDってのは昔のDBだと絡む増やせないから生まれた文化なの？ 設計技術が未熟だったせいだったり DB容量が少なくてやむにやまれぬだったり DBのオートインクリメントが信用できない時代の遺物だったり
345 18/06/16(土)23:14:54 No.512225535
>>その上司どうなった？ >取締役になったよ 流石IT立国を目指してた国だな日本！ しねばいい
346 18/06/16(土)23:15:03 No.512225574
>>その上司どうなった？ >取締役になったよ …今よりいい会社を探す準備しよっか
347 18/06/16(土)23:15:09 No.512225606
>>その会社番号だのひづけだのを連結するIDってのは昔のDBだと絡む増やせないから生まれた文化なの？ >どっちかっていうと紙で管理してたのをそのまま同じ気分でぶっ込んでるんじゃないか 紙起票のものを転記したいとか その転記した伝票を紙についてる番号で検索したいとか
348 18/06/16(土)23:15:33 No.512225710
>multiDB transactionマジでしんどい >しんどいからほんとに疎結合にしてマイクロサービス化進めてるけどつらい ほんとに辛い 今が辛い マルチDBトランザクションってあの誰も使ってないという伝説のXAトランザクションの使い手か！？
349 18/06/16(土)23:15:33 No.512225715
>>100倍で済めばいい方 >>リリース後100万倍くらいされる >(そのとき当時担当してたエンジニアはもういない) （当時のプロジェクトリーダーは役員になってて文句言えない）
350 18/06/16(土)23:15:39 No.512225738
見てくれよこのカラム名が謎の英数字で構成されたDB！
351 18/06/16(土)23:15:40 No.512225743
運用屋さんやってるとつらい… 数年経つとORACLEさんがこっちにする！って馬鹿な方を選び始めてつらい
352 18/06/16(土)23:16:12 No.512225870
XA…頭が…
353 18/06/16(土)23:16:16 No.512225890
カラム名のつづり間違ってる…
354 18/06/16(土)23:16:19 No.512225904
>見てくれよこのカラム名が謎の英数字で構成されたDB！ CL01いいよね…やめて…
355 18/06/16(土)23:16:21 No.512225911
>データ大きかったりするとやっぱりそうなるかね... cloudinaryほんとにいいよ CDN対応勝手にしてるし URL queryで画像の伸縮拡縮自由にできるし画質管理もできる リソースバカ食いで セキュリティホールの温床のimagemagick入れなくて済むのが嬉しい
356 18/06/16(土)23:16:27 No.512225933
>見てくれよこのカラム名が謎の英数字で構成されたDB！ 漢字表記をローマ字で直したのの子音だけ抽出して繋げる命名規則とかあったなあ…
357 18/06/16(土)23:16:38 No.512225981
>見てくれよこのカラム名が謎の英数字で構成されたDB！ 意味がわかればそれで良いけど大抵コメントも整備されてない…
358 18/06/16(土)23:16:43 No.512225993
年号変更を乗り越えたあと 今消費税率を1桁で保持しているDBが消費税10%化で軒並み死ぬってあった 自業自得だと思う
359 18/06/16(土)23:16:43 No.512225994
HDDアクセスは遅いってイメージを未だに持ってるからか サーバ上のファイルじゃなくBLOBに入れたがる人の気持ちは判る
360 18/06/16(土)23:17:00 No.512226060
>Accessを一方的に悪くいうシステム屋は嫌いだな… 上のトラン一個の奴のことならクソなのはその設計であってAccessはむしろかなり良くできてると思ってるぞ JETにしろVBAにしろ基礎設計の古さによるつらみはあるけど ちゃんとDB的に正しい集合を食わせればめっちゃ強力だと思う 特にレポートの表現力は値段からしたら信じられんくらい
361 18/06/16(土)23:17:01 No.512226064
>数年経つとORACLEさんがこっちにする！って馬鹿な方を選び始めてつらい オプティマイザさん急にトチ狂うよね おめー統計情報もほとんど変わってねーだろ！ なんで実行計画変えた！
362 18/06/16(土)23:17:08 No.512226080
>漢字表記をローマ字で直したのの子音だけ抽出して繋げる命名規則とかあったなあ… うちも似たようなのあったわ… なれると案外読み取れるから悪くないのかと思ったんだが どうなんだろう
363 18/06/16(土)23:17:23 No.512226138
>その転記した伝票を紙についてる番号で検索したいとか 検索したいならきちんとばらしておけよ…あと紙フォーマットから読み込みとか大本が不安定なばらつきあるデータを無理やり使うんじゃねえ！ おめえらのことだぞ官公庁！！
364 18/06/16(土)23:17:43 No.512226224
>今消費税率を1桁で保持しているDBが消費税10%化で軒並み死ぬってあった >自業自得だと思う それは流石に頭日大すぎる…
365 18/06/16(土)23:17:45 No.512226232
>>漢字表記をローマ字で直したのの子音だけ抽出して繋げる命名規則とかあったなあ… >うちも似たようなのあったわ… >なれると案外読み取れるから悪くないのかと思ったんだが >どうなんだろう 「」が一通語をよく理解してるのってやっぱりそういう…
366 18/06/16(土)23:17:52 No.512226263
マイクロサービスはまともに運用できる能力無いとしぬ世界に聞こえる サービス毎にDB作ってどうやって連携させるんだ…
367 18/06/16(土)23:18:05 No.512226303
そういやNoSQLって流行んないね やっぱりトランザクション処理できないからかな
368 18/06/16(土)23:18:05 No.512226306
ローマ字由来の項目名はSQL描いた時に並びがガタガタになるから好きじゃない
369 18/06/16(土)23:18:15 No.512226346
>年号変更を乗り越えたあと 今その話しないでくれるかな！！！1！
370 18/06/16(土)23:18:21 No.512226365
>今消費税率を1桁で保持しているDBが消費税10%化で軒並み死ぬってあった >自業自得だと思う 良かったー税率ソースに直書きで！
371 18/06/16(土)23:18:23 No.512226379
軽減税率がマジでヤバい
372 18/06/16(土)23:18:45 No.512226466
>「」が一通語をよく理解してるのってやっぱりそういう… あー…あー……
373 18/06/16(土)23:18:50 No.512226487
いいですよね yobi1とかで取得するようになってしまったシステム…
374 18/06/16(土)23:18:50 No.512226488
>それは流石に頭日大すぎる… つうか文字列なのかなもしかして…デシマルじゃねえのかな
375 18/06/16(土)23:18:51 No.512226491
>サービス毎にDB作ってどうやって連携させるんだ… DB自体は共有するケースも有るけど 技術力がないと既存のモノリシックなサービスが複数乱立する地獄が発生するぞ！
376 18/06/16(土)23:19:01 No.512226542
>>漢字表記をローマ字で直したのの子音だけ抽出して繋げる命名規則とかあったなあ… syn_no（社員番号） shn_mi（商品名）
377 18/06/16(土)23:19:07 No.512226560
>今消費税率を1桁で保持しているDBが消費税10%化で軒並み死ぬってあった 顧客は死ぬけどベンダー大喜びじゃね
378 18/06/16(土)23:19:16 No.512226584
まさかOracleの元号変換機能を使ってる会社がいるのか…？
379 18/06/16(土)23:19:19 No.512226600
gff...tkkn...
380 18/06/16(土)23:19:33 No.512226655
>そういやNoSQLって流行んないね >やっぱりトランザクション処理できないからかな みんな使い方を間違ってるから...
381 18/06/16(土)23:19:57 No.512226763
>そういやNoSQLって流行んないね >やっぱりトランザクション処理できないからかな 取って代わる程ではないが要所では利用されているんじゃないか
382 18/06/16(土)23:20:08 No.512226812
>みんな使い方を間違ってるから... すまない…キーバリュータイプの集合体なんじゃねえのこれ？って思っててすまない…
383 18/06/16(土)23:20:09 No.512226814
>syn_no（社員番号） >shn_mi（商品名） でも「しゃ」はYで「しょ」はHってのはわかる…
384 18/06/16(土)23:20:23 No.512226864
SHACHO_FLAG ってINT(8) columnを見たときに 会社を辞める決意をしました 今ではかなりしあわせです
385 18/06/16(土)23:20:50 No.512226969
>なんで実行計画変えた！ 馬鹿みたいな話だけど急にトチ狂うぐらいだったら最初からヒント入れておいたほうがいいのかな… でもこれでうまくいっているところもありそうだしうーむ
386 18/06/16(土)23:20:59 No.512226998
Oracleで異なるDB間でかなりリアルに データを参照被参照しなきゃいけない場合って どういう方式がベストプラクティスなんだろう DBLinkはおっそいし負荷かかるし マテビューはストレージ無駄だし
387 18/06/16(土)23:21:00 No.512227001
>SHACHO_FLAG ってINT(8) columnを見たときに >会社を辞める決意をしました 鶴の一声フラグ…何に使ってたんだ
388 18/06/16(土)23:21:01 No.512227009
>SHACHO_FLAG ってINT(8) ちょっと可愛いじゃないか…
389 18/06/16(土)23:21:20 No.512227075
日本語ローマ字で開き直ってる感じの奴は割と好き
390 18/06/16(土)23:21:22 No.512227081
SQLは常に全件抽出でAP側で絞るのいいよね
391 18/06/16(土)23:21:24 No.512227093
>そういやNoSQLって流行んないね >やっぱりトランザクション処理できないからかな MongoDBで通販サイト作りました！ってブログ記事があって トランザクションどうしてるのだろうとおもったら1レコードに対するトランザクションはなんとかできるからそれで頑張ってた 例えば25cmと26cmのスニーカーが在庫で100個づづあったら レコードを200個つくってそれぞれの注文時にレコードを引き当てるというものすごい力業だった まだあるかなその会社
392 18/06/16(土)23:21:25 No.512227099
SHACHO_FLAGなのにBOOLではないのか…
393 18/06/16(土)23:21:30 No.512227140
>syn_no（社員番号） >shn_mi（商品名） https://codic.jp/engine 時々これ使ってるな でもちがう！！！ってなるときもある
394 18/06/16(土)23:21:43 No.512227189
Cassandraは使い方さえ間違えなければいいやつだよ NoSQL使えばDB使わなくて済むって考え方がまずいんだよな 使うなら両方使うことになるのに
395 18/06/16(土)23:21:50 No.512227228
>SHACHO_FLAG ってINT(8) columnを見たときに 何用の情報なのかぜんぜんわからん
396 18/06/16(土)23:21:52 No.512227242
>Oracleで異なるDB間でかなりリアルに >データを参照被参照しなきゃいけない場合って >どういう方式がベストプラクティスなんだろう システム提案段階でお客に良いマシンを買ってもらう
397 18/06/16(土)23:21:53 No.512227244
何のテーブルにあったんだ…
398 18/06/16(土)23:21:57 No.512227266
Win+SQLServer高いし他の部署はOracle使ってるからLinux+Oracleに乗せ換えようって言われてんだけど うちの技術力で保守できるわけねーだろって思ってる
399 18/06/16(土)23:21:58 No.512227268
>Cassandraは使い方さえ間違えなければいいやつだよ >NoSQL使えばDB使わなくて済むって考え方がまずいんだよな >使うなら両方使うことになるのに おっワークスアプリケーションズのことか？
400 18/06/16(土)23:22:01 No.512227275
>SHACHO_FLAGなのにBOOLではないのか… ぶーるつかうなvarchar(1)にしろってことさ
401 18/06/16(土)23:22:31 No.512227422
>SHACHO_FLAGなのにBOOLではないのか… １なら社長 ２なら会長 ３なら会長の奥さん
402 18/06/16(土)23:22:35 No.512227451
>>SHACHO_FLAGなのにBOOLではないのか… >ぶーるつかうなvarchar(1)にしろってことさ そこはCHAR(1)じゃねえの！？
403 18/06/16(土)23:22:38 No.512227470
>SHACHO_FLAGなのにBOOLではないのか… そこで心が折れました User.SHACHO_FLAG 社長以外にも立ちまくってたし...
404 18/06/16(土)23:22:47 No.512227530
>SQLは常に全件抽出でAP側で絞るのいいよね 1年持たなそう･･･
405 18/06/16(土)23:22:51 No.512227557
フラグじゃないだろ 役職のテーブル作れよぉ！
406 18/06/16(土)23:22:53 No.512227561
AzureとSQLServerとC#で開発してたときめっちゃ楽だったわ…
407 18/06/16(土)23:22:59 No.512227584
>>SHACHO_FLAG ってINT(8) columnを見たときに >何用の情報なのかぜんぜんわからん 提案それぞれに社長の承認がおりた日付とか…？
408 18/06/16(土)23:23:04 No.512227618
社長フラグではなく シャチョさんフラグなのかもしれない
409 18/06/16(土)23:23:07 No.512227635
>>SHACHO_FLAGなのにBOOLではないのか… >そこで心が折れました >User.SHACHO_FLAG 社長以外にも立ちまくってたし... 車長のフラッグだったのかもしれん
410 18/06/16(土)23:23:46 No.512227781
ビジネスドメイン的には重役のフラグっぽくて このフラグが立ってると重要機能が閲覧できるフラグだった
411 18/06/16(土)23:23:59 No.512227847
OracleにBool型カラムないからね なんでないんだ
412 18/06/16(土)23:24:01 No.512227858
>そこで心が折れました >User.SHACHO_FLAG 社長以外にも立ちまくってたし... 社長命令で対応変えてたuserなのかもしれないし…
413 18/06/16(土)23:24:07 No.512227884
>提案それぞれに社長の承認がおりた日付とか…？ でもINT型ですよ
414 18/06/16(土)23:24:16 No.512227918
わからない…わからないんだ
415 18/06/16(土)23:24:22 No.512227938
わかるよ操作権限で社長しかできない操作があるんだよね 実際には社長が部下に仕事丸投げするから >User.SHACHO_FLAG 社長以外にも立ちまくってたし...
416 18/06/16(土)23:24:30 No.512227965
>>なんで実行計画変えた！ >馬鹿みたいな話だけど急にトチ狂うぐらいだったら最初からヒント入れておいたほうがいいのかな… >でもこれでうまくいっているところもありそうだしうーむ ヒントで固定するやつが最適だと最初から分かってるなら固定していいと思う 実際は本当に最適かよくわからんのでDBMS側に任せる >急にトチ狂う
417 18/06/16(土)23:24:49 No.512228045
>Oracleで異なるDB間でかなりリアルに >データを参照被参照しなきゃいけない場合って >どういう方式がベストプラクティスなんだろう >DBLinkはおっそいし負荷かかるし >マテビューはストレージ無駄だし OracleとSQL_SERVERのデータ共有は一回JAVAかましてたなあ…リアルタイムじゃなくてバッチでだけど
418 18/06/16(土)23:24:51 No.512228055
権限委譲(丸投げ)
419 18/06/16(土)23:24:51 No.512228059
>OracleにBool型カラムないからね >なんでないんだ 個人的には混乱の元になるから無いんじゃないかな… というか他でもフラグはINT(2)とかが多い気がする
420 18/06/16(土)23:25:20 No.512228162
>わかるよ操作権限で社長しかできない操作があるんだよね >実際には社長が部下に仕事丸投げするから 本当に社長以外まずいやつがあってSHACHO_FLAG2とか増えそう
421 18/06/16(土)23:25:34 No.512228221
>本当に社長以外まずいやつがあってSHACHO_FLAG2とか増えそう エスパー大成功すぎる
422 18/06/16(土)23:25:35 No.512228230
DBのこと全然分かんないけどoracleとSQLserverでSQL書き方違ってて折れそう
423 18/06/16(土)23:25:45 No.512228273
NoSQL！
424 18/06/16(土)23:25:48 No.512228282
>本当に社長以外まずいやつがあってSHACHO_FLAG2とか増えそう すげぇありそう…
425 18/06/16(土)23:26:00 No.512228325
実際はBUCHO_FLAGだったけど...
426 18/06/16(土)23:26:01 No.512228329
PL/SQLにはbool型あるけどね
427 18/06/16(土)23:27:00 No.512228556
>今消費税率を1桁で保持しているDBが消費税10%化で軒並み死ぬってあった >自業自得だと思う 200%くらいはいくかもしれないよね