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

私は最近、多くのDBテーブルが作成されているプロジェクトを終了しました。 これらのテーブルのほとんどには一時的なゴミが含まれているので、これらすべてのテーブルを一覧表示する簡単な方法を探しています。 作成日に基づいてソートされたすべてのDBテーブルを一覧表示する方法はありますか？

12 postgresql  schema 

データベースがいくつかあるSQL Server 2012インスタンスがあります。それらの1つで、データベース以外のテーブルを選択するビューを作成しました。 ユーザーがそのビューを選択できるようにしたいのですが、そのテーブルを選択してはなりません。ユーザーがテーブルを選択できないため、ビューが作成されました。 /programming/368414/grant-select-on-a-view-not-base-tableおよびhttp://msdn.microsoft.com/en-us/library/ms188676を読みました。 aspx、それでも動作しません。 GRANT SELECT TABLE TO USERすべてのテーブルに対してaを実行すると、ユーザーはビューを選択できます。しかし、いずれかのテーブルを取り消すと、失敗します。 これは簡単な手順ですが、機能させるのに苦労しています。以前にそれが発生するのを見たことがありますが（インスタンスの所有者がビューへのアクセスを許可し、テーブルへのアクセスを許可しませんでした）、それを実行したり、方法を知っている人を見つけることができません。 誰かがそれを行う方法についてのチュートリアル、またはコード例を私に提供できますか？ ユーザーSELECTsがビューを受け取ると、次のメッセージが表示されます。 オブジェクト<TABLE>、データベース<DB>、スキーマに対するSELECT権限が拒否されましたdbo。 そのテーブルに選択を許可すると、エラーメッセージにより、テーブル名がビューが読み取る別のテーブルに変更されます。

11 sql-server  schema  permissions 

私の組織はSQL Server 2012可用性グループの採用を計画しており、それがアプリケーションのアップグレードプロセスに与える影響（ある場合）を理解しようとしています。 私たちは8週間のサイクルでアプリケーションの更新をリリースします。どのリリースにもスキーマの変更やデータの移行が含まれる可能性があります。 私が理解しようとしているのは、HA / DRソリューションがスキーマの変更を透過的に処理する（新しい列、インデックスがセカンダリに追加される）かどうか、または各インスタンスでスキーマを作成してからAlways Onをオンに戻すために手動で介入する必要があるかどうかです。 私が想定しているデータ移行の部分は透過的に処理されますが、それも確認したいと思います。 また、可用性グループの構成に基づいてこれらの動作に違いはなく、誤っている可能性もないと全面的に想定しています。私にお知らせください。 一言で言えば; アプリケーションの特定のリリースでは、非常に大きなテーブル（数千から数億のレコード）に列を追加することで、テーブルを変更できます。一部の列は「完全に新しい」ため、Enterprise Onlineのスキーマ変更機能を利用できます。他の列は既存の列のリファクタリングである可能性があり（FullNameはFirstNameとLastNameに分割されます）、これらのフィールドに入力するために、テーブルの各行に対して移行が実行されます。これらの動作のいずれかでは、DBAがAlwaysOn構成を変更する必要がありますか、それともデフォルトで処理され、すべてのセカンダリがDDLおよびDMLステートメントを「無料」で取得しますか？ あなたが提供できる明確さをありがとう。

11 sql-server  sql-server-2012  availability-groups  schema  high-availability 

これは馬鹿げた質問のように思えるかもしれませんが、私はスキーマ移行のためのオープンソースソリューション、つまりLiquibaseとFlywayを検討してきました。 ただし、上司から、SQL Serverデータツール（SSDT）でも同じことができると言われました。同意するかどうかはわかりませんが、インターネット上でLiquibaseやFlywayと直接比較するものはほとんどありません。 SSDTはSQL Serverの開発、データモデリング、および設計ツールであり、スキーマ比較（およびそのスクリプトの生成）とソース管理もサポートしていると私は考えています。スキーマ移行のいくつかの側面でLiquibase / Flywayと一部重複する可能性がありますが、別の問題に取り組みます。しかし、全体的なスキーマ移行ツールとして、LiquibaseとFlywayは完全に専用のツールですが、SSDTはデータベースの設計と開発に適しています。 比較がないと言うだけでSSDD自体はスキーマ移行ツールではないとしても、どんな意見でも大歓迎です。

