MySQL :: MySQL 8.0 リファレンスマニュアル :: 9.4 ユーザー定義変数
あるステートメントのユーザー定義変数に値を格納し、後で別のステートメントで参照できます。 これにより、あるステートメントから別のステートメントに値を渡すことができます。 ユーザー変数は@var_name として記述され、変数名 var_name は英数字、.、_および $ で構成されます。 ユーザー変数名を文字列や識別子として引用符で囲めば、ほかの文字も含めることができます (@'my-var'、@"my-var"、@`my-var` など)。 ユーザー定義変数はセッション固有です。 あるクライアントで定義されたユーザー変数は、他のクライアントでは表示または使用できません。 (例外: パフォーマンススキーマ user_variables_by_thread テーブルへのアクセス権を持つユーザーは、すべてのセッションのすべてのユーザー変数を表示できます。) 所定のクライアントセッションのすべ
データベーステーブル設計の基礎の基礎〜エンティティの抽出・定義から正規化まで - エンジニアHub｜若手Webエンジニアのキャリアを考える！
データベーステーブル設計の基礎の基礎～エンティティの抽出・定義から正規化まで 適切な形でデータベースのテーブルを設計し、運用するには？テーブル設計に必要な初歩を日本MySQLユーザ会副代表の坂井恵さんが丁寧に解説します。 金融系アプリ、ゲーム、人工知能などなど……。どんな種類のシステムを開発する上でも、避けて通れない領域があります。データベースです。データを適切な形式で格納し、取り出す。単純明快ながらも奥深いこの仕組みは、多くのシステムの根幹を支えています。 しかし、適切な形でデータベースのテーブルを設計し、運用するのは簡単なことではありません。「良いテーブル設計」のためには知識と経験が不可欠です。今回は日本MySQLユーザ会の副代表である坂井恵さんに、これからテーブル設計に着手する方に向け、設計に必要な技術と、良い設計を作るための考え方を教えていただきました。 坂井恵（さかい・けい） @
変数に型のない言語におけるSQLインジェクション対策に対する考察(5): 数値項目に対するSQLインジェクション対策のまとめ - 徳丸浩の日記(2007-09-24)
_数値項目に対するSQLインジェクション対策のまとめ 一連の議論では、以下の条件におけるSQLインジェクション対策について議論している。 SQLインジェクション対策において、バインド機構が利用できない(したくない) 変数に型のない言語(Perl、PHP、Rubyなど)を使用している 数値型の列の場合 この場合の対策としては、以下の二種類が機能する。 SQL文組み立ての前に、数値としての妥当性検証を行う 数値項目もシングルクォートで囲み(クォートし)、文字列リテラルと同様のエスケープを行う 数値項目もクォートする方法 このうち、後者の積極的な推進者として大垣靖男氏がおられる。例えば、以下のような記事 すべての変数をエスケープする対策 この方法はすべてのデータベースに利用できる対策です。文字列，整数などデータ型に関わらず変数すべてを文字列としてエスケープすることにより，SQLインジェクションを
SQLの暗黙の型変換はワナがいっぱい
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2009年9月24日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、SQLにおいて「暗黙の型変換」を使うべきでない理由として、具体的な「ワナ」をいくつか紹介します。 数値項目に対するSQLインジェクション対策のまとめにて説明したように、RDBの数値型の列に対してSQLインジェクション対策をする方法として、以下の三種類が知られています。 バインド機構を用いる パラメータの数値としての妥当性確認を行う パラメータを文字列リテラルとしてエスケープする このうち、方法3を使うべきでない説明の補足です。具体的には、方法3には、「暗黙の型変換」が発生しますが、それが思わ
数値項目に対するSQLインジェクション対策 - ockeghem's blog
文字列項目に対するSQLインジェクション対策は、「'」(シングルクォート)や「\」(円マーク、バックスラッシュ)のエスケープであるが、数値リテラルなどはエスケープでは対策できない。 ここで、なぜ文字列に対してエスケープ処理が対策になるかを復習しておこう。それは「どんな文字(列)に対しても正しいSQL文を生成する」ためである。一方、数値の場合は、どんな数値であってもエスケープ処理などは元々必要ない。それにも関わらずSQLインジェクション脆弱性が混入するのは、数値を想定した変数に数値以外の文字が混入するからに他ならない。 すなわち、文字列の場合と数値の場合は、対策の前提が異なるわけである。 ここで、高木浩光氏からの批判に戻ると、関連する内容は以下のとおりである。 「対策は入力値の妥当性検証」 < それは違う。SQL文構成時直前に型変換（ないし型検査）する。文字列のクオート同様 以下、いくつかの
新人がテーブル設計でつまずいた話 | TECHSCORE BLOG | TECHSCORE BLOG
こんにちは、土屋です。 今回の記事では、私が初めてテーブル設計をしたときに、つまずいた話をまとめてみました。 テーブル設計の経験者の方には、「新人はこんなところでミスするんだ」と知っていただければいいなと思います。 【ミスその1】エンティティの属性の書き方が適切ではなかった 論理名を簡潔に書く 社員情報をまとめるエンティティに、社員のIDを属性として入れたいときがありました。 はじめは属性の論理名を、次のように「社員ID」にしていました。 ですが、「社員ID」ではなく、簡潔に「ID」とだけ書けばOKです(※)。 エンティティ「社員」の属性にIDがあると、それが「社員ID」であるのは自明だからです。 ※必ずしも当てはまるわけではありません。例えば、全てのテーブルで「社員ID」にしておくと、JOIN するときに迷いにくいので便利という意見もあります。 正しい表現か確認しながら物理名を書く 物理
パフォーマンスを求めて - お前の血は何色だ!! 4
結局、わかったことは、 次の4つ。 index から 実体へのシークは遅い。 すべてがindex内で完結するクエリーは早い。 limit をつけても where や order by すると意味がない。 indexを張るなら Using indexe をゲットできないと負けかな。 では、select で取得する値すべてに index を張りますか? 場合によっては可能ですが、テーブルに文字列なんかがふんだんに含まれていると難しいものがあり、現実的ではありません。 そこでこんな方法を提案します。2段階にわけてクエリーを打ちます。 A. task テーブルの 2008/6/5 〜 2008/6/18 のデータを開始日順にならべて、先頭5件だけ表示せよ。 select SQL_CALC_FOUND_ROWS * from task where task.task_starttime <= '20
Oracle勉強環境を構築するため、無償でOracle Database Enterprise Edition 12cを手に入れる（ダウンロード編） - RECLOG
Oracleの確認環境が欲しかったのでインストールした。 今回はダウンロードまで。 はじめに 目的 無償版のExpress Editionでは無い理由 Oracle18c XEでは制限が緩和されました OracleDBを無償で使うための条件 OracleEEを選択した理由 12cを選択した理由 Databaseのダウンロード Clientのダウンロード 次回は はじめに 自宅でOracleの動作が確認できないと不便に感じたので色々調べてみた。 インストールまで入れるとちょっと長いので、今回はダウンロードまでの流れをメモ。 ちなみにサーバー機にDatabase、クライアント機にClientを入れようと思う。 目的 Oracle Database Enterprrise Edition(以後EE) 12cをダウンロードする。 無償版のExpress Editionでは無い理由 Oracleには
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OracleとSQL Server、チューニングの違いを知る
InfoQ: データの削除は非推奨