問題タブ [schema-design]

Solrでは、stored = "true"のフィールドがスキーマにあり、そのフィールドに関連付けられているアナライザーを変更した場合、すべてのドキュメントのインデックスを再作成せずに、このフィールドだけを更新できますか？これは、元のデータソースに戻らずに、新しいアナライザーでフィールドの「保存された」値を使用して実行できますか？

少し前に作成した支払い管理システムをアップグレードしています。現在、受け入れることができる支払いタイプごとに1つのテーブルがあります。これは、このアップグレードによって軽減される1つのものに対してのみ支払うことができるように制限されています。私はそれをどのように設計すべきかについての提案を求めてきました、そして私はこれらの基本的な考えを持っています：

1. 支払いタイプごとに1つのテーブルがあり、それぞれにいくつかの共通の列があります。（現在の設計）
2. すべての支払いを、共通の列（タイプに関係なく支払いIDを統合する）をとる中央テーブルと調整し、その支払いタイプに固有の列を持つ別のテーブルと行IDを識別します。
3. すべての支払いタイプに対して1つのテーブルを用意し、特定のタイプに使用されていない列をnullにします。
4. 中央テーブルのアイデアを使用しますが、特殊な列をキー/値テーブルに格納します。

これに対する私の目標は、ばかばかしいほど遅くならないこと、可能な限り自己文書化すること、そして他の目標を維持しながら柔軟性を最大化することです。

各テーブルの列が重複しているため、1はあまり好きではありません。これは、すべての支払いタイプに機能を提供する基本クラスを継承する支払いタイプクラスを反映しています... ORMは逆ですか？

現在の設計と同じように「タイプセーフ」で自己文書化されているため、私は2に最も傾いています。ただし、1と同様に、新しい支払いタイプを追加するには、新しいテーブルを追加する必要があります。

「無駄なスペース」があるため、3は好きではありません。また、どの列がどの支払いタイプに使用されているかはすぐにはわかりません。ドキュメントはこれの苦痛をいくらか軽減することができますが、私の会社の内部ツールには、技術ドキュメントを保存/検索するための効果的な方法がありません。

私が4に対して与えられた議論は、新しい支払い方法を追加するときにデータベースを変更する必要性を軽減するだろうというものでしたが、明示性の欠如のために3よりもさらに悪い問題を抱えています。現在、データベースの変更は問題ではありませんが、将来的に顧客が自分のデータベースを保持できるようにすることを決定した場合、それはロジスティックの悪夢になる可能性があります。

ですから、もちろん私には偏見があります。誰かもっと良いアイデアがありますか？どのデザインが最適だと思いますか？どの基準に基づいて決定する必要がありますか？

SQLiteエンジンはテキスト列に格納するデータを切り捨てないため、スキーマを定義するときに列サイズを指定することに利点はありますか？誰もがこれを好むでしょうか：

これ以上：

なんで？

具体的でないことには利点がありますか？

私は、ユーザーが自分のネットワークから特定のトピックに関する質問を追跡できるようにするフォーラムのプロジェクトに取り組んでいます。

ユーザーのニュース フィード ウォールは、ユーザーのつながりによって投稿され、フォローされているトピックにタグ付けされた質問のみで構成されます。どのデータベースのデータモデルがそのようなアプリケーションに最も適しているか混乱しています。現在、Cassandra と MySQL のソリューションを検討しています。

Cassandra を研究した後、ネットワークからのすべての投稿を表示するシンプルなニュースフィードのデザインは、ユーザーからの投稿についてユーザーのすべてのフォロワーに高速書き込みを実行することにより、Cassandra を使用して簡単に設計できることに気付きました。しかし、「フォローされたトピック」の追加フィルターがある私のようなアプリケーションでは、Cassandra での適切なスキーマ設計に納得できませんでした。私が cassandra について少ししか理解していないために何かを見逃していたら、おそらく、このニュースフィードを Cassandra に実装する方法についての提案を手伝っていただけないでしょうか?

次のテーブルがあります。さまざまな種類の記事に関する情報を保持します。このための適切なスキーマを考え出すのに助けが必要です。

テーブルは次のとおりです。

テスト データの挿入:

この math_articles.title = 'フィボナッチ数列' は記事 'ピサのレオナルド' に言及しているので、私のプログラムは other_articles テーブルに次のデータを挿入します:

テーブル参照に関するスキーマの問題

テーブル other_articles.title = 'ピサのレオナルド' がテーブル math_articles.title = 'フィボナッチ数列' で参照されたので、次のように参照テーブルにこの参照を保存する必要がありました。

不明/参照テーブルへの挿入に問題があります

これらの参照を保存する最良の方法は何ですか?

参照テーブルスキーマに関する私の問題!

• article_from_table_name と article_to_table_name の 2 つの列のデータ型はテキストですが、データベース内の実際のテーブルです。
• from_id と to_id は、 from_id = article_from_table_name.id と to_id = article_to_table_name.id のように、予測テーブルの外部キーにする必要があります。スキーマでこれを定義する方法がわかりません。

• 記事 math_articles.title = 'フィボナッチ数列' を削除すると、参照テーブルも更新されます。何らかの "ON DELETE CASCADE" トリガーを使用する必要があることはわかっています。

  • よろしく

非常に単純なスキーマを持つMySQLデータベースがあります。parent、、テーブルchildがあります。access

parent4つのフィールドと。である主キーをvarchar除いてすべて（長さ16から512の範囲）である51のフィールドを格納します。主キーの他に、他の3つのフィールドにインデックスがあります。テーブルがそれを外部キーとして参照できるようにするための1つ。longtextbigintchild

