In Oracle you can implement constraints against materialized views. Haven't tried this out myself but according to the following article it is possible to implement a constraint like the one wanted by MGS.

http://www.dbazine.com/oracle/or-articles/tropashko8

In SQL Server you can achieve a similar result with a user-defined function in a CHECK constraint:

CREATE FUNCTION dbo.fnc_t1_col_1 (@col_1 INT)

RETURNS BIT

WITH RETURNS NULL ON NULL INPUT

AS

BEGIN;

RETURN COALESCE((SELECT TOP (1) 1 FROM t1 WHERE col_1 = @col_1),0);

END;

GO

create table t2 (col_A int not null,

col_1 int not null CHECK (dbo.fnc_t1_col_1(col_1)=1));

This isn't a very good alternative to a foreign key because the constraint is only evaluated on INSERT and UPDATE OF t2. It won't stop DELETEs agains t1 even if they violate the intended constraint. A trigger or additional constraint on t1 would be needed to prevent that.

The support of the leading DBMSs for anything other than the most basic integrity constraints is truly abysmal. It is a long standing problem in the SQL world and I would speculate that the data quality failures as a result of not enforcing such constraints may well have cost our industry $millions over the years.

The authors of the SQL standards are partly to blame. For example they created something called a "FOREIGN KEY" constraint, which is not quite what the Relational Model calls a foreign key, adding the pointless restriction that it must match some unique constraint definition (not in fact a candidate key or even a super key but actually an ordered list of columns from a super key).