ぶっちゃけプログラミングをなにか一つ学ぶなら「SQL」一択だろ。他はそれ一つ極めても役に立たないものばかり。 [815428849]
■ このスレッドは過去ログ倉庫に格納されています
おもむろにMySQLを立ち上げればGoogleもチョロいしな サーバーサイド言語1つ
SQL少し触れる
html/css/js 少し触れる
これでなんとか使えるレベルだろ >>5
遅かったら実行計画みて直せばええだけなんでない?🤔 SQLってループ処理あるの?
これが無いとプログラミング感が薄れる >>14
今で言うならばマイクロサービスとかAPIを呼び出す側の言語ってことやろね🤔
呼び出し先が標準入力と標準出力と標準エラー出力と戻り値を備えてれば自由自在に組み合わせることが出来るという恐ろしい子なんよ😌 >>19
ORマッパーだけで済むシステムいくらでもあるだろ >>17
SQL自体には無いんよね🤔
フェッチした結果をぐるぐる回して処理させるのは別の言語の範囲なんよ ORMで済むようなシステムに必要なのはRDBではなくKVSだったのでないか
Firestore(NoSQL)使えばいいじゃん C#遣いだからちょっとしか知らんわ
奥が深そうとは思うけど 私SQLしか使えませんなんて奴が存在しないからなあ
結局VBAとかPythonとかかじってからデータベースが必要になって辿り着くから使えるんであって
それらの知識がまったくなく純粋にSQLだけって人いるんだろうか 知り合いにオラクルプラチナ持ちいるけど週3の労働で高給取りだわ
羨ましい >>17
SQLはチューリング完全ではないので、勿論そんなものは無い これ作ったあとどうやって追加していいかわかんない🥺 HTMLは言語じゃないよ
→じゃあなになの→マークアップ言語→言語じゃん もう運用しててデータも入ってるような状態から
列追加したりできるの? 第3正規形に分けるのはわかるんだけど
どうやって消すのかがわからん
子を消したら親も消すのかとか全部決めとくもんなの? >>39
insert into 〇〇 select * from ××
とやってなきゃなんの問題もないやで
やってたら死ぬ >>42
よくわからず第3正規形まで分けたから
やってますね 一つしか学ばないという前提がまずおかしいんだが
どうしても一つしか学びたくないんなら Python でもやってればいいんじゃない?
つーか普通に各パラダイム毎に最低一個は学べよ
低級手続き型言語の C
手続き型静的オブジェクト指向の C++ もしくは Java もしくは C# もしくは Rust
手続き型動的オブジェクト指向の JavaScript もしくは Python
型無し関数型言語の Lisp または Scheme
型付き関数型言語の Haskell または Scala
できれば依存型関数型言語の Idris か Agda も 言語にこだわる必要はないよ
やりたい事を実現する事を考えよう >>32
PL/SQLをSQLと認めたら「ほならJavaとかPro※Cで作ったCとかはSQLでは無いんか?」とかの話にならんやろか😞 SQLなんて最低限でいいよ
極めたところでそれが威力を発揮するのは数十年こねくり回して意味不明になったプロジェクトくらいだから 関数型はほとんどやったことない
emacsの設定ファイルでいじるためくらい
実際に実用で使ってる話もほとんど聞かない 複雑で巨大なSQL組まれるとさわれなくなるから
あまり凝ったことするんじゃないよ SQLにテーブル1つでキーとバリューだけ作ればよかった… わいはせいぜいPC数台の処理結果データ蓄積ぐらいしかやらんから
SQLiteばっか使ってる >>49
別に業務で使わなくたっていいんだよ
それでも使えるようにしておく価値はあるんだ
教養だと思いねえ
「あ、ここ関数型っぽい考え方で書いたらスッキリするわ」って場面が必ずあるから +で文字列繋げてクエリ作ったりしてそう
通はStringBuilder使う >>52
システム運用やってた時は毎日何本もクエリ書いてた
問合せとか問題があれば大体データ見るし >>55
概念に関しては別に特定の言語に依存しないからいいんだけど
結局いわゆる関数型を売りにしてる言語が実用として使われないのには使われない理由があるんでは?
反面教師のためだけに勉強してもいいけどw >>52
sqliteでローカルでしか使わないし
一人だし… from書かなくてもいいやつとか見ると心臓がバクバク言う VBAが一番や
エクセルはどんな会社でもつかうからな >>65
Androidのアプリ作る時とかやろか? お前らプログラミング得意そうで羨ましい
ses1年目の俺にアドバイスくれ >>60
5chもFacebookもhaskellつこてるしreduxはelmのまねやで? >>68
まずその前に一般的な用語の定義、顧客の用語の定義、システムの用語の定義を知るところから始めたらどうやろか?
何やりたいかの意味がわからんとそれを言語で表現出来んやろ? SQLってハードの問題じゃね?
クソなSQLでもハードが良ければ動くだろ >>69
すぐに落ちる5chに関してはダメな例っぽいがw
まぁ言語関係なくダメなのか他の言語で作られてたらもっとダメだったのかは分からんけどw こっちが書いた複雑怪奇なSQLを実行してくれるDBってすげえなって時々感心する ここらへんも小学生から教えるべきなんだよ
馬鹿老害の自民党には無理だけど ポケコンでBASIC勉強させてLEDを光らせるところから始めろ SQLというかRDBMSの考え方は義務教育にすべき 今は複雑なSQLは敬遠されるので、数日で学べる知識で十分だぞ。
昔みたいに何百行に渡るSQLなんて書こうものなら殺されるぞ >>79
銀行さんのシステムとか未だに何百行、は言い過ぎかもしれんけど100行ぐらいのSQLとかあるよね🤔 .NETとOracleかSQLServerやってりゃ事務系で生きていけるよ
ていうか基本だからそれくらいやっとけっていうレベル >>60
実用としては使われてるんだが、たとえば Java みたいに一般に普及しないのは
ただの歴史的な事情だよ
Java 的な言語が流行る → それを学ぼうとする人が増える → 企業が採用し易くなる
→ もっと流行る → わざわざ現状を変える意味ある?
って流れ
SQLってプログラミングに入れるのか?
ていうか、SQLってガチでやろうとするとめんどくせえぞ
副問い合わせを使うべきかどうかとか、エイリアスをどれくらい使うかとか
本当に正規化してテーブルを小分けにするべきか、長い一つのテーブルで管理した方が合理的かとか
そういう判断がクソめんどくさい
普通のプログラミングのほうが答えが出やすいから楽しいぞ >>72
それは暴論に過ぎる
どんな高価なハードウェアを使ったところで O(n!) の処理は O(n log n) の処理と同じ速度では動かない どんな言語も順次、反復、分岐の組み合わせで予約語が違うくらいだから好きな言語使えばいいと思う なんか最初はちゃんとORマッパー使うんだけど
そのうち痒いところに手が届かないパターンが出てきて結局SQL書くことになる >>84
その通り
SQL で頭を悩ませるのはデータ構造の定義であって
それがプログラミングの全てではない 既存概念を組み合せるパズルは個人的には嫌いじゃないんだけど
あれ普通の言語でも糞コードしか書けないような奴は使えるのか?
とんでもない糞SQLを書きそうな気がするけど GA4の登場でBigQuery使えなきゃ話にならない状況になったからSQL勉強しとくと捗るぞ Oracleってわざと使いにくくしてるだろう
後Oracleは壊しながら覚えるものだと思うの >>94
Oracle社に技術力が無いだけで、別に故意にああしているわけではなかろう >>33
まあプラチナ取るために必要な金額考えたらねえ まあ、実際データサイエンティストが一番使っているのSQLだろうからな 何をするものかさっぱり知らないのだけど
大量のデータを扱うためのもの? HTMLプログラミング最強だろお?
副作用のある言語とかダサい >>94
Oracleは何事もDB中心で考えすぎるから新しい思想を取り入れようとするとミスマッチ起こして大抵失敗するイメージなんよね🤔
まあDBとったら買収してクズ化させた資産しか残らんやろけども >>101
大量のデータから整形抽出して
使いやすい形にするのかな? SQLってそれこそノーコードで行けそうな分野に見えるんだが
実際そうではないのかね >>99
お?
副作用のない Haskell の話する?一晩中でも語ってやるぞ アフィアフィ
>>1,2 >3,4,5, >6,7,8, >9,10,11, >12,13,14,15, 16 >17,18,19,20
>21,22,23,24, >25, >26,27,28,29,30,31 ,32,33, >34,35,36 >37,38,39,40
>41,42,43,44,45 >46,47,48,49, >50,51 ,52,53, >54,55,56,57,>58,59,60
>61,62,63, >64,65,66,67,68 >69,70,71,72, >73,74,75,76, >77, >78,79,80
>81,82,83, >84,85,86,87, >88,89,90,91, 92,93,94, >95,96,97,98, >99,100 自作のスマホアプリで使ってるわ
もうファイル作ってデータ保存する時代じゃないわ これはまあ正論
プログラミング言語では無いけど
1番役に立つ GBTSQL
ゲイ、バイセクシャル、トランスジェンダー、サディスト、クエスチョニング、レズビアン
略してSQL、IT業界人はみんなだいたい馴染みがあって、ある程度自分から積極的にやれて相手の意思を感じとれないと仕事にならなかったりする >>106
じゃあData.Sequence(フィンガーツリー)の解説して
日本語の記事で紹介されてたけどいまいちよく分からん >>41
紐付けておけばデータベースに一気に消せる機能があったはず >>114
どこを解説したらいい?
普通のツリー構造はわかる? 普通のツリーというのはデータ構造全体の中心に当たる部分が
木の根本になっていて、最小値や最大値のような極端な値になるほど枝分かれを繰り返した先端部分に配置される。
一方 finger tree ではこの関係が逆になっていて、最小と最大、あるいは Data.Sequence のようにツリー全体を列と捉えるなら
列の先頭1-2番目と末尾から1-2番目の要素を木の根本に置いて、その次の要素二つが次の枝に置かれ… といった形を取る。
この構造があるから先頭と末尾へのアクセスがとても早く、逆に中心あたりのアクセスは(対数時間になるとはいえ)相対的に遅くなる。 javascript 便利
一度作ったのずっと使ってる。
UWSCで作ったマクロも毎日使ってる。上記JSをブックマークレットにした奴と組み合わせて使ってる。 日本にはガチャゲーがあるからDB技術者は豊富なんだよね >>22
ORマッパー使ってもSQL知ってる前提がほとんどだと思うが >>112
言うても、一番作業時間多いのはデータ引っこ抜く作業だと思う。というか
大概の仕事データ引っこ抜いてエクセルとかでちょっと集計して終わりとかだろうし >>116
要するに一層目は(x,x):(x,x)
二層目は((x,x),(x,x)):((x,x),(x,x))
三層目は~
みたいな構造で
追加はセルが一杯になら下層のセルとして追加する
削除はセルが空なら逆に下層から持ち上げてくる
という再帰処理が基本のデータだと思うけど
これが基本的にlogスケールなのは分かるからキューとして使うとならし定数なのは分かる気がする
ただ日経(旧itpro)の記事では遅延評価で効率よくなってるみたいな話でそのへんがよく分からない
別に全要素にアクセスするんなら同じじゃないかのと >>120
時間食うのはデータクリーニングと、あとはモデル検討の試行錯誤だろ
python/pandasで扱える状態になればSQLは使わんぞ
まあpandasのスライスやマージ、集約がSQLに相当すると言えばそうなんだが >>122
いや、モデリングする作業があんま必要とされる職場がないと思うよ。
ただ、あったとしてもpandasで完結することはあんまりないと思うよ
データ自体は通常DBに入っていて必要なデータとってくるのにSQLは必須だし >>122
こっちのほうが圧倒的に近いな
pandas前提ならSQLは引っこ抜いて終わりだからなー
モデリングしないなら
データを確認するところと可視化部分の方がまだ工数使うわ
あとPoCはDBにアクセスすらしないってもの多い >>125
いや、PoC用の外部コンサルとかよりも企業専属のデータサイエンティストのが多いんじゃないかね。
その場合は複雑なモデリングとかしないと思うよ。 >>124
そりゃデータサイエンスじゃなくて事務作業だよ
クロス表眺めて因果推定や施策立案ができるならそれでいいんだが
リアルタイム処理が要求されるなら都度クエリ投げるんだろうけど
蓋閉じられた状態ならまずはデータセットをデータフレームに固めるじゃん
そこから先にSQLの出番なくねーか >>126
モデリングしない前提で書いたんだけど
SQL引っこ抜くのが一番作業多いなら
>>127のいうとおり普通の事務作業者だと思うよ >>121
そうそう、そういう構造
全要素にアクセスするつもりなら、もちろん遅延評価をしたところで速くはならないし
むしろ遅延評価のオーバーヘッド(thunkの生成、評価、解放)のせいで逆に遅くなるよ
その一方で、たとえば Data.Sequence をスタックとして使う場合のことを考えてみるといい
普段は「スタックの先頭への push」と「スタックの先頭からの pop」しかしなくて
スタックを途中で分割したり全要素を列挙したりはあんまりしないようなケースだと
本来やるべきだった下層への押し出しや持ち上げを先延ばしにした結果として
木の深さの増減分が相殺されて結局やらずに済んでしまう、という場合が多く発生する
そうなると遅延評価はとても有利に働く >>127
まあ、実際事務作業というか大概のデータサイエンティストって立場的にはデータ取ってこられる企画職って
言う方があっているんだろうな。
ただ、モデリングメインでもアクティブユーザー数数百万とかのサービスのデータをいろんなテーブルなめて分析用にもってくる
場合割りと面倒くさいSQL処理の比重は大きくなりがちだと思う こういう簡単ぽくて実は奥が深い玄人好みの奴は深掘りしがいがあるけど
視野が狭くなる危険もある、と >>131
ないない
PoC進まねえもんそんなことやってたら
テーブルデータなら>>127の言う通り固めないし
画像もテキストもデータソースRDBじゃない場合が多いしな
>まあ、実際事務作業というか大概のデータサイエンティストって立場的にはデータ取ってこられる企画職って
>言う方があっているんだろうな。
ちょっとデータサイエンティストって言うのは苦しいかなその人たちは >>134
実際そんくらいでデータサイエンティストとラベリングするのは羊頭狗肉という感じするけど
大概のデータサイエンティスト職そんなもんだよ。 >>105
そうだね。職業としてIT業界で働いた前後で変わったのはRDBの知識は無茶苦茶有用ってこと。
既存のプログラムを書くとは発想が違うね。
並列言語ってSQLのようなフオンノイマン型とは違う感じになると思うんだ shell、COBOL、Java、ruby、scala、goと6社またいでやってきて途中でミドルウェア管理に切り替えたら外資入れたわ、
たしかにSQLは遥か昔dao使わずに生SQL発行してた頃の知識はまだ使えるね、ダッシュボードサクッと作ると喜ばれるし
ま、プログラマよりもミドルウェア管理とかSREとかクラウドアーキテクトのがいいよ >>105
SQLを書かなくてもいい場面はあるが
そういうライブラリはSQLの知識があること前提なので
そいう意味では必要 >>135
そんな低レベルでデータサイエンティスト名乗ってるの見たことないな >>139
まあ、web企業のデータサイエンティスト職とか大概そんな低レベルなもんよ。 いや大半の企業はSQLでデータとってきてTableauとかでダッシュボード作って眺めて満足して終わりだから >>130
やっぱりそういうケースでの話になるか…
ふわふわした質問に付き合ってもらってすまんね >>142
ぜんぜん構わない
好きな言語の話をするのは楽しい。俺ハッピー プログラムってまず、i am worldって書けばいいんだろ? まあ他は別に極めなくてもそれなりでもいけるからな
SQLは書き方一つで何十倍も差が出たりするから極めると強いのは確かだわ
同じ理由でプログラミング言語で極めるとすればアセンブラか >>147
アセンブラはセキュリティ業界しかもう要らない感じだね
あとはパチンコ。チューニングするよりハードに任せる世界 >>35
TiDBのようなNewSQLに取って代わった
https://licensecounter.jp/devops-hub/blog/tidb1/
>NewSQLとはRDBMSとNoSQLのメリットをいいとこどりさせた新しいデータベースです。NoSQLの柔軟な拡張性と分散型アーキテクチャに加え、 RDBMSの特徴であるACIDトランザクションを同時にサポートします。
RDBMSはスケールしない
NoSQLはスケールするけど制約が多い
NewSQLはすべての要求を満たす
日本だとPaypayのバックエンドがTiDB
https://pingcap.co.jp/customer-db-tech-showcase-2021-paypay/ まぁ色々マスターしても広告がビジネスモデルのweb2.0企業だと全然稼げないんだけどね
サブスク課金が出来るようなコンテンツを持ってるところや
ガチャ課金のスマホアプリを作ってるとか、そういうのがないと純利益3億円以下、時価評価額100億円以下の中小企業にしかなれない
web3.0時代に向けてSolidity勉強したほうがいいレベル excel vbaでADOを使うと、excelブックやシートに対してSQL使えるようになるで DB構造にもよるよね
内部結合だらけだと性能出ねえし
書き方次第で性能出たりするし、センスはいる ■ このスレッドは過去ログ倉庫に格納されています