データベースドキュメント管理システム dmemo のご案内 - クックパッド開発者ブログ
こんにちは、みんなのウェディングに出向中の小室 (id:hogelog) です。 今回はクックパッドとみんなのウェディングで利用しているデータベースドキュメント管理システム dmemo を紹介します。 https://github.com/hogelog/dmemo dmemo を作成し導入した経緯 私は2016年3月頃からみんなのウェディングで Redshift, bricolage, embulk, re:dash 等を利用したデータ分析基盤の構築を進めています。 (みんなのウェディングのデータ分析基盤の現状 - みんなのウェディングエンジニアリングブログ) 社内の誰でも扱えるデータベース、データの集約・計算・加工、ダッシュボードの作成、クエリの共有などは上記ブログ記事でも書いたように Redshift, bricolage, embulk, re:dash 等を組み合わせることで実現
Kazuho@Cybozu Labs: フレンド・タイムライン処理の原理と実践
« MySQL のクエリ最適化における、もうひとつの検証方法 | メイン | MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話 » 2008年06月09日 フレンド・タイムライン処理の原理と実践 MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話に続きます。 Twitter が注目されるようになって久しい今日この頃ですが、友人の投稿を時系列に並べて表示する、というのは、Twitter に限らず Mixi の「マイミクシィ最新日記」やはてなブックマークの「お気に入り」等、ソーシャルなウェブサービスにおいては一般的な手法です。ですが、この処理 (以下「フレンド・タイムライン」と呼ぶ) は、一見簡単そうに見えて、実装には様々な困難が伴います。本記事では、「フレンド・タイムライン」を実現する、プッシュ型とプル型の二種類の手法について、その原
ORMがアンチパターンである11の理由
サンフランシスコのプログラマLaurie Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。 I cannot overstate the degree to which ORM is a dangerous antipattern. — Laurie Voss (@seldo) June 9, 2011 ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない このツイートに対して各方面(ActiveRecord, Doctrine, Hibernate)から多くの（激しい）返信が寄せられて書かれたのが問題のエントリです。まずはアンチパターンとは何かの定義として下記の2つを挙げています。 当初は有益
第39回 DBIx::Skinny：DBIx::Classに不満を感じたら | gihyo.jp
DBIC以降の選択肢 今回はデータベース話の締めくくりとして、DBIx::Class以降に登場したいくつかの選択肢についてざっくりまとめておきます。これらはいずれも若く、DBICに比べてユーザ数も少ないためドキュメントなどの整備が遅れている部分もありますが、今回とりあげるものの多くは日本人がつくっているものですから、英語圏で開発が進められているものより疑問や要望は送りやすいはず。気になることがあったらぜひそれぞれの作者氏に伝えていただければと思います。 DBIx::Skinny nekokakこと小林篤氏のDBIx::Skinnyは、今回紹介するもののなかではもっとも実績豊富なものといってよいでしょう。開発の動機については氏のブログによくまとまっていますが、標準で用意されているCRUDメソッドを使うときだけでなく、速度を稼ぐために生のSQLを書いたときでもinflateなどの補助機能を使え
MySQL と SQLite に対応した DBIx なモジュールを PostgreSQL に対応させる Tips いくつか - Articles Advent Calendar 2010 Casual
こんにちは。PostgreSQL をよく使っている id:sfujiwara (@fujiwara) です。 世間では MySQL のほうが PostgreSQL より人気のようですね (特に Web 業界では)。なので、DBIx な便利なモジュールも開発当初は MySQL と SQLite でしか動かなかったりして悲しい思いをすることがあり、こちゃこちゃ patch を書いたりしておりました。 そこで溜まったいくつかの Tips をここで公開したいと思います。 1. auto increment の扱い まず、いわゆる自動発番なカラムの扱いについて。MySQL ではカラム定義で AUTO_INCREMENT 指定、SQLite では最初のカラムの型を INTEGER にして PRIMARY KEY 指定、でできるやつですね。PostgreSQL では SERIAL 型を使用して定義します
地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。
漢(オトコ)のコンピュータ道: モダンなMySQLの開発環境の構築方法
遅ればせながら モダンな Perl の開発環境の構築方法 モダンなPHPの開発環境の構築方法 モダンなPythonの開発環境の構築方法 モダンな Java の開発環境の構築方法 に続いてみる。MySQLは言語じゃないけど。 コンパイラ等MySQLをソースからビルドするのでなければコンパイラ等は必要ないけど、どうせアプリ開発に必要なので「MySQLなんかいつでもハックしてやるぞ！」という意気込みを示すために入れておこう。OSXならXcode、LinuxならGCC。最新のソースコードじゃないとヤダ！という粋な人にはBazaarのインストールもお勧めしたい。Bazaarは言わずと知れた分散バージョン管理システムであり、MySQL開発チームも採用している。最新のソースコードは次のコマンドでゲット可能だ。 shell> bzr branch lp:mysql-server/5.1 mysql-5.1
SQLite の適切な使用 - Third impact
単純であることに主な設計目標を置く点で、 SQLite はたいていの他の SQL データベースエンジンと異なっています： 管理が簡単 操作が簡単 プログラムへの組み込みが簡単 保守、カスタマイズが簡単 小さくて速いので、多くの人は SQLite が好きです。 しかしそれらの特色は、ただの幸せなアクシデントに過ぎません。 ユーザーは SQLite の信頼性が非常に高いことに気付きます。 信頼性は単純さの結果です。 SQLite は小さく、速く、信頼性が高いのです。 しかし、何よりもまず第一に、 SQLite はシンプルであろうと努力します。 データベースエンジンの単純さは、やろうとする事によって長所にも短所にもなり得ます。 単純さを達成するために、 SQLite は高い並列性、きめ細かなアクセス制御、 組込み関数、ストアドプロシージャ、秘伝の SQL 言語の機能、 XML そして Java
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
ORMを作るために最低限必要な4+1のコンポーネント - Yappo::タワシ
短期間でCPANに上がってる名が通ったO/Rマッパ+αを目を通して、ORMマッパの必要最低限なコンポーネントを整理した。ぶっちゃけもっと削っても良いが一般的にするためにもリストアップ。 ORM 基幹的なクラスで使い方はORMによりけりで、特に無くても良い。 ORM::Schema テーブル定義を行う場所。物によってはデータベースの定義だけ行って。テーブルの定義はORM::Table的な物で行う。 どっちにしろテーブルの定義には変わらない。 大ざっぱに言うと、このクラスからselect系のメソッドが生えている。 ORM::Iterator 結果の行を取り扱うイテレータ。 DBICならDBIx::Class::CursorになりMoCoならDBIx::MoCo::Listが担当。 ORM::Row 結果の行ごとのオブジェクト。だいたいはORM::Schema or Table で定義してるco
DBMによるテーブルデータベース その弐 - mixi engineer blog
インフルエンザで休んだ影響で仕事が鬼のように溜まって消化不良のmikioです（こんな記事を書いている場合じゃない）。さて今回は、Tokyo Cabinetでリレーショナル風データベースを実現したテーブルデータベース（TCTDB）の実装について説明します。 SQLiteとの違いは？ SQLiteはアプリケーション組み込み型のSQL対応リレーショナルデータベースのライブラリです。TCのテーブルデータベースよりもはるかに高機能で、それでいて性能も大変優れています。いわゆるデスクトップアプリケーションに組み込むデータベースをお探しであれば、TCなんかではなく、断然SQLiteがおすすめです。 一方で、TCなどのDBMは、より単純なデータ操作をより高速に実行できるように設計および実装されています。典型的なユースケースとして、大規模Webサイトのアカウント管理や、データマイニングに伴う集計操作が挙げら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FAL Labs