sql >> データベース >  >> RDS >> Mysql

必要なデータベース構造のアドバイス

    まず、ユーザーインターフェース： ユーザーとして私は嫌い 厳密に階層化されたで編成されたカタログ内の製品を検索する 仕方。 「エキゾチック」な製品がどのサブサブサブサブカテゴリにあるのかを覚えていません。これにより、「有望な」カテゴリを探索して時間を無駄にし、（少なくとも私にとっては）カテゴリに分類されていることを発見します。 ）奇妙な方法。

    Kevin Peno 提案は良いアドバイスであり、 ファセットブラウジング として知られています。 。 MarciaBates として ドット爆弾の後：今回はWeb情報検索を正しく行う 、" ..ファセット分類は階層型分類であり、リレーショナルデータベースは階層型データベースです。.. "。

    本質的に、ファセット検索を使用すると、ユーザーは好みの「ファセット」からカタログを検索し、検索に沿って他のファセットを選択して情報をフィルタリングできます。タグシステムの通常の考え方とは異なり、これらのファセットの一部を階層的に整理することを妨げるものは何もないことに注意してください。

    ファセット検索とは何かをすばやく理解するために、 いくつかのデモ があります。 フラメンコ検索インターフェースプロジェクト-流れる検索インターフェース で探索する 。

    次に、アプリケーションロジック： マニトラ 提案は（私が理解しているように）良いアドバイスでもあります。つまり、nodesを分離します。 およびlinks 異なる関係にある木/グラフの。彼が「祖先テーブル」と呼んでいるもの（ただし、はるかに直感的な名前です）は、として知られています。有向非巡回グラフ（DAG）の推移閉包 （到達可能性の関係）。マニトラが言ったように、パフォーマンスを超えて、クエリを大幅に簡素化します。

    しかし 表示 をお勧めします このような「祖先テーブル」（推移閉包）の場合、更新はバッチジョブによる定期的なものではなく、リアルタイムで増分的に行われます。 グラフセットのクエリ言語：データモデリングの質問 。特に、グラフの推移閉包の維持を確認してください。 SQLで （.ps-追記）。

    製品とカテゴリの関係

    マニトラの最初のポイントも強調する価値があります。

    彼が言っているのは、製品とカテゴリーの間には多対多の関係があるということです。つまり、各商品は1つ以上のカテゴリに分類でき、各カテゴリには0個以上の商品が存在する可能性があります。

    与えられた関係変数（relvars）製品とカテゴリこのような関係は、たとえば、少なくとも属性P＃とC＃を持つrelvar PCとして表すことができます。つまり、対応する製品とカテゴリとの外部キー関係にある製品番号とカテゴリ番号（識別子）です。数字。

    これは、カテゴリの階層の管理を補完するものです。もちろん、これは単なるデザインスケッチです。

    SQLでのファセットブラウジングについて

    「ファセットブラウジング」を実装するための便利な概念は、リレーショナル除算 です。 、または、さらには、関係の比較 （リンクされたページの下部を参照してください）。つまりPC（Products-Categories）をユーザー（ファセットナビゲーション）から選択されたカテゴリの（成長する）リストで割ると、そのようなカテゴリの製品のみが取得されます（もちろん、カテゴリはではないと推定されます すべて相互に排他的です。そうでない場合、2つのカテゴリを選択すると、1つはゼロの製品を取得します。

    SQLベースのDBMSには通常、この演算子（分割と比較）がないため、それらを実装/説明する興味深い論文を以下に示します。

    など...

    ここでは詳しく説明しませんが、カテゴリ階層とファセットブラウジングの間の相互作用には特別な注意が必要です。

    「平坦性」に関する余談

    Pras によってリンクされている記事を簡単に確認しました。 、MySQLでの階層データの管理 、しかし私は序文のこれらの数行の後で読むのをやめました：

    関係の平坦性に対するこの主張がナンセンスである理由を理解する 、3次元デカルト座標系 の立方体を想像してください。 ：8つの座標（トリプレット）で識別されます。たとえば、P1（x1、y1、z1）、P2（x2、y2、z2）、...、P8（x8、y8、z8）[ここでは関係ありませんこれらの座標を制約して、実際に立方体を表すようにします]。

    次に、これらの座標（ポイント）のセットをリレーション変数に入れ、この変数にPointsという名前を付けます。 。 代表 Pointsの関係値 以下の表として：

    Points|  x |  y |  z |
