企画や営業など非エンジニア職がSQLを勉強したらメリットばかりだった話 - paiza開発日誌

2017/06/20 20:15:42

quality1

やるか

2017/06/20 20:19:09

fashi

どこで活用するんだろ。Access？ MySQL解放してるの？

2017/06/20 21:41:49

netcraft3

PHPMyAdminで充分と言う人もいるけど、PHPMyAdminはグループ化とか使いにくいからSQLの知識はあった方がいい。

2017/06/20 22:31:12

boobook

社内システムの組み方にもよるから会社によるとしか。

2017/06/20 22:43:58

ysk-ur

なんども挫折してるから「テーブル構造が複雑で属人化しているを解決する」エントリーがほしいです。

2017/06/21 00:53:42

tekimen

デメリットとして誤ってデータを削除してしまうリスクがある。SELECTのみ許可するロールをとかにすればリスクは軽減できるかもしれないけど、できたらどうしてるのか教えてもらえると嬉しい

2017/06/21 00:57:31

packumac

タイトルだけ読んでゾッとした。

2017/06/21 02:12:14

yug1224

以前いたところは企画営業がSQL叩くの当たり前ですごく良かった。最近はTableauなのかな？

2017/06/21 02:14:36

sykuma

非エンジニアで始めたクチですが、TableauでもカスタムSQL書けるだけで出来る事はかなり広がるのでやってて楽しい。が、周りに広げようとしても新しい事に興味を持つ好奇心がないと入口にも立ってくれなくてね…

2017/06/21 03:29:33

midastouch

「谷口です」の読みは「ジャガーでーす」と同じだと思う千葉県民

2017/06/21 04:49:26

youichirou

いいことだと思う。集計とかめっちゃ便利なので。 / テーブル吹っ飛ばされないように権限設定は注意したい。あとはすごく重たいクエリを連発されるとか。

2017/06/21 05:26:48

mijyunon

間違ったSQLを素人が運用する危険性もある。BIツールを導入すべき。

2017/06/21 06:28:11

fumisan

Excelのピボットテーブルで十分かなー

2017/06/21 06:52:13

hiroomi

何が欲しい、使われる用途、目的を知ってれば話ははやい。学習効果も高いと。

2017/06/21 07:00:14

notio

んー、ある程度管理に関わらない人がいじれるようになるのであればバックアップ対応をしっかりするようにするべきかなぁ。それがデメリットになり得るような気はする。

2017/06/21 07:10:41

khawai

勉強しよう

2017/06/21 07:26:33

j3q

完全にオーパーツ化したsqlをメンテする羽目になった私が通りますよ。sqlは避けて通ってたのになぁ

2017/06/21 07:35:08

pero_0104

ありがとうありがとう。当然閲覧権限だよね、こちらが何してるか知ってくれることがとても嬉しいよ。重たいクエリなげちゃったりするかもしれないし難しいのは遠慮せず相談してほしいな

2017/06/21 07:37:04

T-miura

データを見るという概念がないので、SQLを叩く依頼も来ないし、教える必要もない職場。データはあるとしてもエクセル！！

2017/06/21 07:40:57

chikurou

deleteしちゃうかも、って話はSELECT ANY TABLEだけ可能なユーザを用意すれば良いです。他スキーマを見せたくない場合は面倒でもオブジェクト単位にSELECT権限をつける

2017/06/21 08:16:20

ttom198

、

2017/06/21 08:22:17

trisjfen9

経験あるんだけど、結果、企画がSQLをちょっと齧った所為で、テーブル設計にまで口を挟み込み、エンジニアが苦しんでいたのでなんとも…

2017/06/21 08:30:27

knjname

リードオンリーのレプリケーション貼ってるんじゃないの？削除しなくてもクエリでDB応答不能にするのは可能だし / 企画や営業など非エンジニア職がSQLを勉強したらメリットばかりだった話 - paiza開発日誌

2017/06/21 08:34:42

garage-kid

142: 読まなくても異論がない話。

