質問

1行のみのデータベースにテーブルを置くことのポイント(ある場合)は何ですか?

注:テーブルに1つの行のみが存在する可能性については述べていませんが、開発者が意図的に常に1つの行のみを含むテーブルを作成する場合です。

編集:

売上税の例は良い例です。

いくつかのコードで、それぞれが1行だけの3種類の証明書(SSLなど)を含む3つの異なるテーブルを確認しているところを確認しました。これが1つの大きなテーブルにならない理由がわかりません。何かが足りないと思います。

役に立ちましたか?

解決

頻繁に変更せずに永続化する必要があるデータの名前と値のペアを保存するための構成テーブルを作成するように開発者に求められたとき、私はこのようなことを見てきました。彼は、各構成変数の列を持つ1行のテーブルを作成することになりました。私はそれが良いアイデアだとは言いませんが、開発者が彼の指示を与えた理由を確かに見ることができます。言うまでもなく、レビューに合格しませんでした。

  

いくつかのコードで、それぞれが1行だけの3種類の証明書(SSLなど)を含む3つの異なるテーブルを確認しているところを確認しました。これが1行にならない理由がわかりません。何かが足りないと思います。

知らない重要な詳細がない限り、これは良いデザインのようには聞こえません。同じ制約、同じ使用法、同じ構造を持つ3つの情報がある場合、99%の確率で同じテーブルに格納する必要があります。それは、テーブルが基本的に何のためにあるのかの大きな部分です。

他のヒント

いくつかの場合、必要なのは1行のみです。通常はシステム構成データです。たとえば、「現在の売上税率」。これは将来変更される可能性があるため、ハードコーディングするべきではありませんが、通常はいつでも必要なだけです。この種のデータは、クエリが計算で使用できるようにデータベースに存在する必要があります。

必ずしも悪い考えではありません。

どこかに保存したいグローバル状態(ブール値など)がある場合はどうなりますか?ストアドプロシージャがこの状態に簡単にアクセスできるようにしたいですか?

値の範囲が1つの値に制限されている主キーを持つテーブルを作成できます。

単一行はシングルトンクラスのようなものです。目的:他のプロセスを制御または管理する。

単一行テーブルは、クリティカルセクションまたは決定的オートマトン(行値に基づくディスパッチャの種類)として機能できます

会社に関する一貫性のあるデータを取得するために、表COMPANY_DESCRIPTIONで単一行をフルに使用します。会社の手紙と住所を完全に使用します。

VAT、日付、時刻などの実際の値を含めるために、単一行をフルに使用します。

データベースシステムが提供していない機能の一部をエミュレートすると便利な場合があります。たとえば、MySQLのシーケンスを考えています。

1行のテーブルを使用して、すべてのデータベースユーザー間で共有されるアプリケーションレベルの設定を保存できます。たとえば、「最大許可ユーザー」。

おもしろい...私も同じ質問をしました。単純な値を保存したいだけで、ストレージの唯一の方法がSQLサーバーである場合、それはほとんどあなたがしなければならないことです。これを行う必要がある場合、通常、複数の列と1つの行を持つテーブルを作成します。いくつかの商用製品がこれを行うのを見てきました。

過去に単一行テーブルを使用しました(あまり頻繁ではありません)。私たちの場合、このテーブルは、Webインターフェースを介して更新可能なシステム全体の構成値を格納するために使用されました。単純な名前/値テーブルのルートを行くこともできましたが、エンドクライアントは単一の行を優先しました。私は個人的に後者を好んでいましたが、特にこのテーブルが他のテーブルとの関係を持たない場合は、本当に好み次第です。

  

1行のみのデータベースにテーブルを置くことのポイント(ある場合)は何ですか?

リレーショナルデータベースは、物事をリレーションとして保存します:何らかのリレーションを満たすデータのタプルです。

これと同じ:" VAT this many percent は現在私の国で有効です。

この関係を満たすタプルが1つだけの場合、はい、テーブル内のタプルは1つだけです。

SQL は変数を保存できません。 1 要素で構成されるセットを保存できます。これは1行のテーブルです。

また、 SQL はセットベースの言語であり、一部の操作では、定数式を選択するなど、1行のみの偽のセットが必要です。

Oracle の何もないところから SELECT することはできません。 FROM 句が必要です。