11 schema  ssdt  migration 

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 | …

11 mysql  database-design  schema  eav 

私は自分のリーグではないデータベース設計の問題に出くわしました。そして、私の頼りになるDBAの第一人者が消防訓練に出かけています。 本質的に、私は次の主キー（簡潔にするためにPK）を持つテーブルを持っています。 child_id integer parent_id integer date datetime child_idそして、parent_idエンティティテーブルへの外部キーです。「子」テーブル自体にも「親」テーブルへの外部キーが含まれています。loはそれぞれ、child_id常にparent_id上記のテーブルで想定されているものと同じものを参照します。実際、この2つを同期させるための追加のコードがあることがわかります。 これにより、この熱狂的な正規化の初心者は「代わりに冗長性を削除する必要があります！」と言います。 私は次のように分解します。 Table_1 PK: child_id integer date datetime Table_2 PK: parent_id integer date datetime Table_3: (already exists) child_id integer PRIMARY KEY parent_id integer FOREIGN KEY そして、これらの人たちを自然な方法で結合すると、元のテーブルが回復します。この5NFを作ったのは私の理解です。 しかし、今ではビジネスルールが隠されていることに気づきました。 通常、特定child_idのに関連付けられている日付は、対応するに関連付けられている日付のサブセットである必要がありますparent_id。最初のテーブルがこのルールを適用していることがわかります。 日付が大きくなりすぎるまで自由に表1に追加できるため、私の分解ではルールを適用しません。 これは私をここに導き、次の質問があります： この分解は5NFですか？私はそれが挿入異常を許可すると言うだろうが、また次のそれ自体、Wikiの例に従うように見えるこのガイドを。「私が強調したもの」というフレーズは、「3つの別個のレコードタイプからなる正規化された形式からすべての真の事実を再構築できる」という特別な休止を与えますTable_1。 この分解が気に入らないとしましょう（気に入らない）。テーブルとコードをそのままにしておくことが実際的な解決策であることを私は自由に認めます。しかし、理論的には、最初のテーブルから離れてビジネスルールを保持するように制約を分解または追加する方法はありますか？

10 database-design  schema  normalization  relational-theory  best-practices 

私が取り組んでいるプロジェクトでは、さらに監査またはロールバックするために、データベースの一部のテーブルの行に対するすべての変更を追跡する必要があります。その行を誰がどのIPアドレスからいつ変更したかを簡単に見つけ、以前のバージョンを復元できる必要があります。 同様のものが、たとえばStack Exchangeでも使用されています。他の人の質問を変更すると、自分が変更したことがわかり、変更をロールバックできます。 現在のスキーマが平均的なビジネスアプリとほとんど同じプロパティ（以下）を持っている場合、オブジェクトのすべての変更をデータベースに格納するために使用される一般的な手法は何ですか？ オブジェクトのサイズは比較的小さいです。nvarchar(1000)たとえば、バイナリデータの巨大なblobはなくても、ディスクに直接保存され、Microsoft SQL ではなく直接アクセスされる場合がありますfilestream。 データベースの負荷はかなり低く、データベース全体はサーバー上の1つの仮想マシンによって処理されます。 以前のバージョンへのアクセスは、最新バージョンへのアクセスほど高速である必要はありませんが、それでも最新の状態¹であり、遅すぎない必要があります²。 <tl-dr> 次のようなケースを考えましたが、そういうシナリオはあまり経験がないので、他の人の意見を聞いてみました。 IDとバージョンで行を区別して、すべてを同じテーブルに格納します。IMO、それは深刻な愚かであり、パフォーマンスレベルで遅かれ早かれ傷つけるでしょう。このアプローチでは、最新のアイテムとバージョントレースに異なるセキュリティレベルを設定することも不可能です。最後に、すべてのクエリを記述するのはより複雑になります。実際、最新のデータにアクセスするには、IDですべてをグループ化し、各グループで最後のバージョンを取得する必要があります。 1つのテーブルに最新バージョンを保存し、変更のたびに、古いバージョンを別のスキーマの別のテーブルにコピーします。欠点は、変更されていなくても、常にすべての値を保存することです。変更された値をに設定することnullは解決策ではありません。値がに、nullまたはに変更されたときにも追跡する必要があるためnullです。 最新バージョンを1つのテーブルに保存し、変更されたプロパティのリストと以前の値を別のテーブルに保存します。これは、二つの傷のようだ：最も重要なのは同じ列に以前の値の異質なタイプをソートする唯一の方法は持っているということですbinary(max)。2つ目は、以前のバージョンをユーザーに表示するときに、このような構造を使用するのがより困難になると私は考えています。 前の2つのポイントと同じことを行いますが、バージョンを別のデータベースに保存します。パフォーマンスに関しては、同じデータベースに以前のバージョンを置くことで最新バージョンへのアクセスが遅くなるのを避けるために興味深いかもしれません。それでも、これは時期尚早の最適化であり、同じデータベースに古いバージョンと最新のバージョンを置くことがボトルネックであるという証拠がある場合にのみ実行する必要があると思います。 </ tl-dr> ¹たとえば、HTTPログの場合と同様に、ログファイルに変更を保存し、サーバーの負荷が最も低い夜間にログからデータベースにデータをフラッシュすることはできません。異なるバージョンに関する情報は、すぐに、またはほぼすぐに入手できる必要があります。数秒の遅延は許容範囲です。 ²情報へのアクセスはそれほど頻繁ではなく、特定のユーザーグループのみがアクセスしますが、バージョンのリストが表示されるまで30秒間待つように強制することはできません。この場合も、数秒の遅延は許容されます。

