タグ付けされた質問 「physical-design」

1
マルチテナントSQL Serverデータベースの複合主キー
ASP Web API、Entity Framework、およびSQL Server / Azureデータベースを使用して、マルチテナントアプリ(単一データベース、単一スキーマ)を構築しています。このアプリは、1000〜5000人の顧客が使用します。すべてのテーブルにはTenantId(Guid / UNIQUEIDENTIFIER)フィールドがあります。現在、私はId(Guid)という単一フィールドの主キーを使用しています。しかし、Idフィールドのみを使用することで、ユーザーから提供されたデータが正しいテナントからのものであるかどうかを確認する必要があります。たとえばSalesOrder、CustomerIdフィールドを持つテーブルがあります。ユーザーが販売注文を投稿/更新するたびにCustomerId、同じテナントからのものかどうかを確認する必要があります。各テナントに複数のコンセントがあるため、状況はさらに悪化します。次に、確認する必要がTenantIdありOutletIdます。これは本当にメンテナンスの悪夢であり、パフォーマンスに悪影響を及ぼします。 TenantIdとともに主キーに追加することを考えていIdます。また、おそらく追加OutletIdします。だから、主キーSalesOrder:テーブルになりますId、TenantIdとOutletId。このアプローチの欠点は何ですか?複合キーを使用すると、パフォーマンスが大幅に低下しますか?複合キーの順序は重要ですか?私の問題に対するより良い解決策はありますか?

2
テーブルから最後の行をフェッチする最も速い方法は何ですか?
次Pricesの列を持つPostgreSQLテーブルがあります。 price (10進数) product_id (整数) 列もcreated_atありupdated_atます。 価格は定期的に更新され、古い価格はテーブルに保持します。特定の製品について、表の最後の価格は現在の価格です。 特定の製品の最終価格を取得する最も効率的な方法は何ですか。 product_id最後のレコードのインデックスとクエリ 3番目の列active(ブール)を追加して最新の価格をマークし、複合インデックスを作成します(product_idおよびactive) または、他の何か?

1
PostgreSQLはディスク上の新しいレコードを物理的にどのように配列しますか(主キーのクラスターの後)?
PostgreSQLがディスク上のレコードをどのように並べるかを知る必要があります。この場合、docsに記載されているインデックスの組み合わせを利用したいと思います。これは、ビットマップを使用して一致する行を取得し、物理的な場所に従ってそれらを返すことを理解しています。問題のテーブルは、主キーによってクラスター化されています。 私が理解しているように、PostgreSQLはクラスタリングが終了した後、自動的にクラスタリングを継続しません(ただし、特定のインデックスに従ってクラスタリングされたことを覚えています)。さて、これが主キーなので、物理的なストレージの順序はそれに従っているのでしょうか(これがtrueの場合は、特定のクエリに有利に使用したいと思います)。 要約すると、特にクラスタリングの後、PostgreSQLは新しいレコードをどのように順序付けますか? どうもありがとう!

2
charindex関数の長い文字列を分割/保存する最速の方法
1 TBの数字列があります。12文字の数字のシーケンスが与えられた場合、元の文字列(charindex関数)でこのシーケンスの開始位置を取得します。 SQL Serverを使用して1GBの文字列と9桁の部分文字列でこれをテストし、文字列をとして保存しましたvarchar(max)。Charindex10秒かかります。1 GBの文字列を900バイトのオーバーラップチャンクに分割し、バイナリ照合でchunkofstringを使用してテーブル(StartPositionOfChunk、Chunkofstring)を作成すると、インデックス作成に1秒未満かかります。10GB、10桁の部分文字列の後者の方法では、charindexが1.5分に上昇します。より高速な保存方法を見つけたいのですが。 例 数字列:0123456789-検索する部分文字列345 charindex( '345'、 '0123456789')は4を与えます 方法1:これを、1つの列で構成されるSQL Serverテーブルstrtableに格納しcolstr、実行できます。 select charindex('345',colstr) from strtable 方法2:または、元の文字列を分割することにより、テーブルstrtable2(pos、colstr1)を作成できます。2; 123 | 3; 234 asoそして、クエリを select pos from strtable2 where colstr1='345' 方法3:元の文字列をより大きなチャンクに分割することで、テーブルstrtable2(pos2、colstr2)を作成できます1; 01234 | 4; 34567 | 7、6789、次いで select pos2+charindex('345',colstr2) from strtable2 where colstr2 like '%345%' 最初の方法が最も遅いです。 2番目の方法では、データベースのストレージサイズが大きくなります。 方法3:バイナリ照合でcolstr2の長さを900バイトに設定し、この列にインデックスを作成すると、1GBの文字列と9桁の部分文字列の検索に1秒かかります。10GBの文字列と10桁の部分文字列の場合、istには90秒かかります。 これをより速くする他のアイデア(おそらく、文字列を使用することによって、文字列は長整数の数字で構成されます...)? 検索では常に、1 TBの数字列の12桁の部分文字列が検索されます。SQLServer 2017 …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.