Имеем два варианта связывания модели:

ЛИБО а)
1. Две связанных сущности -
МЕСТО(PK:PlaceID, PlaceName) и ОБОРУДОВАНИЕ(PK:HwID, HwName, FK:PlaceID)
2. Каждая запись в ОБОРУДОВАНИИ должна быть обязательно привязана(NOT NULL) к сущности МЕСТО,
по вторичному ключу PlaceID(NOT NULL)
3. При удалении записи в таблице МЕСТО, удаляются все связанные записи в таблице ОБОРУДОВАНИЕ
(DELETE CASCADE)

Плюсы: удобство в контроллере для управления сущностями в БД
Минусы: удаляются все! связанные с МЕСТОМ записи в таблице ОБОРУДОВАНИЕ (что неприемлемо)

ЛИБО б)
1. Две связанных сущности -
МЕСТО(PK:PlaceID, PlaceName) и ОБОРУДОВАНИЕ(PK:HwID, HwName, FK:PlaceID)
2. Каждая запись в ОБОРУДОВАНИИ может быть привязана(NOT NULL) или не может быть
привязана(NULL) к сущности МЕСТО, по вторичному ключу PlaceID(ALLOW NULL)
3. При удалении записи в таблице МЕСТО, необходимо сначала обнулить все связи (PlaceID)
с этим МЕСТОМ в таблице ОБОРУДОВАНИЕ

Плюсы: все связанные записи не удаляются (что необходимо)
Минусы: сложность написания кода обработчика в контроллере для обнуления всех связанных позиций,
нарушение соглашения EntityFramework, недостаток знаний по написанию такого кода

Вопрос:
Как решить данную проблему, какой вариант лучше использовать, что можно сделать?
Может быть нужно переделать модель и использовать промежуточную таблицу между ними?

можеть быть есть 3-й вариант, я прошу совета

Спасибо, я попробую использовать это

Где-то в степиakkolo-kakkolo,
кому они нужны, бесхозные записи оборудования
сделайте поле в таблице место - is_deletes признак что запись удалена
второе поле - date_out -время удаления записи
третье по настроению userid_delete - кто удалял запись.
так хоть у Вас целостность сохранится и история ..

Т.е. вы хотите сказать, что необходимо создать только видимость удаления записи для пользователя, а в таблице МЕСТО данные на самом деле будут оставаться на месте?

Хорошо, спасибо всем огромное!

А если, все же, мне когда-нибудь через лет 10-20 понадобится удалить пару десятков тысяч "удаленных" записей в таблице МЕСТО для экономии места на сервере, то в таком случае удалятся все связанные записи в таблице ОБОРУДОВАНИЕ, а записи об этом оборудовании мне еще понадобятся.

Где-то в степиakkolo-kakkolo,
как хотите, так и назовите, я бы мог предложить еще 2-3 варианта, но этот имхо лучше, вас первый не устраивает,
на второй что вы предлагаете встречный вопрос, а в чем профит тогда у вас в применении ограничения, в том что
ef авто сгенерирует поле оборудование, так вы и так можете убрать ограничение и генерировать в ручную ?

Сейчас меня первый вариант устраивает с применением IsDeleted.
Второй вариант меня смущает чисто по вопросу соглашений EF, что правильно программровать ТАК, а не СЯК