10 sql-server  sql-server-2008  schema  optimization 

私はアプリケーションを持っています（データはPostgreSQLに格納されています）。テーブルのフィールドの大部分は常にnullではありませんが、これらのテーブルのスキーマはこれを強制しません。たとえば、次の偽のテーブルを見てください。 CREATE TABLE "tbl" ( "id" serial, "name" varchar(40), "num" int, "time" timestamp PRIMARY KEY ("id"), UNIQUE ("id") ); またname、num、time明示的として記載されていないNOT NULL彼らが実際に執行はアプリケーション側で起こるので、。 私の感覚では、それを変更する必要があると感じていますが、反対に、アプリケーションレベルでは、null値がここに表示されないようにし、他の誰も手動でテーブルを変更しないようにします。 私の質問は次のとおりです。明示的なNOT NULL制約？ 私たちは適切なコードレビュープロセスと適度に優れたドキュメントを持っているので、新しい人がこの制約を破る何かをコミットする可能性は、変更を正当化するには実際には十分ではありません。 これは私の決定ではないので、これがまさに私が他の正当化を求めている理由です。私の意見では、何かがnullになり得ず、データベースで何かがnullでないことを指定できる場合、それを行うだけです。特に変更が非常に簡単な場合。

10 postgresql  schema  null 

問題 注：PostgreSQLのシーケンスメカニズムではなく、数学的なシーケンスを参照しています。 整数のシーケンスを表すテーブルがあります。定義は次のとおりです。 CREATE TABLE sequences ( id serial NOT NULL, title character varying(255) NOT NULL, date date NOT NULL, sequence integer[] NOT NULL, CONSTRAINT "PRIM_KEY_SEQUENCES" PRIMARY KEY (id) ); 私の目標は、指定されたサブシーケンスを使用して行を見つけることです。つまり、sequenceフィールドが指定されたサブシーケンスを含むシーケンスである行（私の場合、シーケンスは順序付けされています）。 例 テーブルに次のデータが含まれているとします。 +----+-------+------------+-------------------------------+ | id | title | date | sequence | +----+-------+------------+-------------------------------+ | 1 | BG703 | 2004-12-24 …

9 postgresql  performance  schema  array 

