Written in JavaScript, works cross-browser. Provides SQL-like APIs that are fast, safe, and easy to use.
Written in JavaScript, works cross-browser. Provides SQL-like APIs that are fast, safe, and easy to use.
Knex.js (pronounced /kəˈnɛks/) is a "batteries included" SQL query builder for PostgreSQL, CockroachDB, MSSQL, MySQL, MariaDB, SQLite3, Better-SQLite3, Oracle, and Amazon Redshift designed to be flexible, portable, and fun to use. It features both traditional node style callbacks as well as a promise interface for cleaner async flow control, a stream interface, full-featured query and schema build
先日PHPカンファレンス北海道2016にて「『例えば、PHPを避ける』以降PHPはどれだけ安全になったか」と題して基調講演を担当致しました。その際のスライドはこちら。 そうしたところ、以下のご指摘をいただきました。 @ockeghem スライド拝見しました。39番目のスライドですが、バインドのタイミングでintにキャストするのはちょっと例として良くない気がします。意図的にオーバーフローを起こすことで想定外のレコードの取得を許してしまいそうです。キャストしない方がまだ安全だと思うのですが。 SQLデータベースは、int型よりも大きな桁数を扱える場合があるので、intへのキャストを避けた方がよいという指摘は一般論としてはもっともなものだと考えます。PHPの場合、9223372036854775807を越える数字文字列をint型にキャストすると、9223372036854775807が返ります(
Lobiチームの長田です。 今回はLobiで使用しているデータベースの構成・運用について紹介します。 TL;DR メインのデータベースとしてMySQLを使用 一般的なmaster-slave構成 HAProxyとMHAでDBのfailoverを自動化 HAProxyでslaveへの接続を分散・死活監視 MHAで障害時のfailover・ENIを付け替えてmaster切り替え で、何が起こるの? サービスが提供できなくなります。 ユーザーの認証情報等、サービス提供に必要不可欠なデータを管理しているため、一時的なサービス停止は免れません。 ユーザー体験的にもビジネス的にも、大変厳しい状態です。 この「一時的」な時間を可能な限り短くするために障害復旧の一次対応を自動化しています。 自動化のメリットとして、単純にサービス停止時間が短くなることはもちろん、 復旧処理を行う際の人的なエラーを未然に防ぐ
37. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_flag = 0 WHERE blog.delete_flag = 0 38. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_flag = 0 WHERE blog.delete_flag = 0 ユーザの削除フラグを見る 39. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users
N+1, solvedEdgeDB solves the problems that ORMs exist to workaround. A comparison that speaks for itself: SELECT movie.title, ( SELECT avg(rating) FROM reviews WHERE movie_id = movie.id ) AS avg_rating, (SELECT array_agg(q.v) FROM (SELECT person.name AS v FROM actors INNER JOIN persons AS person ON (actors.person_id = person.id) WHERE actors.movie_id = movie.id ) AS q WHERE q.v IS NOT NULL ) AS ac
by @dekokun on 2014/05/31 20:46 Tagged as: MySQL. どうも。先日結婚式を挙げました。二次会のために手作りの巨大くす玉を作るノウハウを手に入れましたのでそのあたりもいずれブログに書きたいですね。 概説 MySQL5.6.5から、DATETIME型でも行の生成時刻と更新時刻を自動更新できるようになりましたよ。 方法 作成時刻は DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP で 更新時刻は DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP で宣言しましょう 参照:How do you set a default value for a MySQL Datetime column? 以下、MySQL5.6.17で検証
前回の記事で少し触れましたが、 go-sql-driver/mysql にドライバ側でのプレースホルダ置換を実装するプルリクエストを出していました。 それがマージされたので、背景のおさらいと利用方法を紹介しておきます。 背景 Go の database/sql の概要については前回の記事で解説しました。 そこで説明したとおり、 DB.Prepare() を使わずに直接 DB.Exec() や DB.Query() を使った場合、 ドライバ側でのプレースホルダ置換に対応していないドライバでは prepare, exec, close で3回のラウンドトリップが発生することになり、パフォーマンスが悪くなります。 基本的には DB.Prepare() を使えばいいのですが、前回の記事で修正したスケーラビリティの問題は Go 1.5 になるまで直りませんし、 IN 句があるSQL文などで事前に P
フルスタックと聞いたからrevel使ってみたのにモデル層のサポートどころかORM(あるいはそれを良い感じに使うレール)もないじゃねえかみたいな感じで仕方なくちょろっと調査した、みたいな所感だけを書いた雑なエントリです。 結論 色々やろうとすると最終的には諦めてdatabase/sqlを使うのが良い。割り切りが大事。 試したライブラリ GORM https://github.com/jinzhu/gorm 多分一番リッチ。 後で書くけど、リレーションを含めたコードファーストなデータストア定義とかをしたいならこれしか選択肢なさそう。 gorp https://github.com/go-gorp/gorp 正確には"ORM-ish library for Go"だけどね genmai https://github.com/naoina/genmai "Simple, better and ea
ORM for golangのGenmaiを使って、MySQLにアクセスしてみた。 使い方は以下の様な感じです。 テーブルを定義します。 データベースを作る時に、&genmai.MySQLDialect{}と、DSNを指定する。 これを実行すると、 テーブル作成できた! データの挿入もOK! あれ?データの取得が下記のエラーでコケるなぁ。 time.Timeを使ってる箇所は、User構造体のgenmai.TimeStampのところだけです。ちなみにgenmai.TimeStampがどうなっているかというと、 となっています。 また、MySQLのドライバに、github.com/go-sql-driver/mysqlを使っています。 うん、ココらへんが怪しいですね。とおもって調べていたら、github.com/go-sql-driver/mysqlはtime.Timeはサポートしているのです
golangではmysqldriverでmysqlにアクセスできますが、 一つ一つ構造体に入れないといけなかったりと、けっこう辛いものがあります。 goでmysqlを使う そこでいろいろ探していたところ、 ActiveRecordのように構造体を使ってDBにアクセスできるORMがありました。 https://github.com/jinzhu/gorm 自動でテーブル作ってくれたり、変更してくれたりと、他のORマッパーよりかはActiveRecordっぽいです。 リレーションも勝手に貼ってくれるみたいです。 ただし、取り出すときは元のオブジェクト→リレーションのオブジェクトと、 順に取ってくる必要があり、自動でリレーション先のオブジェクトの取得はしてくれるわけではありません。 (使わない場合は無駄なアクセスになるので、正しいと言えば正しいですが) package main import (
前回の日記(Go言語でのORMを色々検討してみた - タオルケット体操)の続きみたいなもんです。 もしかしてRevelはそもそもMVCに関心がない? もしかしてMVCゆーてるだけちゃうんかみたいな疑問が。だったらもっとminimalなフレームワーク使うんですが、それは…(絶望) 前回の日記のケツの方で、RevelがFat Controllerを推奨しているようにしかみえなくてどうなの大丈夫なの? みたいな疑問への、自分なりの妥協案回答です。 同じようなことを考えてる人はちらほらいるようで、RevelのUserメーリスにもこんな質問がありました。 Google グループ サンプルの場所はここ(Booking | Samples | Revel - A Web Application Framework for Go!)です。 ソースコード本体はRevelに含まれるgithub.com/rev
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題(クエリ)を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ(アプリケーションの設計者)に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
MySQL 5.6 リファレンスマニュアル というわけで、日本語版のマニュアルがリリースされた。これまでMySQL 5.6のリファレンスマニュアルは英語版しか無かったのだけど、公式に日本語版がリリースされる運びとなったので、是非参照して頂きたい。 かつてMySQL 5.1の日本語版マニュアルが存在したのだが、そちらは現在ウェブから参照できなくなっている。(PDF版はダウンロードできるという話も。)MySQL 5.1の日本語版マニュアルは、ぶっちゃけ翻訳があまりイケてなかったので、今後はぜひMySQL 5.6の日本語版を参照してもらいたい。ついでにもう古のバージョンは窓から投げ捨てて、この機会に是非新しいバージョンへ移行してみてはいかがだろうか。 何か問題が見つかった場合には、ぜひバグレポートをお願いします。バグレポートのカテゴリは「Japanese Documentation」を選択してく
PostgreSQL 9.2より追加されたJSON型だが、特徴を理解して適切に使わないと色々な副作用に悩まされることになる。その問題点を挙げると共に、どのような場合に使うべきかの指針を示す。 PostgreSQLは、データ型としてjsonをサポートしています。しかし、やりたいことがある時に何でもかんでもjson型を使ってしまうというのはやめるべきです。これは、hstoreや新しく登場したjsonb型にも同じことが言えます。これらの型は必要な時には便利なツールになりますが、PostgreSQLでデータのモデリングを行う際に最初に検討すべきものではありません。 なぜなら、データを呼び出したり操作したりするのが難しくなってしまうためです。 何もかも同じところに入れてしまおうとすることによるアンチパターンをご存知の読者もいるでしょう。EAVアンチパターンは、長らくデータベーススキーマにおける必要悪
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く