7

私はScalaで新しいプロジェクトを開発しています。これは一連のCRUD操作のアプリケーションにすぎませんが、いくつかの風変わりな要件があるため、Play2またはLiftは法案に適合しないため、アプリケーションをゼロから開発します。これは、AnormまたはScalaQueryがデータベース統合の選択肢としてはあまり明白ではなくなり、疑問が残ることを意味します。何か新しいことを試すときが来たのでしょうか。

私の過去のテクノロジースタックには主にJavaとPostgreSQLが含まれており、ORMとプレーンSQLの両方の経験があります。MongoDBのようなNoSQLデータベース管理システムは、一般的なRDBMSの優れた代替品ですか、それとも特殊なケースのアプリケーションデータストアですか？また、データベースの選択は、Scalaシステムの設計にどのように影響しますか（あるとしても）？たとえば、JSONのようなインターフェースを使用してデータベースと通信しているという事実、およびWebとRESTサービス間のJSONは、真ん中のすべてがScalaオブジェクトになる場合、それはそれほど意味がありませんか？

私は基本的に、特にScalaを使用して、リレーショナルデータベースからオブジェクト/ドキュメントタイプのデータベースに移行した経験を求めています。SLICKの次のリリースでは、RDBMSとの良好な統合が約束されていることを私は知っています。したがって、TypeSafeのような会社がRDBMS統合をTypeSafeスタックの一部にすることを決定した場合、たとえばCasbahを使用してMongoDBに統合することで、上流に泳ぎますか？

この質問が少し曖昧に見える場合はお詫び申し上げます。しかし、適切な洞察や経験を持った人が助けてくれることを願っています。

アップデート：

SLICKへのリンクを追加しなかったことをお詫びします（かなり新しいです）。ここに行きます：

アップデート2：

テクノロジーに対する私の個人的な最初の勝利は、通常、開発者の生産性です。これは、軽量でシンプルなことを意味します。習得が速く、保守が簡単で、魔法がありません。

4

3 に答える 3

5

私は現在同様の状況にあり、Web開発とSQLデータベースの経験があるので、MongoDB、Cashbah（およびScalatra）と連携する機会として利用しました。私の経験はまだ非常に限られており、私が扱っているプロジェクトとデータの量はかなり少ないですが、ここに私が行ったいくつかの観察があります。

  • 私が持っているいくつかのデータセットでは、パフォーマンスがSQLまたはNoSQLのどちらにも動機付けられていないようです。ただし、大量のデータが存在する場合のパフォーマンスは、多くの場合、たとえばWikipediaによってNoSQLを使用する理由としてリストされています。

  • 私のドキュメント（データベース内のエントリ）は、テストスーツのベンチマークから作成され、主に静的な構造を持っており、固定スキーマSQLデータベースに格納できると楽観視しています。ただし、いくつかの下位構造は静的ではありません。たとえば、新しいテストケースが追加され、新しい統計が追跡され、その他は削除されます。これが、スキーマのないNoSQLデータベースを試す主な動機でした。また、MongoDBのドキュメントアプローチでは、データがさまざまなテーブルや行に分散されるリレーショナルデータベースのエントリとは対照的に、どのデータが一緒に属しているか（つまり、ドキュメントに属しているか）がはるかに明確になると感じたためです。 、および完全な「ドキュメント」を結合によって再構築する必要がある場合。

  • Tools such as Lift-Json or Rogue allow you to work with regular Scala objects in a type-safe, although the data is regularly (de-)serialised as (from) JSON. However, this naturally works best if the structure of your data is mainly static, otherwise, you you are left with using strings to access your data (e.g., for expanding the results of a query using Cashbah).



If you are mainly concerned about a coherent representation of data on server and client side, languages such as Opa or Haxe might be of interest, since they compile to code that can executed on both sides. See this page for "multitarget" or "tierless" languages.

于 2012-07-03T10:01:06.383 に答える
3

コメントが長くなりました。Scala での私の短い経験を関連付けようとしていました (Play2 が登場してから約 6 か月が経ちましたが、すぐに私のお気に入りの言語になりました)。

最近のいくつかのプロジェクトでは、MongoDB で Salat/Casbah を使用して楽しんできました。ほとんどは Play2 にありましたが、最新のものは webapp フレームワークなしでした。上流に泳いでいるような気分ではありません。

mongo を使用しない特定のユース ケースがあると思いますが、特に id またはインデックスでクエリを実行し、トランザクションを必要としない場合 (および必要になる場合)、汎用オブジェクト データ ストアとしてうまく機能します。最小限のアドホック集計タイプのもの)。

mongodb 専用の別のサーバー セットが必要になる (または mongodb 専用のサービスを使用する) ことが予想されますが、ほとんどの本格的なデータベース アプリではそれが普通だと思います。

私は Play2/Anorm も使用しました。これは、いくつかのアドホック クエリ ダッシュボード スタイルのレポート ページで使用するのが驚くほど楽しかったです。私は Squeryl ルートを試し始めましたが、1 回限りの集計クエリには Anorm の方が使いやすいように思えました。SLICK は見ていませんが、面白そうです。

于 2012-07-03T10:28:21.677 に答える
2

アプリでどのような問題を解決したいかを知らずに、言うのは本当に難しいです.

個人的には、REST/JSON 経由で NoSQL DB を使用して生産性が向上したことを発見しました。ただし、ほとんどの NoSQL DB は REST インターフェイスを提供しているため、UI を備えた Web アプリケーションを作成する場合を除き、多くのミドルウェア、Scala などを必要としません。

これが学習課題である場合は、複数のことを試してみることをお勧めします。NoSQL DB ごとにツールキットに提供できるものが異なり、CouchDB、Riak、Neo4j、および MongoDb にはすべてさまざまな長所と短所があり、さまざまな用途に適していることが個人的にわかっているからです。目的。

これが役に立てば幸いです。幸運を祈ります。

于 2012-07-04T05:09:09.323 に答える