さまざまな種類の活動をサイトに関連付けるアプリケーションを継承しました。アクティビティタイプはおよそ100種類あり、それぞれに3〜10個のフィールドの異なるセットがあります。ただし、すべてのアクティビティには、少なくとも1つの日付フィールド（日付、開始日、終了日、予定された開始日などの任意の組み合わせ）と、1つの担当者フィールドがあります。他のすべてのフィールドは大きく異なり、開始日フィールドは必ずしも「開始日」と呼ばれるわけではありません。 アクティビティタイプごとに1つのサブタイプテーブルを作成すると、スキーマが100の異なるサブタイプテーブルになり、扱いにくいので扱いにくくなります。この問題の現在の解決策は、アクティビティ値をキーと値のペアとして保存することです。これは、ポイントを理解するために、現在のシステムを大幅に簡略化したスキーマです。 各アクティビティには複数のActivityFieldsがあります。各サイトには複数のアクティビティがあり、SiteActivityDataテーブルには各SiteActivityのKVPが格納されます。 これにより、（Webベースの）アプリケーションのコーディングが非常に簡単になります。必要なのは、特定のアクティビティのSiteActivityDataのレコードをループし、各行のラベルと入力コントロールをフォームに追加することだけです。しかし、多くの問題があります： 整合性は悪いです。アクティビティタイプに属さないフィールドをSiteActivityDataに配置することは可能です。DataValueはvarcharフィールドであるため、数値と日付を常にキャストする必要があります。 このデータのレポートとアドホッククエリは難しく、エラーが発生しやすく、低速です。たとえば、指定された範囲内の終了日を持つ特定のタイプのすべてのアクティビティのリストを取得するには、ピボットとvarcharを日付にキャストする必要があります。レポートの執筆者たちはこのスキーマを憎んでおり、私は彼らを責めません。 だから私が探しているのは、レポートが簡単になるような方法で、共通のフィールドがほとんどない多数のアクティビティを保存する方法です。これまでに思いついたのは、XMLを使用して疑似非SQL形式でアクティビティデータを格納することです。 Activityテーブルには、各アクティビティのXSDが含まれるため、ActivityFieldテーブルは不要になります。SiteActivityにはキーと値のXMLが含まれるため、サイトの各アクティビティは1行に表示されます。 アクティビティは次のようになります（ただし、完全に具体化していません）。 <SomeActivityType> <SomeDateField type="StartDate">2000-01-01</SomeDateField> <AnotherDateField type="EndDate">2011-01-01</AnotherDateField> <EmployeeId type="ResponsiblePerson">1234</EmployeeId> <SomeTextField>blah blah</SomeTextField> ... 利点： XSDはXMLを検証し、データベースレベルで数値フィールドに文字列を入力するなどのエラーをキャッチします。これは、すべてをvarcharに格納していた古いスキーマでは不可能でした。 Webフォームの構築に使用されるKVPのレコードセットは、 select ... from ActivityXML.nodes('/SomeActivityType/*') as T(r) XMLのxpathサブクエリを使用して、ピボットを使用せずに、開始日、終了日などの列を持つ結果セットを作成できます。 select ActivityXML.value('.[@type=StartDate]', 'datetime') as StartDate, ActivityXML.value('.[@type=EndDate]', 'datetime') as EndDate from SiteActivity where... これは良い考えのように思えますか？このように多数の異なるプロパティセットを格納する他の方法は考えられません。既存のスキーマを保持し、データウェアハウスでクエリしやすいものに変換することも考えていましたが、スタースキーマを設計したことがなく、どこから始めればよいかわかりません。 追加の質問：XSDでを使用して日付データ型を持つタグを定義すると、xs:dateSQL Serverはそれを日付値としてインデックス付けしますか？日付でクエリを実行する場合、日付文字列を日付値にキャストし、インデックスを使用する可能性をなくす必要があるかどうか心配です。

9 database-design  sql-server-2012  schema  reporting 

