Хорошая тема. Я провел некоторое время, размышляя над наиболее подходящей схемой, и пришел к выводу, что решение Квентина-Старина является лучшим, за исключением того, что я добавил поля start_date и end_date в его таблицу PersonAddress. Я также решил добавить заметки , активные и удаленные .
удалено предназначено для функции мягкого удаления, так как, я думаю, я не хочу терять следы предыдущих адресов, просто удаляя запись из соединительной таблицы. Я думаю, что это вполне разумно, и другие могут захотеть рассмотреть. Если этого не сделать, то можно было бы пересмотреть бумажные или электронные документы, чтобы попытаться отследить адресную информацию (чего лучше избегать).
примечания Я думаю, что это что-то вроде требования, но это может быть просто предпочтением. Я потратил время на упражнения по обратной засыпке, проверяя адреса в базах данных, и некоторые адреса могут быть очень расплывчатыми (например, адреса в сельской местности), что я считаю очень полезным, по крайней мере, разрешить хранить записи об этом адресе в адресе записи.
Одна вещь, о которой я хотел бы услышать мнения, - это уникальная индексация таблицы address (опять же, ссылаясь на таблицу с тем же именем в примере Квентина-Старина. Как вы думаете, она должна быть уникальной? индекс должен применяться принудительно (как составной индекс, предположительно для всех полей, не являющихся нулевыми / обязательными)? Это может показаться разумным, но все же может быть сложно остановить дублирование данных, несмотря на то, что почтовые индексы не всегда уникальны для одного свойства. если поля страны, провинции и города заполняются из справочных данных (которые они есть в моей модели), различия в правописании в адресных строках могут не совпадать. Единственным способом избежать этого может быть запуск одной или нескольких БД запросы из полей входящей формы, чтобы определить, был ли найден возможный дубликат. Еще одна мера безопасности - дать пользователю возможность выбрать адрес в базе данных, уже связанной с этим человеком, и использовать его для автоматического заполнения. Я думаю, что это может быть случаем, когда вы можете быть только чувственным и принять меры предосторожности, чтобы остановить дублирование, но просто примите, что это может (и, вероятно, произойдет) рано или поздно.
Другим очень важным аспектом этого для меня является будущее редактирование записей таблицы address . Допустим, у вас есть 2 человека в списке: -
11 Независимо от улицы
Какой бы город
Z1P C0D3
Не следует ли считать опасным разрешать присваивать одну и ту же запись таблицы address разным лицам (сотрудникам, компаниям)? Тогда, скажем, пользователь понимает, что один из этих людей живет на 111 Whither Street, и там есть опечатка. Если вы измените этот адрес, он изменит его для обеих сущностей. Я хотел бы избежать этого. Я бы предложил, чтобы модель в MVC (в моем случае, PHP Yii2) искала существующие записи address при создании нового адреса, известного как связанный с этим клиентом (SELECT * FROM address INNER ПРИСОЕДИНЯЙТЕСЬ к personaddress ON personaddress.address_id = address.id WHERE personaddress.person_id = {текущий человек редактируется ID}) и предоставьте пользователю возможность использовать эту запись (как было предложено выше).
Я чувствую, что связывание одного и того же адреса с несколькими различными объектами просто вызывает проблемы, так как это может быть в случае отказа последующего редактирования записи address (нецелесообразно) или риска того, что дальнейшее редактирование записи может повредить данные, относящиеся к другим объектам за пределами того, кто редактирует адрес запись.
Мне бы очень хотелось услышать мысли людей.