=======+====+====+====+
       | x1 | y1 | z1 |
       +----+----+----+
       | x2 | y2 | z2 |
       +----+----+----+
       | .. | .. | .. |
       | .. | .. | .. |
       +----+----+----+
       | x8 | y8 | z8 |
       +----+----+----+

    この立方体は、表形式で表現するという単なる行為によって「平坦化」されているのでしょうか。関係（値）はその表形式の表現と同じものですか？

    関係変数は、n次元の離散空間内の点のセットを値として想定します。ここで、nは関係属性（「列」）の数です。 n次元の離散空間が「フラット」であるとはどういう意味ですか？上で書いたように、まったくナンセンスです。

    誤解しないでください。SQLは不適切に設計された言語であり、SQLベースのDBMSには特異性と欠点（NULL、冗長性など）、特に悪いもの、DBMS-as-がたくさんあります。ダムストアタイプ（参照制約なし、整合性制約なし、...）。しかし、それは、リレーショナルデータモデルの空想上の制限とは何の関係もありません。逆に、それらがそれから離れるほど、結果は悪化します。

    特に、リレーショナルデータモデルは、一度理解すれば、上記の公開された論文を参照して詳しく説明したように、階層やグラフでさえ、どのような構造でも問題なく表現できます。 SQLでさえ、その欠陥を理解すれば、より良いものを見逃す可能性があります。

    「入れ子集合モデル」について

    その記事 の残りの部分をざっと読みました。 そして、私はそのような論理的な設計に特に感銘を受けていません。それは、2つの異なるエンティティ、ノードを混乱させることを示唆しています。 およびリンク 、1つの関係にすると、これはおそらく厄介さを引き起こします。しかし、私はその設計をより徹底的に分析する傾向はありません。申し訳ありません。

    編集： Stephan Eggermontは、以下のコメントで、「フラットリストモデルは問題です。これは実装の抽象化であり、パフォーマンスの達成を困難にします。... "。

    さて、私のポイントは、正確には、次のとおりです。

    1. この「フラットリストモデル」はファンタジーです ：リレーションをテーブル（「フラットリスト」）としてレイアウト（表現）するからといって、リレーションが「フラットリスト」（「オブジェクト」とその表現は同じものではない）であることを意味するわけではありません。
    2. 論理表現（関係）と物理ストレージの詳細（水平または垂直の分解、圧縮、インデックス（ハッシュ、b +ツリー、rツリーなど）、クラスタリング、パーティショニングなど）は異なります。リレーショナルデータモデルのポイントの1つ（ RDM ）論理を「物理」モデルから切り離すことです（DBMSのユーザーと実装者の両方に利点があります）。
    3. パフォーマンスは、物理ストレージの詳細（実装）の直接的な結果であり、そうではありません 論理的表現の例（Eggermontのコメントは、論理的-物理的混乱 の典型的な例です。 。

    RDMモデルは、実装を制限しません。必要に応じて、タプルとリレーションを自由に実装できます。関係は必ずしもではありません ファイルとタプルは必ずしもではありません ファイルの記録。このような対応は、ばかげた直接画像の実装です。 。

    残念ながら、SQLベースのDBMS実装は 、あまりにも頻繁に、ダムの直接画像の実装は、さまざまなシナリオでパフォーマンスが低下します- OLAP / ETL これらの欠点をカバーする製品が存在します。

    これはゆっくりと変化しています。最終的にこの根本的な落とし穴を回避する商用およびフリーソフトウェア/オープンソースの実装があります：

    もちろん、要点はないです 「最適な」物理ストレージ設計が存在する必要がありますが、物理ストレージ設計はすべて、優れた宣言型言語によって抽象化できます。 関係代数/微積分に基づく（そしてSQLは悪い 例）またはより直接的に論理プログラミング言語（たとえば、Prologなど- "プロローグからSQLへのコンバーター 「質問」。優れたDBMSは、データアクセス統計（および/またはユーザーヒント）に基づいて、物理ストレージの設計をオンザフライで変更する必要があります。

    最後に、Eggermontのコメントで、「リレーショナルモデルはクラウドと普及者の間で圧迫されています。 「もう1つのナンセンスですが、ここで反論することはできません。このコメントはすでに長すぎます。



    1. 通常のajaxと長いポーリングの違い

    2. セーフモードでのmysqlの削除

    3. 高可用性のためにChamiloMySQLデータベースをデプロイする方法

    4. GUIを使用してMySQLWorkbenchでテーブルを作成する方法