次の場合の基本的なスキーマ設計を思い付かなければならないトレーニング演習として、単純なデータベース設計タスクを実行しています。 製品の親子階層があります（例：原材料>作業中>最終製品）。 注文は各レベルで行われます。 注文数は、次の6か月間、毎週のバケットで確認できます。 製品レベルごとに需要予測を行うことができます。 次の6か月以内の任意の週の需要予測を今日行うことができます。 需要予測は、次の6か月間の毎週のバケットに対して行われます。 需要予測は通常、階層の上位レベル（原材料または仕掛品レベル）で行われます。下位レベル（最終製品）に分解する必要があります。 需要予測を上位レベルから下位レベルに分解する方法は2つあります。 ユーザーは最終製品の割合分布を指定します。たとえば、作業中の予測は1000だとします。ユーザーは、バケット10の最終製品1に40％、最終製品2に60％が欲しいと言っています。次に、今から10週目（日曜日から土曜日）の予測値最終製品1の場合は400、最終製品2の場合は600になります。 ユーザーは、バケット5の最終製品に対する注文に従って分解するだけで、バケット5の最終製品1と2の注文はそれぞれ200と800であり、EP1の予測値は（（200/1000）* 100）％になります。 EP2の場合、「（作業中）」の予測の（（800/1000）* 100）％になります。 予測は次の6か月間、毎週バケットで表示可能であり、理想的な形式は次のとおりです。 product name | bucket number | week start date | week end date | forecast value | created_on PRODUCT_HIERARCHYテーブルは次のようになります。 id | name | parent_id __________________________________________ 1 | raw material | (null) 2 | work in …

9 oracle  database-design  schema  oracle-11g 

SQL Server 2008を使用して新しいリソースセットのスキーマを定義しています...この場合、各レコード（行など）はXMLフラグメントを格納する必要があります。時々; 頻繁ではありませんが; 要素と属性の値を見つけるには、XMLをクエリする必要があります。自分の考案に任せれば、xmlデータ型を使用する傾向がありますが、これは問題があると考えられています。それが私の質問につながります。 このシナリオを前提として、XML列にxmlを格納するか、varchar（MAX）列にXMLを格納するかを決定する際に考慮すべき要素は何ですか。 それが役立つ場合...ここにいくつかの追加の詳細があります： これらのフラグメントのスキーマ（XSDなど）の使用に関して決定は行われていません フラグメントのサイズは、小さいものから非常に大きいものまでさまざまです。 すべてのXMLは整形式です 1日の間に、最大3か月間必要なオンラインクエリサポートで最大10,000個のフラグメントが収集されます XMLに対するクエリは1日を通して発生しますが、このタイプの同時クエリがほとんどないため、軽いままです。

9 sql-server-2008  database-design  schema  datatypes  xml 

コード、ドキュメント、システム構成など、Gitでの作業のほとんどをバージョン管理しています。私の貴重な仕事はすべてテキストファイルとして保存されているので、私はそれを行うことができます。 また、Postgresデータベース用の多くのSQLスキーマを作成して処理しています。スキーマにはビュー、SQL関数が含まれており、Postgres関数はRプログラミング言語で（PL / Rを介して）作成します。 私と共同編集者が作成したチャンクスキーマをコピーして貼り付けようとしていましたが、忘れていました。コピーと過去のアクションは反復的でエラーが発生しやすくなります。 pg_dump / pg_restoreメソッドはコメントを失うため機能しません。 理想的には、現在のスキーマを1つまたは複数のファイルに抽出し、コメントを保持してバージョン管理を行うための方法が欲しいです。 コメント付きのスキーマをバージョン管理するためのベストプラクティスは何ですか？

9 postgresql  schema  version-control 

（PostgreSql 9.4に裏打ちされた）大規模なSAASアプリケーションの場合、300,000を超えるアカウントがあり（そして成長中）、アカウントごとにスキーマを使用してデータをパーティション分割することと、すべてのデータを1つのスキーマに入れ、外部キーを使用することの長所と短所は何ですか。クエリで分割しますか？ 以前、多くのスキーマを操作するときにpg_dumpが非常に遅くなっていましたが、それが今日のケースかどうかはわかりません。また、データベース構造の変更はすべてのスキーマで行う必要があることも認識しています。そしてプラス面では、スキーマをある物理サーバーから別の物理サーバーに移動するのは簡単です。また、スキーマをバックアップから復元することはもちろんです。データをそのようにパーティション分割することは理にかなっています。 それで、私が見逃している長所と短所は何ですか？

9 postgresql  database-design  schema  multi-tenant 

私はdbmsが初めてです。機能的な依存関係についての講義ビデオを見ました。しかし、機能的な依存関係がデータベース全体または特定のスキーマに対する制約であるかどうか、少し混乱していますか？

8 database-design  schema  dependencies