2017/06/21 08:35:24

pintinho

開発系のエンジニアとサポート系のエンジニアと仕事を分けるのが幸せになれる方法だと思う。

2017/06/21 08:39:40

teppay75

これは確実に、この種の人が運用にも口挟んでくる気がするな。知ったかな人を増やすだけになりかねん諸刃の剣やぞ。

2017/06/21 08:40:29

reteria

個人情報とか大丈夫なんだろうか

2017/06/21 08:56:38

kirarapoo

エンジニアなのにBIツールの導入とか考えないのかな？

2017/06/21 09:08:32

hisatsugu79

まさに。良記事。事務職の人が次に目指すべきプラスアルファの知識として、簿記や法務知識、HTMLなどと同じく汎用性が高くなってきてる。一度覚えたら知識をメンテするための時間もあんまり要らないし。

2017/06/21 09:17:12

NOV1975

BIツール使え／SQLを勉強する、というのは良いんだけど、なんでもかんでも触ってよいというわけでもないと思うし、どの範囲で何をやるかを決めてやらないとダメよ。

2017/06/21 09:18:25

kantei3

？？？「それ以外の職種では「SQLを使えないので、データがほしいときはエンジニアにお願いしている」という人も多いかと思います。」

2017/06/21 09:24:50

houyhnhm

PRって書いとけって。いやもう私はクリックしないし、そもそもこんなタイトルで客が引っかかるとは思えないけどさ。／SQLって何？って人に刺さる文章ではないよねえ。

2017/06/21 09:36:02

satomi_hanten

経験上システム(SQL含む)の知識がある営業は有能ばかりだった。けど片手で足りる程度しか見たことない。ゾーニングがちゃんとできるなら(あと負荷の考慮)、どんどんやって良いと思う

2017/06/21 09:42:38

deep_one

アクセスのクエリビルダが使える程度でいいと思う…

2017/06/21 09:53:02

dazz_2001

SQLをExcelに読み換えると、どこにでもある話

2017/06/21 09:54:04

mogemura

エンジニアが企画や営業の勉強するのも効果あるよ

2017/06/21 10:01:54

hdampty7

素人が気軽にSQL発行できる規模のRDBって小規模システムだけだよ。どうせ分析用スレーブとか用意してサマリー化してないと。BIにしたって生のピボット渡されても本当に欲しいデータが取れてるのか分からんだろうね。

2017/06/21 10:02:12

lifeisadog

これはちょっと違うな。

2017/06/21 10:03:11

SndOp

Drop Tableの爽快感

2017/06/21 10:04:31

versatile

クソSQL流しても大丈夫なDBがあることが前提

2017/06/21 10:10:05

lp008962

「誤ってデータを削除してしまうリスク」← GRANT SELECT ON YourDB TO SelectOnlyUser。リンクテーブルせずインポートしたACCESSあげるとか。まぁACCESS理解できるとは思えんけど

2017/06/21 10:20:22

su_zu_ki_1010

適切な権限を割り振って、テーブル構成がちゃんとなっているという前提で、非エンジニアがSQL出来るとお仕事が楽になるという現場を知っているのでこの記事については否定しないよ。

2017/06/21 10:33:24

ryun_ryun

非エンジニアがSQL使えると、データ取る能力だけでなく数字で考える力も付くのでメリットは大きい。ただ、本番環境にSQL投げちゃうと負荷だとか権限周りの注意が必要なので、その辺の対策は必要。

2017/06/21 10:36:32

ka-ka_xyz

ふと思ったけど、「特定のロールを持つユーザがクエリを発行したとき、実行計画のコストが一定以上だったら実行させない」みたいなことやれないものかな。

2017/06/21 10:38:53

mumincacao

この手のお話ちょくちょく見かけるけど本番環境以外のみらーりんぐされてる DB を準備してあることが前提かなぁ？ SELECT 限定でも残念 SQL 流されると DoS っちゃうし・・・（－ω【みかん

