ActiveRecordで多階層カテゴリ(Ancestry) - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
12章 Index Shotgun(闇雲インデックス) - Qiita
CREATE TABLE Mikosan ( miko_id SERIAL PRIMARY KEY, date_joined DATE NOT NULL, description VARCHAR(128) NOT NULL, status VARCHAR(10) NOT NULL, hours NUMERIC(9.2), INDEX(miko_id), INDEX(description), INDEX(hours), INDEX(miko_id, date_joined, status) ); mysql> show index from Mikosan; +---------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+----
クエリチューニング: GROUP BY から LATERAL への書き換え - Qiita
「ユニークキーの GROUP BY」 を 「LATERAL」 に書き換えることで、クエリを性能改善できる可能性があります。 ここでは、非常にシンプルな書き換えの例を示します。 テーブルの準備 まずは、以下のような「部署」、「書籍」、「部署ごとの書籍在庫数」を管理する3つのテーブルを準備します。 なお、「書籍」テーブルは、データベースの状況をイメージしやすいように用意しているだけで、以降のクエリ書き換えでは特に使いません。 -- 部署のIDと名前を管理するテーブル department を作成 CREATE TABLE department (dept_id INTEGER PRIMARY KEY, name TEXT); -- 部署の情報を5件登録 COPY department (dept_id, name) FROM stdin; 1 総務部 2 開発部 3 財務部 4 企画部 5 購
ストアドプロシージャの基本的ななにか - Qiita
あんまり知識ないけどがんばる SQLにも存在する様だけど, MySQLでしか経験がないからMySQLで書くよ 対象 以下に該当する方が対象です。 ある程度, SQLクエリが読める ある程度, DBの知識がある 背景 資料を探せど探せど, (個人的に)良いドキュメントが見つからなかったので 『じゃあ書いちゃおう』と思いました。 ※悪い資料だらけってわけじゃないけど, 物足りないとか惜しい記事ばかりだったので。 ストアドプロシージャって？ DB上での一連処理に, 名前をつけて関数のように, 呼び出して使用できるもの。 DB上で動作を完結させちゃうから, 開発言語に依存しないよ！ Ruby とか PHP だとか Perl でも Python だろうと CALL できれば結果は同じになるはずだよ！ 権限まわり 作成
MySQLでのトランザクション処理をGolang+dbrで実現してゆく話 - Qiita
環境 Go :go version go1.6.2 darwin/amd64 IDE :VSCode1.1.0 echo:Echo v2.(beta) MySQL: Ver 14.14 Distrib 5.7.12, for osx10.11 (x86_64) OS:Max OSX El Capitan 俺 :Go初めて3日目 MySQLはHomebrewで入れました。 トランザクションとは トランザクションとは、連続する複数のデータ操作のまとまりのこと 特徴として： ユーザはトランザクション単位(複数のデータ操作)での取り消しと確定ができます(トランザクション処理) 複数のデータ操作が連なっている時、「複数の更新処理を連続して行う際に、すべての処理が成功したときにのみデータベースへの変更を有効としなければならないデータ操作」では、このトランザクション処理は必須です。 ただのロックとは違い
HTTP/1.1 200 OK - Qiita
※このお話はたぶんフィクションです。実在の人物や団体とはあんまり関係ありません。 序 planetter.comをバージョンアップすることにした。数年前にリリースしてからずっと放置していたけど、そろそろ手を付けないとやばいと思った。 しかしウェブの世界はドッグイヤーだ。3年も経てば何もかもが変わっている。しばらく開発から遠ざかっていた僕には、最近の技術トレンドなんてさっぱりわからない。 まずは自分自身をアップデートするところから始めよう。 Atom 最初はIDEだ。以前はEclipseを使っていたけど、いまはもうウェブ系言語の進化速度に追いつけていないようだった。ウェブ開発用のIDEならいまはWebStormが人気のようだ。有料だけど、最新の技術に対応しているし、使い勝手もいい。 でも最終的にはAtomを選んだ。IDE(統合開発環境)ではなくエディタなので、これ自体は単機能だけど、不足分は
天下一「AndroidのORM」武道会（2014年版） - Qiita
はじめに この記事は「Android Advent Calendar 2014」の5日目の記事です。 追記(2015/12/19) 2015年版を書きました。どうぞご覧下さいませ。 天下一「AndroidのORM」武道会（2015年版） - Qiita tl;dr 3行でまとめ へ移動↓ AndroidのORM事情 スマートフォンアプリでは、ネットワークから取得したデータの保持や、ユーザーが入力したデータの保持、その他いろいろなデータの管理にSQLiteデータベースを使用することが多いと思われます。 これらはAndroidの標準APIで操作できますが ―一度やってみればわかりますが― 非常にめんどくさく、思わず険しい顔になってしまいます。 そんなAndroidのSQLite操作を楽に行うため(そして実装時間節約のため)、O/Rマッパー(ORM)を導入するのは良い判断だと思います。 ところが
AuroraとRDS MySQL 5.7のsysbench - Qiita
この記事を見て、結果に疑問を持ったので、AuroraとRDS MySQL 5.7のベンチマークを取ってみました。 動作環境 サーバ Aurora 5.6.10a / db.r3.large / SingleAZ MySQL 5.7.10 / db.r3.large / SingleAZ io1 / 100GB / 1000iops 設定はそれぞれ以下を変更 sync_binlog = 0 innodb_flush_log_at_trx_commit = 2 クライアント 4.1.17-22.30.amzn1.x86_64 / c4.2xlarge sysbench 0.4.12 サーバとクライアントはすべて同じAZ 並列数を高くできるように以下の値を増やした max_connections max_prepared_stmt_count nofile テストスクリプト --oltp-tab
突然のUnbuffered Query…PDO+MySQLで入り込んだ迷宮 - Qiita
CodeIgniterをバージョンアップしたところ、思わぬ形でPHPのバグを踏んでしまいました。 MySQLのバッファモード トラブルに見舞われるまで知らなかったのですが、PHPからMySQLを使う場合には、「バッファモード」と「非バッファモード」があります（リファレンス）。 バッファモード…SQLを発行すると、自動的にPHP側へ全データを取ってくる。デフォルト設定。 非バッファモード…SQLを発行した段階ではまだデータを取ってこない。 一見すると、非バッファモードのほうが便利そうに見えるのですが、1つ大きな問題があります。非バッファモードの場合、一度投げたクエリを始末し切るまで次のクエリが投げられないのです。もちろん、それを意識した上でPDOなりMySQLiなりを直接叩くのであればまだ使いでもあるのですが、（非バッファモードに対応しない）フレームワーク経由でDB接続するとなると、どこでク
PhoeixでElixirのマルチプロセスモデルを学びながらMemcachedにアクセスできるようにしてみる - Qiita
やること Phoenixアプリにmemcachedにアクセスするプロセスを追加する Phoenixで子プロセスを立ち上げている部分を確認 Elixir（そしてErlang）は複数のプロセスが協働しながら一つのアプリケーションを実行するマルチプロセスモデルを採用しています. なので当然Elixirで作られているPhoenixFrameworkも同様にマルチプロセスモデルを元に作られています. 実際に, アプリケーション作成時に以下の様なコアモジュールが作成されます. defmodule PhoenixSample do use Application # See http://elixir-lang.org/docs/stable/elixir/Application.html # for more information on OTP Applications def start(_typ
memcached-cli で Memcached の Slabs Reassign と LRU Crawler を試してみる - Qiita
この記事では、Gotanda.pm #8 でデモをする予定だった内容の手順と結果を紹介します。 勉強会では、発表時間が足りずデモが実施できませんでした。 何かの参考になれば幸いです。 はじめに memcached-cli は筆者が開発した Perl 製の Memcached クライアントです。 テキストプロトコルでできる操作はすべて実行でき、TELNET よりもユーザーにやさしいインタフェースとなっております。 依存も少なく、Perl 5.8 以上であれば動作するように作ったつもりなので、Memcached をお使いの方はぜひ使ってみてください。 Memcached Slabs Reassign と LRU Crawler について デモの手順に入る前に、今回触れる Memcached の機能について、かんたんに説明しておきます。 そもそもの話ですが、Memcached はデータをサイズに
Serverless 使って Lambda から RDS を使用する - Qiita
先日 Lambda の VPC サポート実装がアナウンスされてたので試してみました。 VPC サポートの実装により、Lambda と RDS, ElasticCache などを連携させられるようになりました。 使ってみた所感としては、今まで用途が限定されていた気がする Lambda の使いどころがかなり広がったんじゃないかと思います。 小規模な案件なら本当にサーバいらなくなるんじゃないでしょうか。 諸々インストール フレームワークは jaws の後継 serverless を使います。 動作には node V4 が必要です。 作業は適当に立ち上げた EC2 インスタンス上で行いました。 $ git clone git://github.com/creationix/nvm.git ~/.nvm $ source ~/.nvm/nvm.sh $ nvm ls-remote # 最新のバージョ
PostgreSQLアンチパターン：外部キー制約の更新コストを見くびる - Qiita
CREATE TABLE reports ( id bigserial NOT NULL, user_id bigint NOT NULL, time_of_report timestamp without time zone NOT NULL, previous_report_id bigint REFERENCES reports (id), elapsed_time integer NOT NULL DEFAULT 0, CONSTRAINT reports_id_pkey PRIMARY KEY(id), CONSTRAINT reports_user_id_fkey FOREIGN KEY(user_id) REFERENCES users(id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE CASCADE ); CREATE INDEX
ad3e04e50357a1e758fc#_reference-a1b4100c3771c36dfbe6
SELECT COUNT(*) INTO before_count FROM table1; ... INSERT INTO table1 ...; ... SELECT COUNT(*) - brefore_count INTO registered_count FROM table1; なにかTABLEへの追加処理をしてますが、意図通りにできたかどうか、前後で COUNT(*)をとって、その差分を報告させようとしています。 複数のプロジェクトの複数のオーナーのコードで見かけたので、こんな初級アンチパターンも共有しときます。 なにがまずいの? COUNTは、シーケンシャル・スキャンしないと出てこない値なのです。アンチパターンでは、テーブル全体が対象ですから、主キーインデクスを総なめです。小さいテーブルのうちはいいのですが、運用の1000万行を越えるような巨大テーブルだと、主キーインデック
個人開発アプリのサーバーサイド環境を金と時間をかけずに用意する方法 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事はSansanアドベントカレンダー3日目です。 前提 個人でアプリを開発していても、やっぱりなんだかんだサーバーサイドが必要になる機会ってあると思います。ただ、注力したいのはやっぱりアプリ側の開発なのでできるだけサーバーサイドにはコストをかけたくない、そんなときどうすれば、、、みたいな話です。 基本的には、 金をかけたくない 時間をかけたくない でもサーバーサイド用意したい という前提で雑にサーバーサイド環境を用意する場合の話です。 作ったアプリなど 最近は放置気味になっていますが、下記のようなアプリをこれまでにリリースしました
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2章 Naive Trees(素朴な木) - Qiita
Spring BootでSpring Data Redisを利用する - Qiita
FuelPHPのDB基本と返り値 - Qiita
macでphpからmemcachedを使用できるようにする手順 - Qiita
よく使うOS・ミドルウェアのサポート終了期限(EOL/ライフサイクル)をまとめた - Qiita
