条件を追加した場合のテーブル設計について

新たに購入可否テーブルを作成し

で良いんじゃないでしょうか
王道ですね

もしくはDBに権限を残さずプログラム側のロジックで実装するか

既存の商品テーブルに購入者情報のフィールドを加えるのは悪手でしょう。購入者は増えたり減ったりするのではないですか？
商品＋購入者をキーをとしたテーブルで購入できる人はレコードがあれば良いと思います。煩雑さという点では、商品テーブルを拡張する方がいろいろ面倒そうです。

商品番号,商品名,価格
の商品番号は１品の為に付番され、販売されれば、二度と利用されることの無いコードですか？

JANコードでなければ、

商品番号,商品名,価格,取置顧客コード、手付金、有効期限

JANコードであれば

商品番号,商品名,価格,数量

手付販売、取置販売の場合でも、在庫引当するため、数量から減算し、他のテーブルに移管しましょう。

id,有効期限,商品番号,数量,取置顧客コード、手付金

入札条件は顧客側と商品側に

商品番号,条件１、条件２・・・
顧客コード、条件１、条件２・・・

マッチングアプリのようなもの？

私も「購入可否テーブルを作成する」が良いと考えます。
デフォルトが全員購入可能なのか全員購入不可なのかによりますが、一旦デフォルトは購入可能という要件であると仮定して進めます。
その際の設計方針ですが以下の案が考えられます。

• 購入不可テーブルにする
• JSONで保持する

デフォルトが全員購入不可なのであれば購入可能テーブル、購入可能ユーザーリストと読み替えてください。

購入不可テーブルにする

カラム

• 商品番号
• ユーザー名（ユーザーID？）

運用方法

注文不可にする場合

当該テーブルにレコード追加

注文可能にする場合

• レコードを追加しない
• レコードがある場合削除する

注文可否の確認

existsで検索する

JSONで保持する

商品番号に対してレコードは常に1件になるように設計します。

カラム

• 商品番号
• 購入不可ユーザーリスト（JSON型のカラムにする）

運用方法

注文不可にする場合

当該テーブルの購入不可ユーザーリストに追加

注文可能にする場合

当該テーブルの購入不可ユーザーリストから削除

注文可否の確認

• MySQLの場合
  • JSON_CONTAINSで検索
• PostgreSQLの場合
  • ->で検索
• その他：自分で調べてください
• アプリ側（プログラム側）でJSONパースして処理

こんにちは
Aさんは購入できてBさんは購入できないというのは、特に条件なく管理人がこいつは購入させないって考えて購入の可否を決めてるんでしょうか？
であればみなさん言っているように購入可否テーブル作成するのがいいと思います
が、別に何か条件(Aさんはプレミアム会員だから購入OKみたいな)があるなら、

• ユーザーと条件のテーブル
• 条件とその条件であれば購入可能な商品のテーブル
  が必要かなと感じます
  違ったらすみません