2017/06/21 10:42:33

rti7743

たいていは、管理画面とかの裏側にあるサーバにレプリケーションのスレーブを引いてきているわけだから、そこで分析でもなんでもすればいい。

2017/06/21 10:45:30

sds-page

MySQLは集計しようとしてサブクエリを多段にするといきなり激重になるのを何とかして欲しい

2017/06/21 10:50:48

newmind

結果、非エンジニア職が死んで元に戻るやつ。 BIツールを使え。

2017/06/21 10:50:49

yoiIT

知らないよりだいぶ良い

2017/06/21 11:01:03

dekasasaki

過去に「SQLが書ければ何でも作れますよね！？」ってよくわからない知恵をつけてしまった営業の人がいたな。ふと思い出した。

2017/06/21 11:02:38

nice_and_easy

データ抽出依頼用エクセルテンプレートとかマジわけわからんからねー。とはいえコレをやりはじめると、データ重要度に応じたアクセス制御の仕組みをDBのユーザ・権限レベルで実装しなきゃいけなくて面倒という点も

2017/06/21 11:10:42

xevra

BIツールが正解。

2017/06/21 11:26:48

yukimi1977

設計まで正しく理解してないと正しいデータが取得できない。正直怖いので、作ったSQLは確認させてほしい

2017/06/21 11:28:04

yoshikidz

だいたいselectユーザ作って渡してたけれど、まーちゃんと使う人が一人でてきたらみんな使ってくれる。prodだと変なsubquery覚え始めるとサービス止まるので、マーケ用のテーブルだけslaveとか作っておくと便利。

2017/06/21 11:37:19

karikari1255

ブコメ見て、本番のDBを直接触らせる発想はなかったので驚いた。個人情報を潰した上で同期した分析用DBを別に用意してた。仮にDELETEしても翌日の同期で元に戻るだけだし。

2017/06/21 12:00:23

honeningen

参照用のDB立てて、参照権限のみのユーザでつないでもらえば良いですよ。でもお客さんが言ってくれればそこに便乗できるけど、社内の非エンジニアのためだけにそれやるのめんどくせえってなるのかも。

2017/06/21 12:00:53

kuniku

いきなり本番（商用）で流さないで。すげー遅い場合やDBのインスタンス落ちた事ある。メモリ追い出し/CPU占有/スロークエリ/フルスキャン/個人情報もろみえ。awkでログファイル解析ならOK

2017/06/21 12:06:58

hyujico

被エンジニアが書いたSQLから取得したデータが正しいデータなのか、本人が判断するのは難しいのでは。自分なら必要とされる情報のビューと汎用的な検索画面を提供するかな。

2017/06/21 12:10:25

diam00nd

議論が活発で良い。

2017/06/21 12:17:24

tokoroten999

SQLの質問や無茶なパフォーマンスチューニングの依頼が増える未来が見えそうな気がする

2017/06/21 12:18:49

tzt

DELETEの恐怖については権限を絞ったアカウントを渡して、負荷については解析専用のスレーブを用意して本番に影響が出ないようにとかしてた記憶。

2017/06/21 12:39:03

yogasa

自分の仕事を他人に押しつけられたので工数あきましたみたいな話？（読んでない）

2017/06/21 12:50:05

honeybe

