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

データベースにデータ整合性ルールを適用するチェックや外部キーなどの宣言的メカニズム。

3
フィールドを一意にすると、インデックスが作成されますか?
uniqueフィールドに制約を課す場合、スケーラブルな挿入時間を得るために、そのフィールドにインデックスを作成する必要もありますか?または、これは私のために行われますか? 具体的には、私はプロトタイピングのためにApache Derbyを使用していますが、おそらく近い将来にMySQLに移行する予定です。また、SQL標準にこれについて何かを述べている何かがあるといいのですが。 このフィールドで検索する必要がないので、役に立たないインデックスを作成したくありません。しかし、私はO(n)挿入時間よりも役に立たないインデックスが欲しいです。

2
複合外部キーに別の一意制約が必要なのはなぜですか?
以下は、レコードが同じテーブル内の親レコードを参照できる単純なテーブルです。 CREATE TABLE foo ( id SERIAL PRIMARY KEY, parent_id INT NULL, num INT NOT NULL, txt TEXT NULL, FOREIGN KEY (parent_id) REFERENCES foo(id) ); 他のフィールド値(num)の1つが親レコードと子レコードの間で同一でなければならないという追加の要件により、複合外部キーでうまくいくと思いました。最後の行を FOREIGN KEY (parent_id, num) REFERENCES foo(id, num) となったエラー:参照された表「foo」というのキーを与えられた一意の制約マッチングはありません。 この制約は簡単に追加できますが、参照される列(id)の1つが既に一意であることが保証されているのに、なぜ必要なのかわかりません。私の見たところ、新しい制約は冗長になります。

6
階層のあるテーブル:外部キーによる循環を防ぐための制約を作成します
次のように、テーブル自体に外部キー制約があるテーブルがあるとします。 CREATE TABLE Foo (FooId BIGINT PRIMARY KEY, ParentFooId BIGINT, FOREIGN KEY([ParentFooId]) REFERENCES Foo ([FooId]) ) INSERT INTO Foo (FooId, ParentFooId) VALUES (1, NULL), (2, 1), (3, 2) UPDATE Foo SET ParentFooId = 3 WHERE FooId = 1 このテーブルには次のレコードがあります。 FooId ParentFooId ----- ----------- 1 3 2 1 3 2 この種の設計が意味をなす場合(例:典型的な「従業員と上司と従業員」の関係)があり、いずれの場合も、スキーマにこれがある状況にあります。 …

3
インデックスと制約の一覧表示
継承したアプリケーションのSQL Serverデータベースを見ています。約10年間SQL Serverを調べていませんので、ご容赦ください。 私が調べているデータベーステーブルにはというbigint NOT NULL列がありますがid、制約を確認しても何も表示されず、すべてのデータベーステーブルに同じことが当てはまります。 これらのテーブルに主キーとインデックス(クラスター化または非クラスター化)がないと仮定しても正しいですか? 私は次のクエリを実行しましたが、結果は私の疑いを裏付けるように見えます。 //**returns 0** select count(*) from INFORMATION_SCHEMA.TABLE_CONSTRAINTS; //**returns no rows** select * from sys.indexes where object_id = (select object_id from sys.objects where name = 'NAME-OF-TABLE'); //**returns all tables in database** SELECT name FROM sys.tables WHERE OBJECTPROPERTY(object_id,'IsIndexed') = 0;

1
MySQL:大きな列に対する一意の制約
VARCHAR最大3071文字を保持できる列を含むInnoDBテーブルを作成しようとしています。UNIQUEこの列のデータに制約を課したいのですが。 MySQLはインデックスを使用して制約を強制しているようです。InnoDBでは、インデックスサイズは767バイトに制限されているように見えます- VARCHAR(3071)データを保持している列には十分ではありません。 最大データ長やInnoDBの使用に妥協することなく、データベースにデータの一意性を強制する方法についての考えはありますか?

2
Oracle USING INDEX句に相当するSQL Server
OracleのUSING INDEX句に相当するSQL Server 2008はありますか?具体的には、構成: CREATE TABLE c(c1 INT, c2 INT); CREATE INDEX ci ON c (c1, c2); ALTER TABLE c ADD CONSTRAINT cpk PRIMARY KEY (c1) USING INDEX ci; Sql Server Documentation on Unique Indexsには、次のように記載されています(強調を追加)。 一意のインデックスは、次の方法で実装されます。 PRIMARY KEYまたはUNIQUE制約 PRIMARY KEY制約を作成すると、テーブルにクラスター化インデックスがまだ存在せず、一意の非クラスター化インデックスを指定しない場合、列に一意のクラスター化インデックスが自動的に作成されます。主キー列はNULL値を許可できません。 これは、主キーに使用するインデックスを指定する方法があることを意味しているようです。

