http://www.contrib.andrew.cmu.edu/~shadow/sql/sql2bnf.aug92.txt
This file contains a depth-first tree traversal of the BNF for the language done at about 27-AUG-1992 11:03:41.64. The specific version of the BNF included here is: ANSI-only, SQL2-only. ::= | ::= | | ::= | ::= A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z ::= a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t |
SQLの整形ツール - プログラマー'sペイジ
SQLのチューニングをする場合，そのSQLはプログラムの実行ログから採取する場合が多い． その場合，チューニングするためには，まずSQLを見やすく整形しないと始まらないのだが， この作業は結構疲れてしまうし，往々にしてチューニング対象のSQLは長いので困る． 楽をするためにフリーの整形ツールをいくつか試してみたが，どうも気に入らない．まぁ好みの問題が大きいんでしょうけど．．． それで仕方がないので，自分で整形ツールを作ることにした． 本格的にやると大変なので，少々使えるレベルものを，Perlでちょろっと書いてみた． なお，整形結果の例は，SQLの整形ツール〜整形結果の例にあります． また，ブラウザから整形を実行できるようにしたものが，SQL整形のデモ(Ajax版)にあります． #!/usr/bin/perl use strict; my $in = ''; while (<STDIN>)
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
コメントを頂いたので - SQLer 生島勘富 のブログ
数値を文字型で持つべきではない コメントをいただいたので。 前の記事はこちら。 http://d.hatena.ne.jp/Sikushima/20110809/1312871002 元ネタはこちら。 http://d.hatena.ne.jp/iad_otomamay/20110808/1312805917 http://d.hatena.ne.jp/iad_otomamay/20100906/1283786846 システムはそれぞれ要件が全く違う。だから、何事も一概には言えない。 しかし、はっきり言えるのは数値を文字で置き換えて保存するのは、普遍的な超バッドノウハウでしょう。これはどう考えてもあり得ん。 インサートされた時点の数値エリアの入力率が50％でそれが最終的に90％になる伸長率が高いデータだったとしても、 PCTFREE ＝ 100％ × 数値エリア割合 × 50％ としておい
JOIN禁止と固定長カラムについて - SQLer 生島勘富 のブログ
あまりに気になったので「山本大＠クロノスの日記」にチャチャを入れてみる。 http://d.hatena.ne.jp/iad_otomamay/20110808/1312805917 http://d.hatena.ne.jp/iad_otomamay/20100906/1283786846 まあ、政治的にはどのみち勝てなかったでしょう。私も同じ条件であれば、一応は説得を試みるけれど返り討ちに遭うと思う。いずれにしても結果は同じですが、教えられたと思っているなら間違いです。 結論はいつものとおり「下手糞が居るから」に行き着くのですが……。 JOIN禁止について 「JOIN禁止」が正しい場合がある。 それはJOINされるデータがアプリケーションサーバにキャッシュされていて、その一貫性が何らかの形で保証されている場合。 そもそも、せっかくキャッシュしているのに、それを使わずにJOINして取り直
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
テスト自動化とは - ソフトウェアテスト自動化まとめサイト なんでも自動化サイト
1.V字開発プロセスモデルによる分類 1.1.要件定義 VDM 形式手法(Formal Methods)により仕様の自動検証などを行う。 1.2.システム設計 モデル検査 Spin モデル検査により状態遷移図の状態で自動検証を行う。 LTSA モデル検査により状態遷移図の状態で自動検証を行う。 NuSMV モデル検査により状態遷移図の状態で自動検証を行う。 モデル駆動 ZIPC(商用:キャッツ株式会社) 状態遷移図による検証が可能 MDA モデルを実際に動かして動作検証する。Executable Umlなどを使用して仕様を記述。 IAR visualSTATE(商用:IAR SYSTEMS) ステートマシンを設計、検証、実装できるツール。20ステートまでの無料の評価版あり 1.3.詳細設計 Enterprise Architect(商用:SPARX SYSTEMS) テストツールではないが
SQLキーワード(予約語)
お間違いでは？ これは大変古いバージョンのマニュアルです。 より新しいバージョンのもの → [7.4マニュアル] [8.0マニュアル] [8.1マニュアル] Appendix B. SQLキーワード(予約語) Table B-1には、標準SQLと PostgreSQL 7.1.3にあるキーワードのすべてのトークンの表があります。 バックグラウンド情報はSection 1.1.1を 参照して下さい。 SQLは予約と非予約 キーワードを区別します。予約語のみが真のキーワードで、識別子として 使用することはできません。非予約語はある特定の環境で特別な意味を 持ち、その他の環境では識別子として使用することができます。 ほとんどの非予約語は、SQLで規定された組み込みのテーブル名と関数名 で、非予約語の本質的な存在意義は、ある状況においては前もって 定義された意味があることを宣言することにあります。
PDOとMYSQLの組み合わせでLIMITを使う場合の注意点 » とりあえず9JP
注意点というほどでも無いかもしれないけど、一度ハマった事があるので・・・。 $sql = "SELECT * FROM example_tbl WHERE name=? age=?"; $sth = $dbh->prepare($sql); $sth-> execute(array('あいうえお' , 18)); という感じで配列で渡すと非常に手軽だけれど・・・ $sql = "SELECT * FROM example_tbl WHERE name=? age=? LIMIT ?,?"; $sth = $dbh->prepare($sql); $sth-> execute(array('あいうえお' , 18, 0, 30)); といった感じでLIMITの値を渡すとエラーが出る。 配列で渡す場合、全て文字列として渡すらしく、LIMITに文字列を渡してしまった事が原因らしい。 なので、LI
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL
SQLite で auto-increment なフィールドを作成する方法
SQLite で auto-increment なフィールドを作成する方法 2006-02-12-1: [SQLite][PHP][MySQL] PHP のマニュアルの sqlite_last_insert_rowid の項目を見ていたら Tip: You can create auto-increment fields in SQLite by declaring them as INTEGER PRIMARY KEY in your table schema. つまり，SQLite で auto-increment なフィールドを作りたければ， INTEGER PRIMARY KEY を指定してあげればいいらしい． このような記述を見つけたのでテストしてみた． - SQLite 2.x の場合 $ sqlite test.db SQLite version 2.8.16 Enter "
ORACLE／フォーマット形式編 - オラクルちょこっとリファレンス
日付型や数値型は、表示させたい形式（フォーマット）を変えたい場合がありますが、そうした場合に同じデータを使って表示形式だけを変えて表示させることができます。 日付フォーマット 日付フォーマット記号の一覧です。 フォーマット説明
Oracle Tips
Oracle Tips テーブル内のレコードの全削除truncate table テーブル名 DELETE文と異なりトランザクションの対象とならないため大量のレコードも一瞬で削除され、ロールバックセグメントの空き容量を気にする必要もありません。（とーぜん、コミットやロールバックはできません） スキーマに存在しているテーブル名の取得select * from user_tables select * from tab （こっちはビューも取得可能） スキーマ内のオブジェクト名の取得select * from all_objects where owner = 'ユーザ名' order by owner, object_type, object_name ユーザ名は大文字。 USER_OBJECTS でも可。 （こっちはスキーマ内のオブジェクトが対象） テーブル構造の取得describe テーブ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OTN Japan - スキルアップ講座 : Oracle9i 物理設計
mysqlで質問です。 例えばselect文でlimitをかけた場合、limitをかけない場合の検索該当個数を得る方法などがあったら教えてください。…
サービス終了のお知らせ
https://net-newbie.com/sqlite/lang.html
オラクルのエラーメモ(Hishidama's Error for Oracle Memo)
オラクル特殊SQLメモ(Hishidama's Oracle SQL Memo)