JSON APIの従来のSQLの代わりにRethinkDBを選択するのに適していますか？

Question

私はWebアプリケーションのバックエンドを構築しています。それはフロントエンド用のAPIとして機能し、Pythonで書かれます（正確にはFlaskです）。

設計と実装に関するいくつかの決定をした後、私はデータベースの部分に行きました。そして、私は、NoSQLのデータストレージが、従来のSQLデータベースよりも私のプロジェクトに適しているかどうかを考え始めました。次に、データベースによって処理されるべき基本的な機能の説明と、どのタイプのストレージを選択すべきかに関して私が思い付く賛否両論のリストを示します。最後に、なぜ私が他のNoSQLデータストレージよりRethinkDBを考慮したかについてのいくつかの言葉。 Artist、Song、Suggestion、UserとUserArtists：

APIの基本的な機能

APIはいくつかのモデルで構成されています。

Userにいくつかの関連データを追加して、一部にArtistをリンクしたいと考えています。要求に応じてSongをArtistに追加し、またUserのSuggestionを生成します。ArtistとSongが含まれます。

おそらく最も重要な部分の一つはArtist sが定期的にUser S（ともArtist Sにリンクされるということですが、システムから削除することができます - ので、User Sからあまりにも - 彼らはいくつかの基準を満たしていない場合）。 Songも、Artistに動的に追加されます。これは、Userの固定セットがArtistでないことと、Artistの固定セットがSongであることを意味します。これらは常に更新されます。

賛否のNoSQLため

：

• 柔軟なスキーマ、以来ではないすべてのArtist FacebookIDまたはSong SoundcloudIDを持つことになります。
• JSON APIの場合、レコードがJSONとして保存されるというメリットがあります。
• 私はSongの数だと思いますが、特にSuggestionの方がかなり上がりますので、NoSQLはより良い仕事をします。 SQLため

：

• これは、固定されたスキーマは、モデル間の関係と便利になることがあります。
• FlaskはSQLAlchemyをサポートしており、モデルの定義に非常に役立ちます。 NoSQLのため

短所

：

• 関係は実装が困難であり、モデルのトランザクションなどを更新するコードのビットを必要とします。
• Flaskにはラッパーやモジュールがないため、データベース操作中にコードを読みやすくするためのラッパーを実装する必要があります。
  • 操作がかさばり、私はかどうかを確認し、スキーマを定義する必要があります。
  • 私は特にUserArtistの

  SQLため、私は私のレコードを格納する方法上の任意の確信を持っていませんカラムのデフォルト値の設定、デフォルトの割り当て、データの検証、トランザクションの開始/コミット - APIのようなシンプルなものではあまりにも面倒です。

なぜRethinkDBですか？

私は次の理由の私のAPIのためのNoSQLの可能な実装のためのRehinkDBを検討してきました：

• それは他のソリューションより簡単でより軽量になります。
• これは大きなプラスのネイティブPythonサポートを備えています。
• これは、モデル間に関係があるAPIで便利なテーブル結合などを実装しています。
• これはむしろ新しいもので、コミュニティからの示唆と愛がたくさんあります。また、データベースのやりとりを活用する新しいものを継続的に追加する意思もあります。

これらのすべてが考慮されて、私は上のいくつかの修正、NoSQLのか、SQLを2つに私のニーズのためのより多くのappropiate、ならびに任意の他のプロ/詐欺であるかどうかについて、そしてもちろんの任意のアドバイスを聞いて喜んでいるだろう私が正しく言及していない事柄。

Answer 1

私はRethinkDBで働いていますが、それはWeb開発者としての私の偏った答えです（少なくとも私ができるほど偏っていない）。

• 柔軟性のあるスキーマは、開発者の観点から（あなたの場合は）素晴らしいです。あなたが言ったように、PostgreSQLのようなものでは、サードパーティ（SoundCloud、Facebookなど）から引き出すすべてのデータをフォーマットする必要があります。本当に難しいことではありませんが、楽しいものではありません。

• テーブルを結合できることは、自然なやり方です（user/userArtist/artistなど）。ユーザーがアーティストを含むことができる構造を持つことはできますが、アーティストを検索する必要があるときや、それぞれのユーザーのリストを取得する必要があるときは、使いにくいものになります。

最初の点はNoSQLデータベースでよく見られることですが、JOIN操作はSQLデータベースのものです。 RethinkDBは世界各国の最高のものを提供するものとして見ることができます。

私はRethinkDBを使って開発することは簡単で、速く楽しいと信じています。それは私がウェブ開発者として探しているものです。

ただし、RethinkDBが提供しないトランザクションが1つあります。 アトミックの複数のテーブル（またはユーザー間でお金を振り分けなければならない場合など）の更新が必要な場合は、PostgreSQLのようなものを使うのがよいでしょう。複数のテーブルで更新が必要な場合は、RethinkDBがそれを処理できます。

あなたが言ったように、RethinkDBは新しいものですが、コミュニティは驚くべきものです。私たちはRethinkDBで、ユーザーについて多くのことを気にしています。

ご質問がありましたら、お返事ありがとうございます：）