っぽいですね。
Djangoはコメントにもらったこのページに「一つのオブジェクトには一つしか主キーを指定できません」て書いてあります。

SQLObjectも主キーは１つしか対応してません。なのでTurboGearsも無理。
http://ymasuda.jp/python/sqlobject/doc_0.7/SQLObject.html

「SQLObject は複数カラムからなる主キーをサポートしません (この仕様は恐らく今後も変わらないでしょう)」だそうです。

うーん、既存スキーマが自然キー使っちゃってる場合ってまだまだありそうなんですが、そうするとPython系はいきなり選択肢から外さざるを得なくなりますねえ。
この辺は技術じゃなくて、ロビー活動（ていうか要件調整）で既存スキーマに依存しなくてもよいようにするしかないですね。でも既存スキーマをいじらなければいけない状況もあると思うと、Railsは守備範囲の広さでは頭一つ抜きん出ていますね。

RailsはOracle対応なのも大きい。SQLObjectはまだ不完全とドキュメントに書いてある。Djangoは結構頑張ってるっぽいからRails並みに行けそう。RailsのOracleアダプタも「おや？」という部分がありましたが、今のところはバッチリ使えてます。シノニムもちょっと工夫したら行けました。ビューは使ってないのでわからないけど、まあ行けるでしょう。
ちなみに複合キーはダメです。自然キーはダメです。

なぜって、人間が見てわかりやすいモデルでも、モデルを参照するのはプログラムで、プログラムが書きやすい形 は圧倒的に単一代理キーの方だから。生産性、保守性＝変更のしやすさ（細かく言うと変更性は保守性の一部）が圧倒的に高いです。

生産性を無視してモデル（の見た目）にこだわるのは本末転倒。そういう人はプログラムを書いたことがないとしかいいようがない。もしその人がSEなら、僕なら完全に失格として扱います。コード書いてから言えと。
アイデンティファイアーとPKは切り分けましょう。

最近はJavaでもRubyでもPythonでも代理キー前提のフレームワークが出回って浸透してきたので、今後は楽になって行きそうですけどね。いい時代になったものだ。


でも参照整合性制約を張るか張らないかは、まだ迷うところ。データの保全性としてはもちろん張るべきだけど、スキーマの変更性としてはどうだろう、というところでまだ答えが出てない。開発時だけオフればいい気もしつつ、張るとパフォーマンス落ちるしなあ、とか。皆さんどうしてるんでしょう？

ちなみに今回は張らない方向にしました。これで次回移行時に変なデータが多かったら、やっぱり張るべきという答えになりそう。問題なければ張らんでもよか、という結論になりそう。