タグ付けされた質問 「eav」

5
キー値のこのデータベーススキーマの名前はありますか?
慣れていると思われる形式(エンティティごとに1行、属性ごとに1列)からデータベースをリファクタリングしたクライアントからの日常的なデータフィードを処理します。 変更前:属性ごとに1列 ID Ht_cm wt_kg Age_yr ... 1 190 82 43 ... 2 170 60 22 ... 3 205 90 51 ... 後:すべての属性に1つの列 ID Metric Value 1 Ht_cm 190 1 Wt_kg 82 1 Age_yr 43 1 ... 2 Ht_cm 170 2 Wt_kg 60 2 Age_yr 22 2 ... 3 Ht_cm …

5
大きなテーブルでLEFT JOINを使用して非常に遅いSELECTを最適化する方法
私は何時間もグーグルで独学で解決策を探していましたが、運がありませんでした。ここではいくつかの同様の質問を見つけましたが、この場合は見つかりませんでした。 私のテーブル: 人(〜1000万行) 属性(場所、年齢、...) 人と属性の間のリンク(M:M)(〜40M行) フルダンプ〜280MB 状況:person_idいくつかの場所(location.attribute_value BETWEEN 3000 AND 7000)、性別(gender.attribute_value = 1)、生まれた年(bornyear.attribute_value BETWEEN 1980 AND 2000)、目の色(eyecolor.attribute_value IN (2,3))から すべての個人ID()を選択しようとしています。 これは私の魔女が3〜4 分かかったクエリです。最適化したい: SELECT person_id FROM person LEFT JOIN attribute location ON location.attribute_type_id = 1 AND location.person_id = person.person_id LEFT JOIN attribute gender ON gender.attribute_type_id = 2 AND gender.person_id = person.person_id …

2
スタースキーマデータウェアハウスの動的フィールドのEAVの代替
APIリクエストログを保存するために、大きなデータウェアハウスで動的なフィールドと値をサポートする必要があります。私のユーザーケースは、すべてのAPIリクエストクエリ文字列を保存し、将来それらに対してクエリを実行できるようにすることです(したがって、単なるストレージではなく、だから私は彼らのためにブロブを使用することはできません) 例えば http://example.com/?action=test&foo=abc&bar=def... すべてのfield => valueマッピングを保存する必要があります。つまり(action => test), (foo => abc), (bar => def)、フィールドは非常に動的であるため、私が見つけた唯一の解決策はEntity-Attribute-Valueを使用することですが、人々は非常に悪いデザインだと言い続けています。 それで、上記の私のユースケースを考えてください、EAVに適した代替物は何でしょうか? KAVを使用した現在のスキーマ テーブルrequests (id, timestamp, uri) 例(1, 149382220, '/') テーブルparams (request_id, key, value) 例(1, 'action', 'test'), (1, 'foo', 'abc'), (1, 'bar', 'def') 助言がありますか? 更新:AWS RedShiftでウェアハウスを実行します

3
複数のバリアント/属性を持つ製品のスキーマ設計?
MySQLを使用しています。このアイデアは、異なるコンセプトのshopifyに似ているため、ユーザーは複数のタイプのバリアントと属性を持つ独自の製品を追加します。 私が行ったすべての調査から、これは私にとって最も可能性の高い解決策のようであり、次のスキーマに何か問題があるかどうか疑問に思っています。 ありがとうございました Table: products ------------------------------ | ID | ProductName | |----------------------------| | 1 | Leather Wallet Case | | 2 | Jeans | | 3 | Power Bank | Table: products_variants ------------------------------- | ID | ProductId | ParentId | Variant | VariantName | SKU | StockTotal | WholeSalePrice | …

4
複数の異なる型である可能性のある値を格納する適切な方法
私が持っている回答のテーブルと質問表を。 回答のテーブルには、値を持っていますが、問題によっては、この値は以下のようになりbit、nvarcharまたはnumber(今のところ)。質問は、その意図した回答値の型がどうあるべきかという概念を持っています。 少なくとも数値を比較する必要があるため、これらのAnswer値をどこかで解析することが重要です。 もう少しコンテキストについては、質問と潜在的な回答(通常、テキストボックスタイプの入力に許可されているデータタイプ)は、ソートの調査で一部のユーザーによって提供されます。その後、指定された他のユーザーが回答を提供します。 私が検討したいくつかのオプションは次のとおりです。 A.目的のタイプに応じて異なる方法で解析されるXMLまたは文字列(質問で追跡されます) B. Answerテーブルを参照する(またはAnswerテーブルによって参照される)3つの個別のテーブル。意図されたタイプに基づいて結合されます。この場合、各質問の回答が1つだけになるように制約を設定する最善の方法、またはそれをアプリケーションに任せる必要があるかどうかはわかりません。 C.目的のタイプに基づいて取得できるAnswerテーブルの3つの個別の列。 私はこれらのアプローチの長所と短所、または私が考慮していなかった代替のアプローチについていくつかの情報を得ていただければ幸いです。

3
在庫アイテムにさまざまな属性がある場合の在庫データベース構造
エンタープライズハードウェア情報を格納するためのインベントリデータベースを構築しています。データベースがワークステーション、ラップトップ、スイッチ、ルーター、携帯電話などからの範囲を追跡するデバイス。デバイスのシリアル番号を主キーとして使用しています。私が抱えている問題は、これらのデバイスの他の属性がさまざまであり、他のデバイスに関係のないフィールドをインベントリテーブルに含めたくないということです。以下は、データベースの一部のERDへのリンクです(一部のFK関係は表示されていません)。たとえば、ワークステーションデバイスタイプのデバイスを電話テーブルに配置できないように設定しようとしています。これには、デバイスタイプまたはクラスを検証するために多くのトリガーを使用する必要があり、異なる属性を持つ異なるデバイスが追跡されるときはいつでも新しいテーブルが使用されます。 シリアル番号にマップできる属性テーブルの設定を調べましたが、デバイスタイプに適用されない属性をデバイスに割り当てることができます。たとえば、必要に応じて誰かがワークステーションに電話番号属性を割り当てることができます。 。このサイトで次のような構造の説明を見つけました。 この構造は、属性がすべて私が保存しているアイテムに適用できる場合に最適です。たとえば、データベースに携帯電話のみが格納されている場合、属性は、タッチスクリーン、トラックパッド、キーボード、4G、3Gなどです。その場合、それらはすべて電話に適用されます。データベースには、hostname、circuitType、phoneNumberなどの属性があり、特定のタイプのデバイスにのみ適用されます。 特定のデバイスタイプに適用される属性のみがそのタイプのデバイスに割り当てられるように設定します。このデータベースのセットアップ方法に関する提案はありますか?これが1対1の関係の適切な使用であるかどうか、またはこれを行うより良い方法があるかどうかはわかりません。お時間を割いていただき、誠にありがとうございます。 ここに私が読んだ他のスレッドのいくつかがあります。彼らは私にいくつかの良い洞察を与えました、しかし私は彼らが本当に適用するとは思いません: /programming/9335548/how-to-structure-database-for-inventory-of-unlike-items /programming/1249632/database-structure-for-items-with-varying-attributes /programming/5559587/product-inventory-with-multiple-attributes /programming/6613802/question-about-setting-up-inventory-database /programming/514111/how-to-best-represent-items-with-variable-of-attributes-in-a-database
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.