In theory, the any database constraint is an inequality

E1 <= E2

where E1 and E2 are RA expressions involving database relations. In
logical programming terms the partial order <= is the familiar
implication symbol.

In practice, there is a lot of technical details to work out no matter
what approach would you take, being that constraint enforcement via
triggers or via ANSI SQL style assertions (implemeted as check
constraints on materialized views).

I suggest that any rule-engine technology that does not naturally
embrace databases would give you the most headache. There is a reason
why rule engines never being able to crawl out of their tiny niche and
enjoy wider adoption.

Stored procedures (or operators in general) and constraints are part of
relational design; not something that comes in addition, as a last resort.

I would suggest creating a little sub-language via subroutines for
validation for a given product or order. Example:

IF (anyOf("footware,halloween,product4625") Or allOf("shirts,coupon"))
And anyOf("discount4") THEN logError("Federal law 234X prohibits
type-4 discounts on these items per trade fight with France")

The end result will look like some kind of Boolean expression and/or
set-oriented language, perhaps with some string list parsing
capabilities. Whether it's possible to do this easily with SQL, I'd
have to look at your actual system.

This is in conjunction with a many-to-many table for product
classifications.

-T-

I would rephrase the question to ask if you've come up with a concrete
table design that can hold these options.  Are they hypothetical, or are
these the actual requirements for a real system?

The first looks like a cross-reference from products to products, no?
So that is easy enough to store.  An insert or update trigger that
queries the table and adds more lines (unless already present) should
not be that hard.

The second, if I am not mistaken, is identical to the first, except that
it requires the user's consent to purchase an additional item?
Otherwise it would be the same as the first one.  The trick would be
that it looks in their sales history to satisfy the behavior.  Again a
simple cross-reference table stores the rule, a small trigger implements it.

The third rule is again another cross-reference.  Maybe all three kinds
of rules are in the same table with a column to say the rule type.

The fourth rule is starting to sound like you're making this up, but I
don't know what business this is in and I've seen some strange ones, so
I suppose it must be real.  This looks superficially like a super-case
of rule 3.  Adding quantities to the cross reference causes rule 3 to
reduce to a case of this rule.

For the last one, one way or another you have to query quantities and
group by product category.  You can do it in a view, in SQL in a
trigger, or anywhere else.