childほとんどvarcharがいくつかのtextフィールドを持つ23のフィールドを格納します。フィールドは、それを親にリンクするvarchar(256)ための外部キーとして使用されます。ただし、外部キーフィールドの実際の内容はすべて60文字より短いと予想されます。

accesssには、主キーを構成するフィールドbigintとフィールドがあり、フィールドはそれをにリンクする外部キーです。varcharbigintparent

このaccessテーブルは、どのユーザーがからどのレコードにアクセスできるかを指定するために使用されますparent。任意のレコードにアクセスする必要がある複数のユーザーがいる可能性があります。

には約2e6行parent （したがってaccess）があり、には約2e7行がありchildます。編集：申し訳ありませんが、access5329840行があります。accessつまり、のすべての行に1つ以上の行がありparentます。

上記のスキーマは、MySQLへの移行を検討している古いFileMakerデータベースに基づいています。理想的ではないと思いますが、その理由はよくわかりません。

パラメータに応じて、クエリは高速またはかなり低速になります。bobしたがって、たとえば、にアクセスできるレコードが複数ある場合、次のクエリには1〜2秒かかります。bobただし、ユーザーがアクセスできるレコードがない場合（たとえば、呼び出されたユーザーがいない場合）、クエリには数分（たとえば、12分）かかりますbob。

EXPLAINクエリについて次のようになります。

それで、一致しないクエリを高速化する方法はありますか？これは、すべてにvarchar / textフィールドを使用することによって引き起こされる可能性がありますか？varchar（256）フィールドを外部キーとして使用すると、問題が発生しますか（上記のクエリでは使用されていませんが）？それとも、クエリのせいですか？

編集：私はちょうどテーブルPRIMARY KEY ("RecordID", "UserName")上のがに使用されていないことに気づきました。UserName列にインデックスを作成しましたが、問題が修正されたようです。誰かアドバイスがあれば、それでもありがたいです。accessSELECT ... FROM access WHERE UserName = 'blah'

の現在の出力EXPLAIN：

編集：@DRappの提案は大きな違いを生みます。access.UserNameのインデックスがある場合とない場合で、クエリは高速です。インデックスを削除して、なしでDRappのクエリを試してみると、STRAIGHT_JOIN再び遅くなります。

access.UserNameにインデックスがないDRappのクエリ：

上のインデックスを持つ同じクエリaccess.UserName：

access.UserNameインデックスがない場合とない場合の同じクエリSTRAIGHT_JOIN：

非常に小さくて単純なユースケースでMongoDBを最適に使用する方法を見つけようとしていますが、ドキュメントがやや混乱しています。私のドキュメントは、ユーザーが多くの電子メールを持つことができるという事実を表す必要があります。ドキュメントに従えば、最も明白で簡単な解決策は埋め込みを使用することです。問題は、電子メールアドレスの一意性を検証したい場合です。これは、埋め込みでは不可能です (もちろん、map/reduce を使用できますが、非常に悪い選択のようです)。

私は間違いなく、電子メールが独自のコレクションに値しないと感じていますが、明らかに埋め込みオブジェクトでは検証を行うことができません (もしそうなら、それが効率的であるとは本当に信じていません)。この状況でスキーマをどのように設計しますか?

複数の 1 対多の関係を持つ 1 つのテーブルをモデル化する最良の方法は何でしょうか。

上記のスキーマでは、Report に 1 行、Grant が 2 行、Donation が 12 含まれている場合、3 つを結合すると、デカルト積と 24 の結果セットが得られます。 24列にします。

カレシアン積を避けるためにこれをモデル化するより良い方法はありますか?

サンプルコード

更新 1 2011-03-07 15:20

これまでのフィードバックに乾杯します。このシナリオに追加するために、1 つのレポート テーブルから得られる 15 の他の 1 対多の関係もあります。これらのテーブルは、さまざまなビジネス上の理由からグループ化できません。

「マッチ」を格納するテーブルがあります。これらのマッチには、MatchId、TeamA、TeamB、Wager、Winner の列があります。

TeamA と TeamB が各チームのプレーヤーのリストを返せるようにしたいと考えています。数はそれぞれ任意である可能性がありますが、これは可能ですか、それとも実用的ですか? これを設計する他の方法は考えられません。これに対してより良いスキーマはありますか? プレーヤーは UserId になり、ユーザーはチームにバインドされません。チームは試合に関連するだけです。

編集: たとえば、プレーヤー A、B、C、D、E、F

マッチ 1: 3v3 ABC vs DEF

Match2: 3v3 DAB vs FEC

プレーヤーは特定の TeamId にバインドされるべきではありません。これは、試合のみに依存するためです。プレイヤーは、試合で望む誰とでもチームを組むことができます。

既存の成熟したスキーマがあり、それにいくつかの新しいProduct属性を追加する必要があります。たとえば、Products.Flavorがあり、Weight、Fragranceなどの新しい属性を追加する必要があります。Productsテーブルを拡大し続けるのではなく、他のいくつかのオプションを検討しています。1つ目は、任意の属性のプロパティバッグとなる新しいAttributesテーブルと、特定の製品の属性のマッピング（および値）を格納するProductsAttributesテーブルです。私が理解するようになったので、これはEntity-Attribute-Value（EAV）パターンです。もう1つのオプションは、属性と呼ばれるXMLタイプのProductsテーブルに新しい列を追加することです。ここでは、新しいテーブルを追加せずに、任意の製品インスタンスに属性を任意に追加できます。

各アプローチの長所/短所は何ですか？SQLServer2008とASP.NET4.0を使用しています。