Oracle には、1つの行と1つの列のみを含む擬似テーブル dual があります。

かつて、 2 行(以前は dual という名前でした)がありましたが、バージョンへの途中で2行目を失いました。 7

MySQL にもこの擬似テーブルがありますが、 MySQL FROM 句なしで選択を行うことができます。それでも、空の行セットが必要な場合に便利です。 SELECT 1 FROM dual WHERE NULL

  

一部のコードで、3つの異なる種類の証明書( SSL など)を含む3つの異なるテーブルを確認していますが、各テーブルには1行しかありません。これが1つの大きなテーブルにならない理由がわかりません。何かが足りないと思います。

それは、「すべてを持っているか失うか」のようなものかもしれません。シナリオ、3つの証明書すべてが同時に必要な場合:

SELECT  *
FROM    ssl1
CROSS JOIN
        ssl2
CROSS JOIN
        ssl3

証明書が欠落している場合、クエリ全体は何も返しません。

これがなぜ最良の解決策となるのか、本当にわかりません。 1行のテーブルにあるデータを含む何らかの種類の設定ファイルを用意する方が効率的です。データベースに接続して1つの行を照会するコストはより高くなります。ただし、これがデータベースロジックの何らかの設定になる場合。次に、これは、使用しているデータベースのタイプに応じて、もう少し意味があります。

この http:// githubには、まったく素晴らしいrails-settingsプラグインを使用しています。 com / Squeegy / rails-settings / tree / master

設定は本当に簡単で、素晴らしい構文を提供します:

  Settings.admin_password = 'supersecret'
  Settings.date_format    = '%m %d, %Y'
  Settings.cocktails      = ['Martini', 'Screwdriver', 'White Russian']
  Settings.foo            = 123

すべての設定のリストが必要ですか?

  Settings.all            # returns {'admin_password' => 'super_secret', 'date_format' => '%m %d, %Y'}

アプリの特定の設定のデフォルトを設定します。これにより、定義された設定がデータベースにない場合でも、指定された値で返されます。次のようにconfig / initializers / settings.rbに新しいファイルを作成します。

Settings.defaults[:some_setting] = 'footastic'

これの用途は、データベースの現在のバージョンを保存することです。

スキーマの変更のためにデータベースバージョンを保存している場合、データベース内に存在する必要があります。

現在、スキーマを分析し、それに応じて更新していますが、バージョン管理への移行を検討しています。誰かがより良いアイデアを持っていない限り。

vb.netとsql expressを使用しています

テーブルに挿入制約がない限り、バージョニングのタイムスタンプは悪い考えのように聞こえます。

データベースがアプリケーションである場合、ビジネスロジックを実装するストアドプロシージャで必要となる可能性のある構成データを保存するのにおそらく意味があります。

ファイルシステムを使用して情報を保存できるアプリケーションがある場合、ほとんどの開発者がはるかに精通していることを除いて、XMLまたはフラットファイルよりもデータベースを使用する利点はないと思いますファイルシステムにアクセスするよりも、SQLを使用してデータを保存および取得する場合。

私が継承したプロジェクトには、このように設定されたテーブルがありました。これは構成データ用であり、指定された理由は、非常に単純なクエリを作成したためです:

SELECT WidgetSize FROM ConfigTable
SELECT FooLength  FROM ConfigTable

大丈夫。一般化された構成テーブルに変換しました:

ID  Name  IntValue StringValue TextValue

これは私たちの目的を十分に果たしました。

CREATE TABLE VERSION (VERSION_STRING VARCHAR2(20 BYTE))

SQLiteデータベースの単一のデータを動的Webページのカウンターとして使用しました。これは、スレッドセーフ(正確にはプロセスセーフ)にするために考えられる最も簡単な方法です。しかし、それが良いアイデアかどうかはわかりません。

これらのシナリオに対処する最良の方法は、データベースをまったく使用せずに、構成ファイル(通常はXML)を使用するか、アプリケーションの起動時に読み取られる独自の構成ファイルを作成することだと思います。ファイルを読み込むコードを書くのに数分しかかかりません。

ここでの利点は、同じXML変数に誤って追加の値を追加する可能性がないことです。異なる入力をテストするために多くのコードを記述する必要がないため、テストに最適です。テキスト値に変更し、アプリケーションを再実行します。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top