クソみたいに遅いSQL流されてエンジニアがブチ切れて権限停止まで読んだ(何

2017/06/21 12:54:59

takamocchi

社内のシステムチームがいちいち理由を付けて「データ出せない」って言うから仕方なくSQL覚えたクチ。SQLを勉強しよう！が入り口だと多分メリット感じない。データが欲しいなら覚えよう。

2017/06/21 13:08:14

shag

delete しちゃうかも？とか言ってる人たち、production には当然 replication node がいて、普通抽出とかはそっちでやるだろ？後ちょいちょい話題出てるけど、BI ツールという先人の知恵があるよ。

2017/06/21 13:09:22

sub_low

SQLわかればもっと知りたいデータが沢山眠ってることがすぐ分かるはずなのに覚えないなんて甘え

2017/06/21 13:23:15

reachout

アクセスにデータ飲ませてアクセスでシコシコデータ見てもらえばいいんじゃ

2017/06/21 13:31:33

khtno73

これはこれで準備は要る話で、Select権限のみアカウント、リードレプリカの用意、GUIもSQLも通るツール・データソース設定、BIツールとロードスクリプト、テーブル仕様の更新、漏洩対策でログ記録、あたりまでが常道か。

2017/06/21 13:32:14

oakbow

BIツール導入できればそちらの方が良い可能性があるけど、SQL触らせて悪いことは基本的にないよね。リードレプリカやその類いを準備してからにした方がいいけど。

2017/06/21 14:04:49

kaipu1224

覚えてもらうまでが大変そう

2017/06/21 14:18:11

delimiter

データの参照だけならいいんじゃない。設計に口出さなければ

2017/06/21 14:51:03

htamaaki

とりあえずReadOnlyにして、テーブルの場所と期日指定を忘れなければ誰でも触れるよね

2017/06/21 15:07:52

tyosuke2011

sql

2017/06/21 15:08:04

wordi

SELECTのみ許可の他にSlaveのみ許可も、Masterでスロークエリ実行されたらやばい

2017/06/21 15:35:21

crapman

企画が覚えたてのSQLが正しいデータを引っ張ってるかどうかも怪しいので、あまりやるべき事じゃない

2017/06/21 16:26:30

myun2-nw

よき

2017/06/21 16:28:45

jiro68

単純な構造のテーブルならともかく、複雑な構造でフラグなどでデータの状態を保持している場合、簡単に誤ったデータが出て混乱の元になる。SQLの構文エラーは修正すれば良いがなまじ値が出るとそれが一人歩きして危険

2017/06/21 16:53:51

beerbeerkun

正規化も勉強するとなおよいと思うよ

2017/06/21 17:27:18

m08084kd

SQL勉強したいですね

2017/06/21 18:14:54

chihaya9636

SQLっていうのは何か知らないけど、生産性向上のためしっかりと教育して問題を解決していく姿勢は大好きです。

2017/06/21 18:16:38

daishi_n

普通はBIツールでなんとかするよね

2017/06/21 19:04:03

securecat

今どきだとBIツールを社内啓蒙したほうがいいような気はする

2017/06/21 19:29:09

minemuracoffee

最近よく万人SQL礼賛記事見るけど、データの正確さと非エンジニアの業務効率の観点考えたら、否定的。コメントで多いけど、BI使ったほうがいい。GoogleDataStudioとか。

2017/06/21 20:35:48

komz

企画や営業など非エンジニア職がSQLを勉強したらメリットばかりだった話

2017/06/21 22:55:51

yukiyan_w

DBを触るよりBigQueryみたいなDWHやRedashみたいなBIツールでSQL練習してもらうのが主流だと思う。クエリ破産防げるし、権限管理も楽だし。

2017/06/21 23:15:58

snowcrush

「社内で非エンジニア職」と書いてあるということは、サービスを内製している企業でRedshiftみたいなDWHを叩くことを想定しているように思うので、雑に重いクエリ発行しても大して問題ないと思うけどなー。

2017/06/22 02:07:13

lehanto

みんながBIツールの使い方を勉強したらメリットばかりだったの間違いでは

2017/06/22 02:22:58

northlight

ちゃんと本番系に考慮した形で実行できるようにするのがめんどい

2017/06/22 11:47:17

grugrugru

SQL

2017/06/22 19:23:37

wwolf

営業がもっとシンプルなテーブルにしてよ（＝正規化を崩せ）とか言ってきてエンジニアイライラやで。結局分析用テーブル用意することに。

2017/06/23 00:08:27

pekeponnn31

最初は凄くそう思ってたけど、分業した方が効率いい気がする。エンジニアに対しての指示方法として勉強するのはありだと思うけど。