2

たとえば、2つのデータの平和があり、一方の値がもう一方の値なしで使用されることはめったにない場合を考えてみます。一例として、ユーザー認証データを保持するテーブルを次に示します。

CREATE TABLE users
(
id INT PRIMARY KEY, 
auth_name STRING,
auth_password STRING,
auth_password_salt STRING
)

パスワードはソルトなしでは意味がないと思います。逆もまた同様です。この方法でデータを表現するオプションもあります。

CREATE TABLE users
(
id INT PRIMARY KEY, 
auth_name STRING,
auth_secret STRING,
)

そして、にauth_secret、などの文字列を格納しますD5SDfsuuAedW:unguessable42

一般に、列を1つの区切られた列に結合する方が適切な状況はありますか?

全体として「より良い選択」になることは決してありませんが、(同じデータに対して)列を増やすことと列を減らすこと(同じデータの場合)にコスト(パフォーマンス、スペースなど)はありますか?私の動機は、誰かがこの種のことを提案したときに、よりよく理解し、それに対してより有能に議論できるようにすることです。


--編集例を変更しました...元の例は次のとおりです。

CREATE TABLE points
(
id INT PRIMARY KEY, 
x_coordinate INT,
y_coordinate INT,
z_coordinate INT
)

vs

CREATE TABLE points
(
id INT PRIMARY KEY,
position STRING
)

position、などの文字列を格納する7:3:15

4

3 に答える 3

3

これは、データを結合、クエリ、レポート、または集約する必要がない場合に行います。

言い換えれば、決して。それは悪いデータベース設計です。

第一正規形(NF1)は、属性を区別する必要があると述べています。これが基本的な要件です。

于 2013-02-23T15:07:10.123 に答える
2

この質問に対する唯一の可能な答えは決してです。区切られたデータを列に格納しないでください。これは、データを区切るために存在する列のポイント全体を無効にし、データベースが実行するように設計されていることを実行することを非常に困難にします。これは正規化の違反であるため、StackOverflowで数か月かけて修正を試みることになります。

これは絶対にしないでください。

しかし、「決して言わない」。

特定の、非常に限られた状況では、それは大丈夫です。大丈夫だと思い込まないでください

良い例は、Stack Overflow独自のPostsテーブルです。このテーブルには、すばやく読み取るためにタグが区切られた形式で格納されています。質問のタグは、編集されるよりもはるかに頻繁にデータベースから読み取られます。タグは別のテーブルPostTagsに保存され、更新されるとPostsに非正規化されます。

つまり、この方法でデータを非正規化できたとしても、そうしないでください。それを避けるために可能な限りすべてを試してください。何日も最適化していて、何かをより速く取得する唯一の方法が非正規化であるという状況に遭遇した場合、それは問題ありません。その列からデータを読み取るだけであり、データが最新の状態に保たれるようにするための2次プロセスがあることを確認してください。非正規化されたデータの更新が失敗した場合は、すべてをロールバックして、データの整合性を確保してください。

于 2013-02-23T15:56:43.107 に答える
1

重要なオプションを省略しました。適切なユーザー定義のデータ型を作成します。(PostgreSQLには長い間2スペースの固有のデータ型がありました。)

これらの実装はかなり異なります。

ただし、これらのプラットフォームの1つを使用する余裕がない場合があります。たとえば、ユーザー定義のデータ型をサポートしていないMySQLを使用する必要がある場合があります。

関係理論によると、データ型は任意に複雑になる可能性があります。それらは内部構造を持つことができます。内部構造を持つ最も一般的なデータ型は、「日付」型です。関係理論は、dbmsがそのようなデータ型で何をすることになっているのかを指定します。dbmsは次のいずれかである必要があります

  • 内部構造を完全に無視するか、
  • パーツを操作する機能を提供します。

日付の場合、すべてのSQLデータベース管理システムはパーツを操作するための関数を提供します。

MySQLの「7:3:15」のような3空間座標を格納する単一の列に対して適切な引数を作成できます。関係理論と一致させるには、dbmsが構造を無視し、単一の値「7:3:15」のみを返すようにします。パーツの操作はアプリケーションコードに任されています。

MySQLにそのようなものを実装する際の1つの問題は、MySQLがCHECK制約を強制しないことです。したがって、「wibble:frog:foo」のような値がデータベースに侵入するのを防ぐのは非常に困難です。

于 2013-02-23T15:47:15.823 に答える