kkaneko.com 2025 著作権. 不許複製 プライバシーポリシー
前回、セッションストアについて悩んでいますという何も解決しないエントリーを書いたら、はてブやTwitterで非常に沢山のコメントを頂きました。色々な考え方があって、非常に参考になりました。ありがたい限りです。別途、考えを整理してまとめようと思いますが、下記の2つの考え方が多いようです。 共用セッションストアの格納先を分散データベースにすれば良いよ セッション設計をちゃんとすれば、クッキーストアを使ってもセキュリティや容量の問題はないよ 私も、どちらかと言えば上2つの方針で考えています。一方で、分散データベースは一貫性を保証しつつ可用性を高めるのは難しいという基本姿勢と、クッキーストアについては設計ミスや実装ミスが起こりうるという現実の中で、どう安全側に倒していけるかという点を考える必要があると考えています。今回は、分散データベースの一貫性について考えていることをまとめてみます。 CAPの定
こんばんはこんばんは。 僕のこの blog は github pages を使っています。ですので、blog 記事書くだけで、github のアクティビティ増えて、なんか「オープンソース活動に貢献してる」風に見えてかっちょいいので、今日も記事を書いてみようと思います。トップ記事がいつまでもアレなのもどうかと思いますしね。(ミルキィホームズのベストアルバムはホントにお勧めなので、みんな買ってね！) この記事読んで、思ったこととかそんな感じの話です。 ユニケージ開発手法、なんかよく分からないんで、よく分からないからカジュアルにこんな感じでつぶやいてみたんですが。。。 うーん、コレどうなんだろ。こういうので十分な環境はあるのだろうけど、業務拡大してある一定の規模超えたら死にそう。 / “シェルスクリプトでビッグデータ処理～ユニケージ開発手法とは～（1/4）:企業のIT・経営・ビジネスをつなぐ情報
一方で、Webサービス系などで論理設計と物理設計をもう一緒くたにやっていくような場合は、 正規化の論理に目の前にあるサロゲートキーを含めないようにすることが大切で、モデリングはナチュラルキーを基軸に考えていくとよいでしょう。 サロゲートキー (代理キー) サロゲートキー + (複合)ユニーク制約 ナチュラルキーをPKにせず、例えば連番となるようなカラムを用意して、それをPKにします。 これがサロゲートキーと言われるものですが、ナチュラルキーには別途ユニーク制約を付与する というのを忘れてはいけません。 ここでは、ナチュラルキーにユニーク制約を付けずにサロゲートキーだけを導入する方式は、業務的・実装的に意味はないと考え、ここでは取り扱いません。 議論の対象にすらしません。ユニーク制約を付けることで業務的なユニーク性を保ちつつサロゲートキーの恩恵を得ることができ、同時にナチュラルキーを明示する
(初心者向け)SELECT文を考える時には最終アウトプットを強く意識する。
SELECT文を考える時、何となくjoinやgroup byとか使ってませんか？もしくはメインとなるテーブルを意識していますか？ SELECT文は非常に便利なので気づかないのですが裏で実行されている事は（非常に簡単に言うと） ・縦＊横の二次元の表を付きあわせ、新たな縦＊横の二次元の表を作成 しているだけなのです。 その際に、一行の粒度が変わる事に注意が必要です。多重度が大きい側にjoinすると、自ずと一行の粒度が変わってしまう（行が増えてしまう）為、初心者のうちは自分が何をしているのか分からなくなります。 例えば次のER図があり、 最終的に次のような表が欲しい場合、どういうSQLを書きますか？ 私は概ね次のステップでSELECT文を考えます。 ・最終アウトプットの一行の粒度を確認する。 この場合注文明細の行数が最終アウトプットの行数と同じ ・その粒度にあったテーブルをメインの表にする。 f
基本的にRailsでは単一のDBを使用するように設計されています。とはいえ負荷軽減のためだったり、あるいは様々なしがらみのために複数のDBに接続しなければいけない場合がたまにあったりすると思います。しかも残念な事に違うDBに同じ名前のテーブルがあったりしてどうすんだよコレとなることも無いとは言えないでしょう。 ActiveRecord が connection pool に対応したのは知識としては知っていましたが複数のDBに実際につなぎにいったばあい connection はどうなるの？と疑問に思ったので調べてみました。 # activerecord-3.0.3/lib/active_record/connection_adapters/abstract/connection_specification.rb 51行目 - 82行目 def self.establish_connectio
![[rails] ActiveRecord3の connection_pool の挙動を調べた - よしだメモ](https://cdn-ak-scissors.b.st-hatena.com/image/square/60944e7788036cbe3f523eef84e8712f00be3001/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fogimage.blog.st-hatena.com%2F17680117127031972029%2F17680117127031974003%2F1555344835)
[Rails3] ActiveReocrdで外部DBを使う
Railsでは基本的に１つのDBを使用するように設計されています。デフォルトで使用するDBは config/database.yml 内で、実行モード（Rails_Env：development/test/production）別にDBが指定されていますが、これらのデフォルトのDB以外のDBに接続するやり方です。 用途としては例えば、他のシステムで使用しているユーザテーブルを参照する（いわゆるレガシーDBというやつですね）、アクセスログデータを別のサーバ上に保管する、などといった場合があるでしょう。 ここで想定する外部DB/テーブルの条件使用しているデータベースのアダプタがある MySQL, PostgreSQL, SQLite3, Oracle, DB2, SQL Server, ... 使用するテーブルに、整数型の単独の主キーが存在する Railsアプリケーションのサーバからアクセスが
1 (5) ( ) JPOUG> SET EVENTS 20120721 2012/07/21 2 • DB Oracle MySQL – RDBMS – Oracle MySQL 8 2 • Twitter @sh2nd • id:sh2 • 3 • – 1 http://d.hatena.ne.jp/sh2/20090802 – 2 http://d.hatena.ne.jp/sh2/20090816 – 3 http://d.hatena.ne.jp/sh2/20100112 – 4 http://d.hatena.ne.jp/sh2/20100510 • 4 • 2 4 5 • • A • D A • Apache Bench • Apache JMeter • HP LoadRunner B • SPECjbb2005 C • Oracle Real Application Te
テキストなど非構造化データのデータベース機能とサーチエンジン機能を兼ね備えた分散リアルタイムデータベース「SenseiDB」が、オープンソースとして公開されています。 SenseiDBとは先生DBの意味らしく、「Sensei (先生) means teacher or professor in Japanese」と説明があり、ロゴにも「師」の文字が使われています。なぜ先生なのか、その意味について以下のように説明があるのですが…… This name indicates that the system can be used in place of Oracle database in many applications. この名前が示しているのは、このシステムが多くのアプリケーションにおいてOracleデータベースで使われているところで利用可能だということです。 TeacherやProfe
業務システムの要件を定義して設計する手法は、プログラミング手法とは大きく異なる。 プログラミングはオブジェクト指向がベストプラクティスだが、要件定義や設計の手法は日本独自のDOA(データモデリング)の方がやりやすいような気がしている。 特にRailsという優れたWebフレームワークが出現して、データモデリングの重要性が増してきたように思う。 理由は、テーブル設計さえできれば、マイグレーション機能によってDBスキーマを一発で生成できるし、scafold機能によってテーブルのCRUD画面はあっという間に実装できるからだ。 つまり、テーブルさえ作れれば、業務システムをWeb上で動かして簡単に理解できるようになってきた現状があるからだ。 僕が今まで読んできた本の中で、自分が役に立ったと思う本を列挙しておく。 【1】グラス片手にデータベース設計編 グラス片手にデータベース設計~販売管理システム編 (
で、話してきた。楽しかったーーー。 めちゃめちゃ疲れているけど、脳内麻薬が出ているぽいので、ブログくらいは書けそうだ。ブログを書くまでが勉強会ですよ、と言った手前、書かないわけにはいかないぜっ。 まぁ、セッションに関しては自分が話したので反省点のみ。緊張しすぎ俺ｗ もっと緊張せず、自然体で話せるようになりたいもんであります。 セッション時間の方は見積もりバッチリ。ほぼジャストの時間で終了しました。俺++ 今回は、事前に id:papanda と飲んだ時にDevLOVEの一つのポイント「明日から実践できること」というテーマをもらっていた。みんな色々な現場に属していると思うが、明日からいきなり「Jiemamy導入しましょう！」ったって難しいですよね。理解もまだまだ得られていないと思う。（理解をいただく為に、コツコツと巡業しますｗ） そこで、Jiemamyのベースとなっている考え方を基に、いくつ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
