サイトで動的にテーブルを作成することは良い習慣ですか？
友人から、「静的」テーブルと「動的」テーブルがいくつかあるサイトを構築するように依頼されました。
実際、彼は、削除できないいくつかのテーブルと、サイトのユーザーから直接作成できる「動的」テーブルを必要に応じて用意したいと考えています。
I.E.ユーザーが現在のデータベースに存在しない「オプション」が必要な場合は、特定のニーズに合わせて新しいテーブルを作成します。
これは良い方法ではないと思います。テーブルにすべての可能なオプションのリストを用意し、各ユーザーにフラグを付ける方が良いと思います。
テーブルgarden(id, camellia, californa_poppy, azalea)には、庭に含めることができる3つの花の種を含む一般的な庭が含まれています
テーブルusers(id, username, some_user_infos, garden_id)には、一般的なユーザーとそのガーデンIDが含まれています。
テーブルusersのgarden_idの値が1で、テーブルgardenのID 1の行が(1, 1, 0, 1)の場合garden_id=1には、許可されたすべての花が含まれていますが、カリフォルニアパピーです。
これが私の考えです。
私の友人は、動的にテーブルを作成し、それらをユーザーに接続して新しい花を動的に定義する方が良いだろうと言っています。
すべての可能な花をgardenテーブルのフィールドとして用意し、私がやりたいようにフラグを立てた方がいいのではないでしょうか。
短い答え：一般に、テーブルと列を動的に作成することはお勧めしません。ただし、まれに特殊なケースが発生する場合があります。
長い答え：
ソリューションの次の問題で（少なくとも）実行できます。
- Garden_idはテーブル「users」にあるため、ユーザーは1つの庭園しか持つことができません。
- 花にさらに情報を追加する場合は、e。 g。色またはサイズごとに、花ごとに1つの列が必要です。
- Sql-queryを作成するには、すべての花の名前（列名）を知っている必要があります。
私があなたの要件を正しく理解している場合、これは交差点テーブルの場合です（花と庭の間の多くの関係に）。
多分これはあなたのニーズを解決します：
次のテーブルを作成します。
- 列「Id」、「Flower」を持つすべての可能な花を含むテーブル「Flowers」を作成します。花を説明する列を追加できます。 g。色、サイズ、...
- 列「Id」、「username」、...を含むテーブル「Users」を作成します。このテーブルにはユーザーのみが含まれ、彼の庭や花に関する情報は含まれていません。
- 列「Id」、「User_Id」を持つテーブル「Gardens」を作成します。庭を説明する列を追加できます。 g。サイズ。このテーブルには、庭に関する情報と、庭が属するユーザーが含まれます。しかし、庭の花に関する情報はありません。
- 列「Id」、「Garden_Id」、「Flower_Id」を持つテーブル「Garden_Flowers」を作成します。このテーブルには、どの花がどの庭にあるかという情報が含まれています。これには、追加情報が含まれる場合があります。 g。花が植えられたとき。
これで、新しい列やテーブルを追加する必要なく、テーブル「Flowers」に新しい花を追加できます。交差テーブル「Garden_Flowers」を使用して、どの花がどの庭にあるかを定義できます。 flower_idとgarden_idを使用して、花ごとに1つのレコードを挿入するだけです。
多くのヘルスケアアプリケーションには、ユーザー定義テーブルのオプションがあります。
これらには通常、特定のスキーマと名前のプレフィックスがあり、「コア」テーブルと区別できます。
これの理由のいくつかは、たとえば喫煙、長期失業などに関する情報を収集するために、さまざまな政府の命令が「突然」表示されるためです。
開発者はこれらを予測できないため、ユーザーが「テンプレート」を設計およびアクティブ化できるようにする必要があります。
それが良い考えかどうかは、ポイントの横にあります。説明は、詳細について気にしていない誰かからのものです。
はい。それで合っています。優先する方法は、リレーショナルデータベースの基本的な考え方と一致します。ユーザーがテーブルを作成または削除できるようにするアプリの設計は、かなり危険です。重要なテーブルが削除されたり、新しいテーブルによって上書きされたりしないようにするために（セキュリティ上の理由から）必要な追加の作業を考えてください。さらに、ユーザーがDDLコマンド（作成/ドロップなど）を実行できるようにするプログラムは、ハッキングまたはその他の破壊的/危険な結果の可能性を高めます。
プログラムの責任は、基礎となるデータベースの構造を抽象化/非表示にすることです。もちろん、データベース管理アプリを作成しているだけではありません。その場合、通常のユーザーではなく、管理者のみが使用する必要があります。