Sequel: The Database Toolkit for Ruby
Ruby Sequel is a lightweight database toolkit for Ruby.Sequel provides thread safety, connection pooling and a concise DSL for constructing database queries and table schemas. Sequel also includes a lightweight but comprehensive ORM layer for mapping records to Ruby objects and handling associated records. Sequel supports advanced database features such as prepared statements, bound variables, mas
Matzにっき(2007-09-05) [言語] SQLAlchemy, Declarative layers, and the ORM 'Problem'
<< 2007/09/ 1 1. U20プロコン最終審査会 2. 死なないために 3. [Ruby] davidflanagan.com: Nifty Ruby Unicode codepoints utility 2 1. [教会] 第一日曜日 3 1. [Ruby] RubyアソシエーションがRuby言語公式ロゴのデザイン募集：ITpro 2. [OSS] Open Tech Press | GNU GPLv3 日本語訳 3. [言語] retlang - Google Code 4 1. Full Disclosure: World's most powerful supercomputer goes online (fwd) 2. [知財] 元麻布春男の週刊PCホットライン - DRMどころかEPNも嫌いだ 3. 取材 5 1. 取材 2. [Ruby] Ruby needs a
SQLに依存することの危険性 ー 単体DBサーバでは終わらない時代の考え方 | 独り言v6
ベンチャー社長で技術者で:ベンチャー社長で技術者で: オブジェクト指向言語で処理したら保守性が悪い！. というのを目にした。要するに「OO言語＋RDBな組み合わせ」において、O\Rマッピングに頼らずにちゃんとSQLとストアドを書いた方がいい、と言うことである。 L.staｒは元々Java屋でそれからSQLに移ったので、未だに自分が両方をバックグラウンドに持つ人間だと思っている。O/Rマッピングのイ ンピーダンスミスマッチを解決する簡単な方法が実は無い、と言うぐらいには両方を理解している。だからこそ言いたいが、この文章、特定のDBが中央に鎮座していて、それがすべての中心になるような業務システムにおいては完全に正しい。ただし、元々そう言うシステムを念頭に置いて書かれた文章であるので、その点はちゃんと考えるべきだ。O/Rマッピングに頼り切って、SQLをきっちり書かない、ということをすると性能が出
「外部キーを張らない」設計への雑感 - スコトプリゴニエフスク通信
僕はOracleでRDBMSとかSQLを勉強した人間なので、絶対に外部キーを張り、可能であればチェック制約もかけて、絶対に不正なデータは入れさせたくないと思う人間なのだが、LAMPサーバーを並べてスケールさせるっていう今時のサイトでは、外部キーを張らない設計の方が主流らしい。・・・本当！？確かに、アプリケーションやORMで頑張れば、外部キーを張るメリットが消え、外部キーを張るデメリットだけが残り、そしてMySQLはRDBMSではなく、SQLをサポートする単なるストレージになるだろうが・・・ちなみにSQLAlchemyならばテーブル定義から外部キーを消しても、mapperの定義で明示的に示してやれば、いままで通りのコードが動くはず。以下は「飼い主(Owner)と犬(Dog)の間に一対多の関係がある」という場合の例。 # -*- coding: utf-8 -*- from sqlalchem
Birth of DBIx::DataModel (or : Perl ORMs in 2005)
DBIx::DataModel is the object-relational mapping (ORM) layer we use for our projects at Geneva's law courts. It is much less known that DBIx::Class, but nevertheless a few people have shown interest in it, so I thought it's worth blogging about some of its design aspects. Today's blog is about history : a couple of words about why and how DBIx::DataModel was born. Back in 2005, I had already writt
ORMapper Active RecordとData Mapper など - name-3333’s memo （いい加減なこと書いてるので信用しないでください）
22:37データアクセスことはじめhttp://otndnld.oracle.co.jp/columns/arai-semi/data_access/1/index.htmlhttp://otndnld.oracle.co.jp/columns/arai-semi/data_access/2/index.htmlわかりやすい。以下、自分の意見も入ってる自分まとめ。ドメイン層（Model） Transaction Script：トランザクションに対応した関数インターフェイスを提供。昔の非OO型のAPIのような形。Table Module：OO型だがテーブルに対応したクラスを作るDomain Model：完全なOO。中身は自由パーススタンス層（データ保持：DBアクセス） Table Data Gateway：データベースに対するアクセスSQLの単なるカプセル化Row Data Gateway：
第17回：新春O/Rマッパー対決2009 - monjudoh’s diary
株式会社ビープラウド Django ORマッパー 多対多のリレーションを張るときに間のテーブルをORマッパー側で管理してくれる。 Queries データ取ってくるときにjQueryっぽいメソッドチェーンが使える 〜.filter(〜).filter(〜).count()みたいな感じ。で、一つのSQLを生成して実行してくれる。 Saving Modelのオブジェクトのsaveメソッドを呼び出しておしまい。 insert/updateを勝手に判定してくれる。 Admin Modelから一般管理ページを生成する機能。 他 論理削除等の扱いがいい感じらしい SQLAlchemy Pythonの主要なORM SQLObject Django ORM SQLAlchemy SQLAlchemyのみData Mapperパターン、他2つはActive Recordパターン。 特徴 Data Mapper
OmniTI ~ ORMs Done Right
Level: This article reviews a fundamental concept or principle This article reviews an intermediate concept or principle This article reviews an advanced concept or principle This article expresses an opinion or just a downright rant Object-Relational Mapper (ORM) systems are one of the most contentious topics in database application development. Creating an ORM is notoriously perilous, but using
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://yappo.ficia.com/
SQL-DB-0.971.2 - SQL database interface for Perl (DEPRECATED) - metacpan.org
TurboGears Japanese (at Lingr) > Archives > April 04, 2007
PostgreSQL & Perl videos on Vimeo
Exposing the ORM Cache - ACM Queue
https://www.func09.com/wordpress/archives/532
Fey-ORM-0.47 - A Fey-based ORM (If you like SQL, you might like Fey::ORM) - metacpan.org