ベストORM、シンプルなデータ構造、強力なクエリ分析

Question

単純なデータ構造のための最良のORM dbの組み合わせは何ですか？これは、識別子と場所として名前が含まれていますが、主なやり取りは時間（スポーツ時間）の数値データと通貨関連のデータになります。

私は最初に名前と統計情報を取るスポーツデータベースを作成したいと考えていました。二次的に私は投資と株価分析のデモを開始する予定です。

どのORMが多くの数値型を格納するのに適しており、強力なクエリ機能を備えていますか？

DBエンジン（ほとんどの場合、sqliteやmongoを使用している）に偏っていないので、最適なネットワークの少ないDBサーバーがORMに感謝しています。

私はいくつかのオプションを見直しましたが、私は提案や意見に影響を与えたくありません。しかし、参考のために。

Genstone /ガラス - Smalltalkの/ファーロ/スクイーク マグマ - ファロ/ Squeakの SQLAlchemyの - Pythonの 続編 - ルビー アクセス/エクセル - Micorosoft 私はスキームを勉強していますがラケットを経由して提供する上でORMを見ていませんか、現時点ではチキン。 Dabo - python

Answer 1

私は、NoSQLとのORM（例えばmongodb）は必要ないと考えています。オブジェクトが作成され、変更され、相互に関連し、発見され、削除される方法からデータストアに相違がある場合は、できるだけ小さく、邪魔にならないようにする必要があります。これは、RDBMSを使用して作業する場合、ORMの仕事です。しかし、原則として、1つ以上の言語のオブジェクトを永続ストアにマッピングするという問題は、永続ストアがリレーショナルデータベースである場合には、サブセットよりもはるかに広いです。

今日、複数のレベルの分散ストアとローカルストアでは、問題は大きくなく小さくなっています。データは、プロセスメモリからローカル共有メモリに、SSDとHDの任意の組み合わせ、そこから分散メモリ（例えば、memcache）、および可能性としては複製された遠隔記憶装置へのローカルディスク記憶装置に広がる可能性がある。モバイル、ローカル、クラウドはもちろんのこと、

ORMを解決する問題は、今日深くて広くなっています。

1987年に私の最初のORMをObjective Cからリレーショナルデータベースコア（ファイルレベル）に書きました。私はその後、ODBMSに言語をインターフェイスするオブジェクトデータベース会社に数年働きました。オブジェクトデータベースでさえ、いくつかの不一致があり、言語特有の強力ではあるが透過的なインターフェースが必要でした。