2
SQL Serverがインデックス付きビューの列がNULL可能ではないことを認識できるようにするにはどうすればよいですか?
SQL Server 2008で次のインデックス付きビューが定義されています(テスト目的でgistから作業スキーマをダウンロードできます)。 CREATE VIEW dbo.balances WITH SCHEMABINDING AS SELECT user_id , currency_id , SUM(transaction_amount) AS balance_amount , COUNT_BIG(*) AS transaction_count FROM dbo.transactions GROUP BY user_id , currency_id ; GO CREATE UNIQUE CLUSTERED INDEX UQ_balances_user_id_currency_id ON dbo.balances ( user_id , currency_id ); GO user_id、currency_id、およびtransaction_amountすべてのように定義されているNOT NULLの列dbo.transactions。ただし、Management Studioのオブジェクトエクスプローラーでビュー定義を見ると、ビューの両方の列balance_amountと-able列transaction_countとしてマークさNULLれています。 私はいくつかのディスカッションを調べましたが、これはそれらの中で最も関連性が高く、SQL Serverがビュー列が常にであることをSQL Serverが認識するのに役立つ可能性のある関数のシャッフルを示唆していますNOT NULL。ただし、インデックス付きビューでは集約関数の式(たとえば、ISNULL()over …

5
相互に排他的な多対多の関係
私はテーブル持っているcontainersいくつかのテーブルに多対多の関係を持つことができる、のは、それらがあるとしましょうplants、animalsとbacteria。各容器は、任意の数の植物、動物、または細菌を含むことができ、各植物、動物、または細菌は、任意の数の容器に入れることができる。 これまでのところ、これは非常に簡単ですが、私が問題を抱えているのは、各コンテナには同じタイプの要素のみを含める必要があるということです。たとえば、植物と動物の両方を含む混合コンテナは、データベースの制約違反になります。 これの私の元のスキーマは次のとおりでした: containers ---------- id ... ... containers_plants ----------------- container_id plant_id containers_animals ------------------ container_id animal_id containers_bacteria ------------------- container_id bacterium_id しかし、このスキーマでは、コンテナーを均一にする必要があるという制約を実装する方法を思いつきません。 これを参照整合性で実装し、データベースレベルでコンテナが同種であることを保証する方法はありますか? これにはPostgres 9.6を使用しています。

3
同じ制約とインデックスで新しいテーブルを作成するにはどうすればよいですか?
主キー制約とそのテーブルに非クラスター化インデックスを含む新しいテーブルを作成しています。 キーとインデックスだけでなく、同じ構造と値を持つ別のテーブルを作成したいのですが。 create table Dummy (id integer ,name varchar(20),salary integer Constraint PK_Con_id primary key(id)) insert into Dummy values(11,'AAA',1000); insert into Dummy values(12,'BBB',2000); insert into Dummy values(13,'CCC',3000); insert into Dummy values(14,'DDD',4000); select * from Dummy; create nonclustered index IX_Name on Dummy(Name) 現在、Dmyテーブルを作成していますがDmy、SQL Server 2008 R2のキーと制約がテーブルに反映されません。 SELECT * INTO Dmy FROM Dummy

2
トランザクション、参照、および複式簿記を実施する方法は?(PG)
複式簿記は すべてのトランザクションまたはイベントが少なくとも2つの異なる名目元帳勘定を変更する財務会計システムで財務情報を記録するための一連のルール。 アカウントは「借方」または「貸方」にすることができ、すべての貸方の合計は、すべての借方の合計と等しくなければなりません。 これをPostgresデータベースにどのように実装しますか?次のDDLを指定します。 CREATE TABLE accounts( account_id serial NOT NULL PRIMARY KEY, account_name varchar(64) NOT NULL ); CREATE TABLE transactions( transaction_id serial NOT NULL PRIMARY KEY, transaction_date date NOT NULL ); CREATE TABLE transactions_details( id serial8 NOT NULL PRIMARY KEY, transaction_id integer NOT NULL REFERENCES transactions (transaction_id) ON UPDATE …

3
SQLは列に許可された値を設定
ALTER TABLE新しい列を追加してデフォルト値を設定し、さらにその列に許可される値を定義する式を作成したいと思います。これはテキスト列であり、許可されているのは「value1」、「value2」、および「value3」のみです。デフォルトは 'value1'である必要があります 以下の構文図によると: 私はここまで来ています ALTER TABLE exampleTable ADD COLUMN new_column VarChar(20) DEFAULT 'value1' しかし、私は許可された値を設定する方法が絶対にわかりません。 何かのように作ることは可能ですか CONSTRAINT CHECK new_column IN( '値1'、 '値2'、 '値3) ?search conditionダイアグラムは私をかなり混乱させることを認めなければなりません。

1
SQL Serverで非主キーとの関係をどのように作成しますか?
私は、UserIDと呼ばれる主キーとUserNameと呼ばれる別の列の2つの列を持つUsersテーブルを持っています。 UserID(int)PK ユーザー名(varchar(256) どちらも一意ですが、他のテーブルの参照としてUserNameを使用する理由を考えました。たとえば、注文テーブルには、useridではなくUserNameによるuserへの参照があります。 OrderID ユーザー名 SQL Serverのカスケード更新/削除機能を利用できるように、UserNameとUsersテーブルを参照するすべてのテーブル間にリレーションシップを作成します。 しかし、SQL Serverでは、主キー以外の列に関係を作成できません。ユーザーテーブルを変更せずにカスケード更新/削除機能を取得して、UserNameをUserIDではなく主キーにする方法はありますか?

6
一意のインデックスの最大16列を回避する方法
CREATE INDEXドキュメントによると: 最大16列を単一の複合インデックスキーに組み合わせることができます。 一意の組み合わせを形成する必要がある〜18列のテーブルがあります。このテーブルはパフォーマンスの影響を受けません -値を更新したりレコードを挿入したりすることはほとんどありません。レコードが重複しないようにする必要があるだけです。単純な一意性の制約を課すことができると考えました。 何か案は?より良い方法がある場合は、一意のインデックス/制約を完全に回避することにオープンです。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.