必要な REST API をオンラインで作成できるソフトウェアを作成しています。
たとえば、20 世紀の自動車モデル/メーカーのリストを共有する API を作成したい場合、色、モデル、メーカー、および「無制限」の他のフィールドなどのフィールドが必要になります。
登録されたユーザーは、「無制限」の量のデータを開示する「無制限」の量の API を作成できます (具体的には、フォーマットの行 od データ: id|color|model|manufacturer| など)。
問題は、この種のデータをどのように保存するかです。
フィード、行、列、値の4 つのテーブルを使用する実用的なモックアップを作成しました
しかし、これは次のことにつながります。
- 複雑な結合
- 一部の処理は PHP サイトで行う必要があるため、機能が制限されています。
- 追加の抽象化レイヤーの必要性
したがって、私の次のアイデアは、 myproject_dataのような別のデータベースを作成することです (必要に応じて水平方向に分割されます) 。
API を作成すると、適切な名前で myproject_data にテーブルが作成されます。
このソリューションは、データ (列、行、値、フィード) を使用可能なデータ (データが入力された適切にフォーマットされた行) に処理するために必要な抽象化レイヤーを排除します。
数百のテーブルを使用することで予想されるパフォーマンスの問題について懸念している限り、パフォーマンスの損失は、複雑な結合を使用し、数十万のレコードを持つ 4 つのテーブルのみを使用する場合ほど大きくないと思います。さらに、追加の抽象化レイヤーを排除します。
どう思いますか ？