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