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

他のデータまたはデータ構造を説明するデータ。

4
データベース内のすべての列名をリストまたは検索するにはどうすればよいですか？
データベースにある列の名前の文字列を検索したい。 私はメンテナンスプロジェクトに取り組んでおり、扱っているデータベースの一部には150を超えるテーブルがあるため、これをすばやく行う方法を探しています。 おすすめは何ですか？
7
テーブルの完全な構造をコピーする
いくつかの方法を使用すると、テーブルのコピーを作成すると、インデックス、PK、FKなどが失われます。たとえば、SQL Serverでは次のように言えます。 select * into dbo.table2 from dbo.table1; これは、テーブルの単純なコピーです。すべてのインデックス/制約がありません。（バックアップを使用せずに）テーブル構造をコピーするにはどうすればよいですか？ 私は主にこれを手動で行うことを探していますが、それが不可能な場合は、任意の解決策を受け入れます。
1
SQL Server Management StudioでIntelliSenseキャッシュを強制的に更新するにはどうすればよいですか？
SSMSのIntelliSenseは、シャットダウンして再起動しない限り更新されません。SSMSセッションがアクティブなときにサーバーから切断して再接続しようとしましたが、機能しません。 再作成する手順： テーブルを作成する そのテーブルから何かを選択します SSMSの下に波線の赤い線が表示され、「無効なオブジェクト名」というヒントが表示されます クエリを実行する SSMSを再起動せずにIntelliSenseを強制的に更新するにはどうすればよいですか？
5
データベースにユニットを保存する最良の方法
何かの量を表す数百の列を持つ大規模な（SQLServer）データベースを継承しました。これらの値の単位（「ガロン」、「インチ」など）は、拡張プロパティのMS_Descriptionフィールドに格納されます。この情報を保存するより良い方法があるかどうか疑問に思っています。ドキュメンテーションの目的には適していると思いますが、このデータに基づいて堅牢な単位変換計算を行うことは困難です。この時点で、私は侵襲的な変更を行う準備ができていませんが、そうする機会を得た場合、この点で推奨されるベストプラクティスは何ですか？私の頭の上のオプションには、次のものがあります。 列名を含まれる単位に変更します（例： "TotalVolumeInGallons"。これにより、情報が少し入手しやすくなりますが、それでも私には弱いようです。） すべての「金額」列に対応する個別の「単位」列を追加します（この列はnvarcharであるか、単位変換の計算を容易にする個別の単位テーブルへの外部キーである可能性があります。多くの列は、データベースのサイズをかなり2倍にする可能性があります-ひどく冗長なデータです。） ユニット専用の拡張プロパティで新しいフィールドを作成します。（残念ながら、これがUnitsテーブルの外部キーになるとは思わない。） 私が見落としている別のアイデアはありますか？ 更新： @Todd Everettの答えを読んだ後、考えられる解決策が思いついたので、先に進んで自分の質問に答えます。（下記参照）
4
sys.databasesのいくつかの列の照合はどうなっていますか？
2005年から2012年までのさまざまなバージョンのSQL ServerにUNPIVOT含まれるさまざまな列でを実行しようとしていますsys.databases。 UNPIVOT次のエラーメッセージで失敗しています。 メッセージ8167、レベル16、状態1、行48 列「CompatibilityLevel」のタイプは、UNPIVOTリストで指定された他の列のタイプと競合します。 T-SQL： DECLARE @dbname SYSNAME; SET @dbname = DB_NAME(); SELECT [Database] = unpvt.DatabaseName , [Configuration Item] = unpvt.OptionName , [Configuration Value] = unpvt.OptionValue FROM ( SELECT DatabaseName = name , RecoveryModel = CONVERT(VARCHAR(50), d.recovery_model_desc) , CompatibilityLevel = CONVERT(VARCHAR(50), CASE d.[compatibility_level] WHEN 70 THEN 'SQL Server 7' …
2
指定された主キーに関連付けられた外部キーを見つける
特定のデータベースのどの列がPK / FK関係を介して結合されているかを確立する方法が必要です。特定のテーブルのPK / FK情報を返すには SELECT * FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE AS cu WHERE EXISTS ( SELECT tc.* FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS AS tc WHERE tc.CONSTRAINT_CATALOG = 'MyDatabase' AND tc.TABLE_NAME = 'MyTable' /*AND tc.CONSTRAINT_TYPE = 'PRIMARY KEY'*/ AND tc.CONSTRAINT_NAME = cu.CONSTRAINT_NAME); GO しかし、そのようなクエリから返されたPKの場合、関連付けられたFKを確立するにはどうすればよいですか（1つがある場合）。 参照されたテーブルは次の方法でも取得できます。 SELECT CONSTRAINT_NAME = name, FOREIGN_SCHEMA = OBJECT_SCHEMA_NAME(parent_object_id), FOREIGN_TABLE = OBJECT_NAME(parent_object_id), …
4
PostgreSQL 9.6の列の削除とCTEを使用したSQL関数への副作用
3列（A、B、Dなど）のテーブルがあり、新しい列を導入しなければならなかった場合、Dの現在の位置を置き換えるためにCと言います。次の方法を使用します。 CおよびD2として2つの新しい列を導入します。 Dの内容をD2にコピーします。 Dを削除します D2の名前をDに変更します。 新しい順序は、A、B、C、およびDです。 （これまでのところ）問題が発生しなかったため、これは正当な慣行だと思いました。 しかし、今日、同じテーブルでステートメントを実行する関数が次のエラーを返したときに問題に遭遇しました。 table row type and query-specified row type do not match そして次の詳細： Query provides a value for a dropped column at ordinal position 13 私はPostgreSQLを再起動して、こことここでVACUUM FULL提案されているように最後に関数を削除して再作成しようとしましたが、これらの解決策は機能しませんでした（システムテーブルが変更された状況に取り組むことを除いて）。 非常に小さなデータベースで作業する余裕があったので、エクスポートし、削除してから再インポートしました。これにより、機能に関する問題が修正されました。 ここに見られるように、システムテーブルを変更する（pg_attributeなどで手を汚す）ことによって、列の自然な順序をいじってはならないという事実を知っていました。 Postgresの列の自然な順序を変更することは可能ですか？ 私の関数によってスローされたエラーから判断すると、私のメソッドで列の順序をシフトすることもまたノーであることがわかりました。誰が私がやっていることも間違っている理由についていくつかの光を当てることができますか？ Postgresバージョンは9.6.0です。 関数は次のとおりです。 CREATE OR REPLACE FUNCTION "public"."__post_users" ("facebookid" text, "useremail" text, "username" text) …
2
複数のファイルのファイルグループに割り当て単位を含む正確なファイルを特定する方法はありますか？
どのデータベースファイルに、データベース内に存在するさまざまなHoBT（アラインされたものとアラインされていないもの）のどの割り当てユニットが含まれているかについて、詳細なビューを取得したいと考えていました。 ファイルグループごとに複数のデータファイルの作成を開始するまで、私が常に使用してきたクエリ（以下を参照）は役立ちました。 select SchemaName = sh.name, TableName = t.name, IndexName = i.name, PartitionNumber = p.partition_number, IndexID = i.index_id, IndexDataspaceID = i.data_space_id, AllocUnitDataspaceID = au.data_space_id, PartitionRows = p.rows from sys.allocation_units au join sys.partitions p on au.container_id = p.partition_id join sys.indexes i on i.object_id = p.object_id and i.index_id = p.index_id join sys.tables …
3
オープンソースのメタデータ管理ソリューションはありますか？[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、データベース管理者のStack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 オープンソースのメタデータ管理ソリューションはありますか？何百ものエンタープライズデータベースのデータベーススキーマ、テーブル、データ項目のメタデータの詳細を保持するメタデータリポジトリを作成したいと思います。 特に、データベースのスキーマデータを自動的にクエリして、テーブルに関連するメタデータの変更を追跡できるものに興味があります。すなわち、列のデータサイズの変更、追加されたテーブルと列など。
13 schema  metadata 
8
特定の列名を持つデータベース内のすべてのテーブルを検索するクエリを作成する方法
約100のテーブルを持つデータベースがあり、2つのテーブルから特定のデータを取得するために結合クエリを作成する必要があります。私はどちらかを知っていますが、もう一方は知りません。基本的に私は次のようなものが必要です： select <tables> from <database> where exists table.column name; これどうやってするの？
12 metadata 
2
DATALENGTHの合計がsys.allocation_unitsのテーブルサイズと一致しません
DATALENGTH()テーブル内のすべてのレコードのすべてのフィールドを合計すると、テーブルの合計サイズが得られるという印象を受けました。私は間違っていますか？ SELECT SUM(DATALENGTH(Field1)) + SUM(DATALENGTH(Field2)) + SUM(DATALENGTH(Field3)) TotalSizeInBytes FROM SomeTable WHERE X, Y, and Z are true 以下のクエリを使用して（オンラインから取得してテーブルサイズ、クラスター化インデックスのみを取得し、NCインデックスは含まない）、データベース内の特定のテーブルのサイズを取得しました。請求のために（部門に使用するスペースの量に応じて部門に請求します）、この表で各部門が使用したスペースの量を把握する必要があります。テーブル内の各グループを識別するクエリがあります。各グループがどれだけのスペースを使用しているかを知る必要があります。 1行あたりのスペースVARCHAR(MAX)は、テーブル内のフィールドが原因で大きく変動する可能性があるため、平均サイズ*部門の行の比率を取得することはできません。DATALENGTH()上記のアプローチを使用すると、以下のクエリで使用される合計スペースの85％しか取得できません。考え？ SELECT s.Name AS SchemaName, t.NAME AS TableName, p.rows AS RowCounts, (SUM(a.total_pages) * 8)/1024 AS TotalSpaceMB, (SUM(a.used_pages) * 8)/1024 AS UsedSpaceMB, ((SUM(a.total_pages) - SUM(a.used_pages)) * 8)/1024 AS UnusedSpaceMB FROM sys.tables t with …
1
レコードのメタデータを保存するためのベストプラクティス
個々のレコードのメタデータをデータベースに保存するためのベストプラクティスは何ですか？ データベース内の多くのテーブルの作成時刻や最終更新時刻などの一般的なメタデータを保存する必要があります。私はいくつかの異なる解決策を見つけました： メタデータをテーブルに直接保存します。 長所： メタデータはレコードに直接リンクされています メタデータを取得するために結合は必要ありません 短所： 多くの重複列が必要です（継承が使用されている場合を除く） メタデータとビジネスデータは分離されていません で一般的なメタデータテーブルを作成し、ソフト外部キーを使用してデータを正しいテーブルとレコードにリンクします。 長所： 列の重複なし メタデータはビジネスデータから分離されています 短所： メタデータとデータ間の直接リンクなし（FKは使用できません） 結合には追加の条件が必要です メタデータを必要とするテーブルごとに個別のメタデータテーブルを作成します。 長所： メタデータはレコードに直接リンクされています メタデータはビジネスデータから分離されています 短所： 追加のテーブルがたくさん必要です 多くの重複列が必要です（継承が使用されている場合を除く） ここで述べたものよりも多くのオプション、長所または短所はありますか？そして、このメタデータを保存するためのベストプラクティスは何ですか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.