タグ

sqlに関するd_animal141のブックマーク (110)

  • NULL撲滅委員会

    序文 全国1千万の DB エンジニアの皆様、こんにちは。NULL撲滅委員会極東支部長のミックです。皆様におかれましては日々、DB の構築、SQL 作成、パフォーマンス・チューニング、番データの入ったテーブルをいともあっさり DROP した新入社員の尻拭いと、獅子奮迅の働きにてチームを支えておられるであろうと存じます。さて、日私が一筆啓上しましたのは、NULL撲滅基宣言への皆様の参加を募りたく思ったからです。 NULL というこの面妖な怪物の質の悪いところは、最初は私たちの感覚に心地よく合致すると感じられるため、ごく自然にするっとシステム設計の中に忍び込んできて、気が付いたときにはシステムをどうしようもなく複雑で、非効率的で、直観に反する動作をするに至らしめ、開発も運用も困難なものにしてしまうところにあります。ゆえに、NULL のもたらす脅威から身を守るには、まず第一にその正体をよく知

  • Gormにおける「仕様通り」なSQLインジェクションの恐れのある実装についての注意喚起 - ANDPAD Tech Blog

    ANDPADボードチームの原田(tomtwinkle)です。 Node.jsの mysqljs/mysql の仕様に起因するSQLインジェクションが話題に上がっていたので、それGolangORMであるGormでも同じような「仕様」があるよ! という注意喚起の意味も込めて筆を執りました。 ※ 2022/02/21追記 コードレビューを自動化して指摘してもらう記事を公開しました! tech.andpad.co.jp Node.jsのMySQLパッケージにおけるエスケープ処理だけでは防げない「隠れた」SQLインジェクション | 株式会社Flatt Security TL;DR GormのQuery Conditions関数に関する危険な仕様 対策 締め TL;DR GormのConditions関数(Find, First, Delete...)を使用する際、第2引数の値にStringを引き渡

    Gormにおける「仕様通り」なSQLインジェクションの恐れのある実装についての注意喚起 - ANDPAD Tech Blog
  • オレ的EXPLAIN技を語っちゃうゾ - Qiita

    メリークリスマス 記事はPostgreSQL Advent Calendar 2021の25日目です。今年も面白い記事がたくさん揃いましたね!!! さて、みなさん今年のPostgreSQLライフはどんな感じでしたでしょうか? 私はというと、なんだかチューニングばっかりやってました。1案件でいろいろお手伝いすることはまあまああったのですが、複数から次々チューニングの相談をもらって、歴代継承者の個性を発現したデクくんのごとく駆け回ったのが今年のハイライトです。 (この綱渡り感、、、伝われ!!!) 俺たちは雰囲気でチューニングしている 今回上手くいったけど、あの時たまたまひらめいた1案をぶつけてみたら効果でたのであって、次善の策なんてなかったけど??って毎回思ってるから、雰囲気でやっていると思う、マジで。コミュニティのノリだと笑いが起きていいんですけど、少しでも勝率を上げるために、若手の前でド

    オレ的EXPLAIN技を語っちゃうゾ - Qiita
  • SQLファイルから型安全なコードを生成するsqlc | フューチャー技術ブログ

    TIGの辻です。GoのORマッパー連載8日目です。記事では sqlc を紹介します。早速ですが、結論から行きましょう。 sqlc まとめ SQLファイルからデータベースにアクセスできる型安全なGoのコードを生成するライブラリ 構造体のモデルの手書き実装不要 複数テーブルをJOINしたときのマッパー実装不要 生成されるコードは不要なリフレクションなし SQLをがんがん書きたい、でも面倒なマッパー構造体は書きたくない、という開発者にとっては大きな味方になります。 sqlc の紹介 sqlc はSQLファイルからGoのアプリケーションコードを生成するライブラリです。2020/2に v1.0.0 をリリースし、着々とスターを伸ばしています。2021/08現在は v1.8.0 をリリースしています。資料で生成しているコードも v1.8.0 を用いています。 https://star-histor

    SQLファイルから型安全なコードを生成するsqlc | フューチャー技術ブログ
  • Go の sql.DB がコネクションプールを管理する仕組み

    Godatabase/sql パッケージ の DB 構造体 は、データベースへのコネクションプールを管理し、かつスレッドセーフ (goroutine セーフと言ったほうが良いのだろうか…?) にそれらの接続を使用できることを保証している。 ドキュメント にも次のように書かれている。 DB is a database handle representing a pool of zero or more underlying connections. It’s safe for concurrent use by multiple goroutines. こちらの基的な実装内容と、動作を制御するパラメータについて調べてみた。 基礎知識のおさらい database/sql パッケージはデータストアの実装によらない一般的な SQL のインタフェースを提供している。具体的なデータストアへの接

    Go の sql.DB がコネクションプールを管理する仕組み
  • 開発者が知っておきたいSQLの実行モデル~アプリからデータベースへのアクセスを高速化するには?

    データベースのデータ・モデルは解決したい問題に合わせて使い分けることができ、昨今ではドキュメントやグラフなどのリレーショナル以外のモデルも注目されています。また、トランザクション系が生成した大量のデータをリアルタイムで分析するというような、性質の異なるワークロードを扱うことも求められています。これら性質の異なるデータ・モデルやワークロードを扱うにはどのような実装が必要でしょうか。この連載では、開発者の皆様がシステム・アーキテクチャやアプリケーション・コードをより洗練させるのに役立つデータベース・マネジメント・システム(DBMS)の基を振り返り、実装に合った技術の組み合わせを解説します。 第1回はデータベースにアクセスするAPIで最も広く使われているSQLという言語の実行モデルを再確認します。なぜこの言語がリレーショナル・モデルのみならず他のデータ・モデルに対しての操作にも使われるようにな

    開発者が知っておきたいSQLの実行モデル~アプリからデータベースへのアクセスを高速化するには?
  • 楽々ERDレッスンを読んだ - patorashのブログ

    TLで良書だというのをチラホラと見かけていたのだけれど、結構古いなので迷っていたのだが、今でも通用しそうな内容っぽいので買って読んでみた。 TLで見かけてた、楽々ERDレッスンを手にいれたので読んでいく。 pic.twitter.com/f7WEl6mHft— パトラッシュ@エキスパート職 (@patorash) 2021年2月1日 感想から書くと、これもまた「UNIXという考え方」と同じで、もっと若いうちに読みたいだった…😇 このの内容を知っていれば、データベース設計で悩むことも相当減っていたと思うし、プログラムで苦しむことも減っていたと思う。つまり、このは「買い」です。かなりお薦めできる。もう読んでいる途中から社内のTeamsでは良書だと言いまくった。めちゃめちゃプッシュしたからか、後輩の何人かも買ってくれたみたいだった😋 ちなみに「UNIXという考え方」の感想はこちら。

    楽々ERDレッスンを読んだ - patorashのブログ
  • 第29回 LOAD DATA INFILE構文でテキストファイルからMySQLにデータをロードする | gihyo.jp

    初期データを投入する際に、mysqldumpで出力した際に作られるようなSQLの形式になっている場合は、mysqlクライアントで実行することでロードすることができました。しかし、外部で用意されているデータはTSVやCSVといったデータで渡されることもあります。TSVやCSVの形式からSQLへ変換を行っても良いのですが、わざわざ変換するのも大変です。そこで今回は、LOAD DATA INFILE構文を用いてTSVやCSVといったテキストファイルからMySQLにデータをロードする方法を紹介したいと思います。 検証環境 今回は第23回 mysqlslapを使って負荷テストをしてみようで使用したCentOS7で実行しています。MySQLのバージョンは5.7.13を使用しています。 LOAD DATA INFILE構文 LOAD DATA INFILE構文とは、テキストファイルで用意されたデータをM

    第29回 LOAD DATA INFILE構文でテキストファイルからMySQLにデータをロードする | gihyo.jp
  • SQLアンチパターンを読んで (ポリモーフィック関連について)

    様々なところで名著と言われている”SQLアンチパターン”を最近読みました。このにはデータベース設計やクエリなどでやりがちな様々な間違い(アンチパターン)が載っています。今回は私も身に覚えがあるアンチパターン:ポリモーフィック関連について紹介したいと思います。 SQLアンチパターン ポリモーフィック関連 ポリモーフィック関連とはある一つのカラムが複数のテーブルを参照しているようなパターンです。 例えば管理ユーザテーブル(admin_users)と一般ユーザテーブル(users)によってユーザを管理している時に、それらのユーザのログをユーザログテーブル(user_logs)でまとめて記録したい場合にポリモーフィック関連を使う可能性が出てきます。 図にあるようにuser_logsテーブルはadmin_usersとusersテーブルをusers_idによって参照しており、どちらに参照するかはus

    SQLアンチパターンを読んで (ポリモーフィック関連について)
  • Using filesort

    去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう?と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル(テンポラリテーブルではない)が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事

    Using filesort
  • TypeScriptで世界一型安全な型レベルSQL Interpreterを作っている話

    こんにちは。DevOps芸人と化して久しいAndyです。 2020年の秋にTypeScript 4.1へTemplate Literal Typesが導入され、そのインパクトに俄かに一部の界隈がザワついたのは記憶に新しいかと思います。 今回は型プログラミングの可能性を大いに押し広げたTemplate Literal Typesを用いてSQL文を型レベルで解析し、その実行結果を型情報として導出するためのsqlptureというライブラリを作ったので紹介します。 Embedded content: https://github.com/andoshin11/sqlpture SQLの実行/検証対象はPostgreSQL v13です。 tl;dr SQL文を型レベルで解析・評価して返り値型を取得できるmini interpreterを作ったよ 型レベルのSQL validatorも作ってるよ 実際

    TypeScriptで世界一型安全な型レベルSQL Interpreterを作っている話
  • SQL と NoSQL:5つの決定的な違い

    最新のデータベースを選択する際に、最も大きな決断のひとつとなるのは、リレーショナル(SQL)か非リレーショナル(NoSQL)かのデータ構造の選択です。どちらのシステムにも独自の利点があり、異なるニーズに対応しているため、最適なデータ管理を行うためには、どちらを選択するかが非常に重要になります。 SQL(Structured Query Language)は、事前に定められたスキーマをモデル化するリレーショナル データベースで行やテーブルなどの構造化データを管理できるようにする、従来のアプローチを採用したプログラミング言語です。対する NoSQL(Not Only SQL)は、より柔軟で非リレーショナルなアプローチを提供し、非構造化データや動的データを扱うのに理想的です。ビジネスが進化し、データがますます多様化する中、SQL と NoSQL の決定的な違いを理解するのは重要です。 そこで

    SQL と NoSQL:5つの決定的な違い
  • ぐるぐるSQLは止めてくださいという話 - Qiita

    1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが(決してメインの仕事ではないですが)、その中でよく出くわす問題の1つに「ぐるぐるSQL」(もしくは「ぐるぐる系」)といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%:ぐるぐる SQL 20%:SQL 文の書き方が不適切 15%:索引がない or 不適切 15%:パーズが遅い 10%:データモデルがおかしい 10%:その他 (大昔は2番目 / 3番目がほとんどだったのですが、最近はなぜがぐるぐる SQL が多い…) ぐるぐる SQL の実装では、ネットワーク通信や、アプリ側のクエリ生成 / 結果データ構築、DB 側のクエリ受信 / 結果送信といった、処理の質的で

    ぐるぐるSQLは止めてくださいという話 - Qiita
  • TextQL - CVSファイルに対してSQLを実行できるコマンドラインツール | ソフトアンテナ

    CSVファイルやTSVファイルはさまざまなデータを格納できるデータベース的な構造を持つテキストファイルですが、データベースで使用できる便利なSQL言語は使用することができません。 表計算ソフトに取り込んでデータを活用することはできるものの、SQLに慣れ親しんだ方ならば、SQLを使って直接作業したいと思った経験のある方も多いでしょう。 日紹介する「TextQL」はこのアイデアに基づいて開発されたコマンドラインツールです。サンフランスのソフトエンジニアPaul Bergeron氏によって作成されたGo言語製のオープンソースソフトとなっています。 SQLiteCSVファイルを取り込んでも同じような作業が可能ですが、次に示すような違いがあるとのことです。 sqliteインポートは標準入力を受け取らずUNIXパイプを破壊する textqlはクオートでエスケープされたデリミタをサポートする tex

    TextQL - CVSファイルに対してSQLを実行できるコマンドラインツール | ソフトアンテナ
  • GraphQL と N+1 SQL 問題と dataloader - Qiita

    この記事ではハイパフォーマンスな GraphQL サーバを実装するのに避けて通れない N+1 SQL 問題について解説します。 TL;DR GraphQL は resolver を個別にかつ再帰的に実行していくため、 RDB のリレーションを効率的に先読みすることができません。そのため一般的に遅延読み込みを行います。 Facebook 社は GraphQL で遅延読み込みするために dataloader という npm パッケージを公開しており、各種言語にその移植版のライブラリが存在しているので、それを使って N+1 SQL 問題を抑制しましょう。 (復習)N+1 SQL 問題とは N+1 問題は「1 つの SQL で N 件のレコードをフェッチしたあと、それぞれ対して関連するレコードを個別にフェッチするのに N つの SQL を発行している」状態を指す言葉です。言葉で書いてもよく分からな

    GraphQL と N+1 SQL 問題と dataloader - Qiita
  • 「SQLアンチパターン」を避けるためのチェックリスト①(DB論理設計編) - log4ketancho

    ずっと前から積ん読状態だった「SQLアンチパターン」を読みました。 何年積んでたか分からないSQLアンチパターン読み終わったー。噂に違わずいいですねー。もっと早く読むべきだった。— @ketancho (@ketancho) 2018年3月6日 噂通りとても良いで、まさに「エンジニアとしての血肉」と言えます。1, 2年目の頃に読んでおくべきだったなーと少し後悔しています。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る 読んで終わりだと身につかないと思うので、自分なりのチェックポイントを言語化しておこうと思います。長くなってしまったので、章ごとに4つに分けたいと思います。この記事はその第一弾と

    「SQLアンチパターン」を避けるためのチェックリスト①(DB論理設計編) - log4ketancho
  • 「INDEXによる高速化」は本当なのか!?PostgreSQLでパフォーマンスチューニングしてみた - Developer’s Blog

    かなり長いので不要部分は省略します。 Sort (cost=478905.76..478905.77 rows=1 width=215) (actual time=1213518.262..1213518.264 rows=22 loops=1) Sort Key: z.mdd Sort Method: quicksort Memory: 31kB -> Subquery Scan on z (cost=478905.73..478905.75 rows=1 width=215) (actual time=1213518.163..1213518.245 rows=22 loops=1) Filter: (z.joutai = 1) -> Unique (cost=478905.73..478905.74 rows=1 width=215) (actual time=1213518.158

    「INDEXによる高速化」は本当なのか!?PostgreSQLでパフォーマンスチューニングしてみた - Developer’s Blog
  • 【SQL】相関サブクエリ入門 - Qiita

    相関サブクエリとはサブクエリの一種であり、外側のクエリの値をサブクエリ内で使用する。 相関サブクエリを使用したSQLはややこしくて読みにくい場合が多いが、基形を1つおさえておくとだいぶ理解しやすくなる。 サブクエリが何かわからない場合は、こちらを先に読んで欲しい。 http://qiita.com/mokrai/items/6df0513ccc5aa40a075a 動作確認環境とテーブル PostgreSQL 9.4でクエリの動作を確認した。 また、使用したテーブルの定義は下記。 CREATE TABLE Employees ( id INTEGER PRIMARY KEY, name VARCHAR(10) NOT NULL, age INTEGER NOT NULL, department VARCHAR(10) NOT NULL ); INSERT INTO Employees V

    【SQL】相関サブクエリ入門 - Qiita
  • postgresql NOT ILIKE clause does not include null string values

    Here's the setup on Postgresql 9.2.4: CREATE TABLE table ( id integer NOT NULL, some_text text ); Now we enter one record, with a null or empty string for some_text, so that when we query: SELECT * FROM table WHERE some_text IS NULL; I get the entry back. So far so good. However, when I query: SELECT * FROM table WHERE some_text NOT ILIKE "%anything%'; I find that nothing was returned. Why is that

    postgresql NOT ILIKE clause does not include null string values
  • SQLでサブクエリを上手に使う6パターン

    はじめまして。Souki.Tです。 SQLを書く上で、使いどころが難しいのがサブクエリです。何でもかんでもJOINして運用するのは格好わるい、サブクエリを使ったら何かカッコいい、結局サブクエリを使いすぎて訳の分からなくなり、作った自分でも手が出せなくなった経験は私だけではないはずです。今回はサブクエリを使う場面をパターンに分けて上手なつき合い方を考えてみたいと思います。 サブクエリとは何かということを説明するのは私には手に余るので誰か説明の上手な人に任せます。どこかにいい解説があったら教えてください。 サブクエリを使わない理由サブクエリの特徴を一言でいうと「重い」。ともかく重い。使い方を間違えたら劇的に重くなることはもちろんのこと、適切に使ったとしても重いものは重いです。普通にJOINで結合して解決するのであれば、使うべきではありません。 それでもサブクエリを使うパターンとはいえ、サブクエ