[B! sql] unaristのブックマーク

q - Text as Data

q - Run SQL directly on CSV or TSV files¶ Overview¶ q's purpose is to bring SQL expressive power to the Linux command line by providing easy access to text as actual data, and allowing direct access to multi-file sqlite3 databases. q <flags> <sql-query> q allows the following: Performing SQL-like statements directly on tabular text data, auto-caching the data in order to accelerate additional quer

unarist 2016/08/11

sql
shell

リンク

今どきのSQLインジェクションの話題総まとめ - PHPカンファレンス2015発表資料

オフラインWebアプリの再到来で今、再び注目されるAPIの本命　ーJavaScript SQL-like databaseyoshikawa_t

unarist 2015/10/05

リンク

PostgreSQLウィンドウ関数のTips | POSTD

大変そうに見えるが簡単ウィンドウ関数を使用するためには、OVER()句で”ウィンドウ関数の構文”を用いる必要があります。サンプルテーブルを作成し、それを使って全てのウィンドウ関数に対する例を挙げてみましょう。この例では、14名の学生が居るクラスを管理しています。 -- Creating the table CREATE TEMP TABLE students ( id serial, name text, grade int DEFAULT NULL, last_seen_in_class date ); -- Adding some students INSERT INTO students (name, grade, last_seen_in_class) VALUES ('Jacob', '9', '2014-08-16'), ('Michael', '6', '2014-08-

unarist 2015/07/17

リンク

ドメインロジックとSQL

以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ

unarist 2015/04/08

トランザクションスクリプトとか複雑なSQLとか

sql
設計

リンク

SQLのlike演算子でエスケープが必要な文字 - teracc’s blog

まとめると以下のようになると思います。 Oracle % _ ％(全角）＿(全角) DB2 % _ ％(全角）＿(全角) MS SQL Server % _ [ MySQL % _ PostgreSQL % _ 注意点は以下のとおり。 DB2、Oracleは、「％」「＿」（全角）もワイルドカードとして解釈する SQL Serverは、[a-z]のような正規表現的な記述を解釈する当然、ワイルドカード的な機能を持たせたい「%」や「_」等はエスケープしない全データベース共通の話として、エスケープ文字自体もエスケープする必要がある（MySQL、Postgresでは「\」がデフォルトのエスケープ文字） likeのエスケープをした後に、Prepared Statementで値をSQLにバインドする（関連）2008-07-10 - T.Teradaの日記

unarist 2015/02/19

sql
db

リンク

SQLでfloat型を使うということ - iakioの日記

9章ラウンディングエラー(丸め誤差)より floatを使う場合に精度に注意すべきという点については同意です。 SELECT * FROM Accounts WHERE hourly_rate = 59.95; このため、account_idが123の行hourly_rate列にサイド59.95を割り当てても、リテラル値59.95とは等価になりません。 Accounts.hourly_rateがfloat型のとき、MySQLとは異なりPostgreSQLでは、このクエリは59.95が格納された行を返却する。これはMySQLでのfloat型が単精度であるのに対して、PostgreSQLのfloat型は倍精度だからだ。単精度浮動小数点型であるreal又はfloat4を使うとMySQLと同様マッチしなくなる。この時点でもうfloatのことなんて考えたくなくなるところだ。さてAccounts