問題タブ [schema]

Microsoft SQL Server 2005 以降のリレーショナル ストアから、次の方法でメタデータとスキーマ情報を取得できることを知っています。

• 情報_スキーマ
• オブジェクト カタログ ビュー

Microsoft Analysis Services でこれに相当するものは何ですか?

t4 と C# を使用してデータ アクセス レイヤーを作成しようとしています。どのデータベースにもアクセスできる DAL を提供できるようにしたいと考えています。私が抱えている問題は、スキーマ情報の一部にあります。列名やテーブル名などの情報を取得できますが、主キー フィールドの名前、主キー値などの他の情報も取得したいと考えています。これを行う最も効率的な方法は何ですか?

C# で DAL テンプレートを作成していますが、ODBC と OleDB を使用してスキーマ情報にアクセスする最も効率的な方法は何だろうと考えています。列、列の種類、および主キーの情報が必要です。

ありがとう

SQL 2000 データベースを SQL 2005 に移行する予定です。私は、2005 でさまざまな所有者/スキーマの下にテーブルやその他のオブジェクトを作成できることをよく知っています。

SQL 2000 ではそのような機能は実際にはありませんでした。そのため、複数のスキーマを作成/管理するためのガイドライン/ベスト プラクティスはどのようなものになるのだろうかと考えています。

すべてのオブジェクトに対して 1 つのスキーマを作成する必要がありますか? それらをどのように分割すればよいですか？

私は純粋なリレーショナル デザインが好きですが、データを格納するためのエンティティ/値メソッドが必要になる場合があります。特に、ユーザーが新しいタイプのデータを頻繁に作成する必要がある場合。

一部の商用ソフトウェアでは、EV テーブルを使用するのではなく、標準テーブルを動的に作成するのを見てきました。

明らかに、これはすべてを解決するソリューションではなく、定義できるデータの種類を制限した場合にのみ機能します。ただし、次の利点があります。

• モデルは明確に定義されています。スキーマを理解するためにスキーマを調査する必要はありません。
• テーブルはそのタイプのデータのデータのみを保持するため、パフォーマンスが向上します。したがって、明らかに無関係な行をクエリする必要はありません。
• 同様に、インデックスは、テーブルが定義するデータ型の値のみを保持するため、パフォーマンスが向上します。(つまり、EV モデルでは、インデックスが valueid,entityid の場合 - インデックスを分割しない限り、クエリとは関係のないエンティティの値を検索することになります)。

私にはこれは素晴らしいことのように思えますが、このアイデアを DBA に実行させると、歯を食いしばることになります。これは良い考えですか、落とし穴は何ですか、そして誰かがこれをやろうとしましたか?

ASP.NET メンバーシップ プロバイダー セキュリティ フレームワークを使用したいのですが、SQL Server スキーマを使用したいと考えています。したがって、aspnet_Membership などのテーブルを使用する代わりに、sec.Membership のようなテーブルを使用することをお勧めします。誰かがこれを試して動作させましたか?

テーブルの各フィールドの前に省略したテーブル名を付けていますか?

例：

それとも、フィールドに最小限の名前を付けますか?

両方を使用したことがある場合、長期的にどの形式が最も役に立ったと思いますか?

編集：この質問には明確な答えがないようで、双方に良い点があります。しかし、私はあまりにも長い間質問を開いたままにしていたので、1 つの回答を承認済みとしてマークする時が来たのかもしれません。したがって、私は最も投票数の多いものを承認済みとしてマークしています。

必要に応じてスキーマ検証を実行するために、イベント処理セットアップを備えたXMLReaderSettingsオブジェクトを使用してXMLReaderでXMLを解析しています。

ただし、エラーキャッチはXMLのレベルごとに1回だけ発生するようです。これは、そのレベルでの後続のエラーが無視されることを意味します。

エラーが発生するたびにエラー処理イベントを発生させる方法はありますか？

編集：私もXmlSchemaValidatorを試しましたが、これは失敗しました。タグの本文内の最初のエラーのみをキャッチしました。

既に使用されている XML 形式のスキーマを作成する必要があります。既存の XML は別のプログラムによって既に生成されており、より標準的な XML 形式を使用するために変更する必要があるすべての場所を追跡するのは難しいようです。

XML 構造に似た例を次に示します。

エラータグは同じレベルで再利用され、特定の項目の後に来ますが、他の項目の後に来ることに注意してください。関連するエラー/その他のタグのペアを xsd:sequence でラップしようとしましたが、まだ効果的に Unique Particle Attribution ルールを破っているため、うまくいきません。

これを行うことはできますか、それとも、このスキーマが検証されないことを他の開発者に知らせる必要がありますか?

.net と C# を使用して、スキーマに対して XML を検証する際に問題が発生しています。

ValidationEventHandler で XmlReaderSettings を使用しています。

ただし、これは、同じレベルの次のタグをチェックするのではなく、XML ファイル内の特定のレベルで最初のエラーが発生した後にエラーのキャッチを停止するように見えるため、基本的に XML ファイル内のすべてのタグをチェックするわけではありません。エラーが見つかったときにレベルをスキップします。

この種の検証に成功した人からアドバイスをもらいたいと思っていました。

どうもありがとう