fedddК примеру: есть таблица "пользователь" и "аноним", а также таблица "заказ". Так вот заказ может сделать либо пользователь, либо аноним. Как лучше осуществить данную связь?


Через наследование. Связь при этом идёт на общего предка "пользователя" и "анонима".

fedddВижу такие варианты:

1) В таблице "заказ" есть два поля, одно указывает на таблицу "пользователь", другое на таблицу "аноним" в зависимости от того кто осуществил заказ(пользователь либо аноним) в одно поле записываем primary key в другое NULL

2) Создаётся отдельная таблица связей, в которой помимо ключа ещё три поля: ключ таблицы "заказ", ключ таблицы "пользователь", ключ таблицы "аноним". Поле заказ всегда установлено, а пользователь или аноним в зависимости от того кто осуществил заказ.

Как из вариантов лучше применить и правильно ли вобще с точки архитектуры такой подход с двумя таблицами?



Как бы второй вариант -- это вариант первого, N опциональных взаимоисключающих связей, но обобщённый на то, что у заказа может быть много владельцев заказа. Поскольку, как я полагаю, владельцев у заказа всё-таки быть не может больее одного, то
второй вариант неправильный.

Если же вообще о этом варианте, то тут недостаток в том, что то, что связи взаимоисключающие, и то, что одна из них должна обязательно быть, тебе придётся реализовывать логикой приложения (в лучшем случае -- триггерами и процедурами, в худшем -- вне СУБД).


fedddП.с.
В данном конкретном случае, лучше сделать таблицу "заказчик" с общими данными для "аноним" и "пользователь" в которой будет поле указывающее пользователь ли это или аноним и таблицу "профиль" в случае если это пользователь там будут хранитсяд анные пользователя.


Вот это как раз и есть наследование. Только пользователь и его профиль -- это одно и то же.
Важно как кодировать ключи. Ключи должны быть уникальны в одном дереве насделования.