サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
これらのメソッドを使用することで、データフレームの列に対して.when()で定義した条件に従ってデータの操作を行えます。たとえば以下のサンプルスクリプトでは、楽器名と演奏者数のデータフレームに対して条件により「Group」列を追加しています。 example03.py：.when()で指定された条件で新たな列を追加するサンプル importpolars as pl # サンプルデータフレームを楽器名と演奏者数で作成 df = pl.DataFrame( { "Instruments": ["Violin", "Trombone", "Flute", "Cello", "Trumpet"], "Players": [5, 1, 3, 2, 1], } ) # 新しい列 'Group' を条件に基づいて作成 df = df.with_columns( pl.when(pl.col("Play
こんにちは、Platform Team の荒引 (@a_bicky) です。前回は続・何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜という話を書いたんですが、今回は Repro の運用に 7 年以上携わる中で私が遭遇して印象的だったAuroraMySQL 絡みのトラブルについて紹介します。AuroraMySQL が詰まってデータ処理のスループットが下がるとか、API のレスポンスが遅くなるとか、ALTER TABLE する度にアプリケーションエラーが発生するとか、胃が痛くなる胸が熱くなる話が多いので、AuroraMySQL を利用していなくても楽しんでいただけるのではないかと思います。AuroraMySQL を利用している方であれば参考になる情報もあるでしょうし、通常のMySQL にも適用可能な話もあります
「えっ、SQLite3ってこんな仕様なの！？」と最近ビックリしたことを紹介します。 たとえばこんな2つのテーブルがあったとします。CREATE TABLEblogs ( id int primary key, title varchar(32) );CREATE TABLE comments ( id int primary key, content varchar(32),blog_id int, foreign key (blog_id) referencesblogs(id) ); ポイントはcommentsテーブルのblog_idにはblogs(id)への外部キー制約が貼ってあることです。 もちろん、blog_idもblogs(id)も、どちらもint型です。 で、以下のようなSQLを発行します（blog_idの値に注目）。 --blogsにデータを追加 INSERT
SQLiteの公式Webサイトに、SQLite3をWebAssembly化した「SQLite3WASM/JS」プロジェクトのページが公開されました。 これまでさまざまなWebAssembly版SQLiteの試みが行われてきたなかで、初めてSQLiteの正式なサブプロジェクトとして開発されるWebAssembly版SQLiteになります。 下記はドキュメント「About thesqlite3WASM/JS Subproject」からの引用です。 this subproject is the first effort "officially" associated with theSQLite project,created with thegoal of makingWASMbuilds of the library first-class members of the fa
こんにちは、Development Teamの三宅です。 先日、社内（AI事業本部内）でSQL研修の講師を担当したので、今回はその内容について簡単に共有したいと思います。 はじめに 例年、AI事業本部では、新卒エンジニアの育成のためにソフトウェアエンジニア研修を行っております。今年はフルリモートでの実施となりました。研修期間は2週間ほどで、内容は前半が講義、後半が実践（チーム開発）でした。私が担当したのは、講義パートの一部であるSQL研修です。SQLやRDBにあまり慣れていない人でも、できるだけ体系的な学びが得られるようにすることを目標に、様々な資料をまとめて提供する方針で準備しました。結果的には、ハンズオン込みで4時間ほどのやや長い講義となりましたが、勉強になったという声も頂けたのでやって良かったと思っています。研修資料 研修内容SQL研修の内容は、基本的には大学のデータベース講義で
MySQL互換のパーサーが多い印象ですね。どのSQLパーサーを利用するのが最も適切なのか3日ほど悩みましたが、おそらく1ヶ月悩んでも結論はでないと途中で気が付き、ザラッと中身を見た感じシンプルな作りのxwb1989/sqlparserをチョイスしました。 xwb1989/sqlparserで適当なSELECT文をパースするとAST(Abstract Syntax Tree)が構造体として返却されてきました。ASTとは聞いたことがありますが何なのかは全くわかりません。怖いですね。 ASTが何なのかはわかりませんが、ひとまず中身を解析してみるとSELECT文を読み取ったらSELECT文を表現した構造体に情報を格納しているということはわかりました。構造体を更にたどってみるとこのSELECT文どのテーブルを参照しているのか、JOINしているテーブルは何かなんてこともわかります。これなら補完候補が出
こんにちは、データ分析部の石塚です。 Gunosyではエンジニア以外の職種でもSQLを叩いて自らデータを集計・分析するという習慣と全社員が各サービスのログ*1に触ることができる環境があります。 例えば、ユーザー獲得を担っているプロモーションチームはエンジニアが0名のチームなのですが、実際にSQLを叩いています。 それによって、自分たちの獲得したユーザーはどのような行動をしているのかを確認したり、分析することができています。 これはGunosyのみの事例ではなく、AWSのRedshiftやAthena、GCPのBigQueryが台頭してきたおかげで、どの会社も低コストにログをSQLで集計・分析できる基盤が整ってきています。 個人的にはアプリやウェブの業界で働くマーケターにはSQLは必須の知識と言える時代になってきたと感じています。 そこで今回は特別プログラミングなどの経験が無い人でも、SQL
去年書いたSoftwareDesignを題材にお話してください！って言われたので話してきました。 下の特集記事は１年経った今も現役で読める内容なので興味がある人はぜひ読んでみてください。 またRDBアンチパターンという連載をしていますのでこちらもあわせてご確認くださいっ！ gihyo.jp そして当日の資料はこちらです。 SoftwareDesignにしっかりとMySQLとPostgreSQLの違いについては触れているのでそこでは触れていない、ハマりどころや初めて両方のDBを知ったと言う人向けのカジュアルは部分を攻めました。 またDBだけの勉強会ですので普段説明するようなところは省略し、できるだけ経験談やコアの話に注力したつもりです。 このへんは資料に含まれて居ないので当日居た人たちだけの特典ですね！！ ということで実は今月は登壇3週連続だったのですが一段落しました。 来週はAWS Sum
SELECT * WHERE a=b FROM c ？ それとも SELECT WHERE a=b FROM c ON * ？ もしあなたが私のようなプログラマだったら、SQLは、初めは優しく見える言語の1 つかもしれません（ただ単に普通の英語通り読めばいいですから）。ですが、何かしらの理由で、なんてことのないクエリにもいちいち正しいシンタックスをググらなければいけないでしょう。 いずれJOINにAGGREGTATION、サブクエリにたどり着くでしょうが、読んだとしてもさっぱりでしょう。例えば次のような感じです。 SELECT members.firstname || ' ' || members.lastname AS "Full Name" FROM borrowingsJOIN members ON members.memberid=borrowings.memberidJOIN
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? マーケティング担当者にSQLを完全マスターさせた話 普段開発とかしない人達にもデータベースに簡単に触れられるようにしたお話です． 安全なデータベースを作る本番サービスのデータベースと同等，だけど個人情報的なものは隠しておきたい，よく聞く話ですね． これについては様々なアプローチがあるようですが，できる限り安定させたい＆バッチでやるにしてもサーバの面倒を見たくない，とう方針のもと，RDSのスナップショットを利用して作成することにしました． 処理の流れ RDSが1日1回スナップショットを取っている(これはRDSの機能) RDSのスナップシ
思いのほか前回のRailsプチ・デザインパターンの紹介に反応があったので、こういう小ネタも出していったほうがいいのかな、ということで第二弾。 ソーシャル系アプリだと、ユーザとユーザを関連付ける多対多のモデルがたくさんでてきます。たとえば、一般的なところではフォローとかブロックとか足あととか。さらにデーティングサイトになると、ウィンクだったり、Secret admirer（こっそりlikeするけど両思いだったらおめでとうって通知がくるってやつ）だったり、いろいろなモデルがこのパターンにあてはまります。 この場合、「AがBをフォローしている」「BがAをフォローしている」「AとBがお互いにフォローしている」という3つの状態があるわけですが、相互フォローの状態は「AがBをフォローし、かつBがAをフォローしている」と読み替えてSQLでも記述可能なので、以下ではシンプルに単方向のグラフで全てを扱うもの
第四企画 坂井 潔SQLインジェクションの脅威からシステムを守るために、プログラミング言語／スクリプトからSQLを発行するときには、パラメータを適切に処理しなくてはなりません。今回はプレースホルダ編と題し、SQLインジェクション対策として最も簡単で効果的な方法を、PHPで説明します。SQLインジェクションとは？ まず「SQLインジェクション」とは何かおさらいしましょう。SQLインジェクションとは、アプリケーション（この場合はPHPスクリプト）に渡すパラメータの値を操作することで、元々は意図されていない処理をSQLとして実行させてしまうことです。 簡単な例をあげてみます。ユーザーから文字列「山田」が渡されたとき、以下のようなSELECT文を発行することにします。 SELECT * FROM users WHERE username LIKE '%山田太郎%'; ユーザーに入力された文字列
社内で、SQLインジェクションについてあらためて原理・原則から議論したいねという風潮がにわかに起こったので、ひとまずは叩き台として僕の方でまとめて皆で議論しましょうというわけで、以下のような資料を作成した。 社内勉強会用の資料なのだけど、僕は別にセキュリティに詳しいわけでもないし、ましてやPHPのことは素人なので、外部の識者にレビューしていただいて、できるだけ正しい知識に基づいて議論できればと思い、まずスライドを先行公開することにした。そうしたところ、Twitter上で多数の識者よりいろいろとご指摘いただいて、少くとも決定的におかしな内容にはなっていないものになったようだ。ありがとうございます。 僕らの職務のひとつに「セキュリティ関連」というものも謳われているので、そのあたりの知識普及・基盤整備についても、仕事のひとつとして行っている。先にも書いた通り、僕自身がその点についてよく理解できて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
