Здравствуйте. Помогите пожалуйста разобраться. В проектируемой базе есть таблица заказов и таблица юзеров. В каждой из них нужно хранить информацию об адресе. Юзер при регистрации в приложении указывает свой домашний адрес, а при формировании заказа может указать произвольный адрес либо оставить свой (он скопируется в новую запись заказа). Соответственно есть 2 варианта:

1. Хранить адреса как в таблице юзеров, так и в таблице заказов.
2. Вынести адреса в отдельную таблицу и связать их внешним ключом с юзерами и заказами.

В принципе 2й вариант выглядит логичнее т.к. адреса по сути отдельная сущность. Но я не уверен что это лучшее решение с токи зрения производительности. Таблица заказов в последствии будет огромной, а каждому заказу всегда будет соответствовать один адрес. В большинстве случаев адреса не будут использоваться в отрыве от заказов. То есть при каждом обращении к заказу будет джойнится таблица адресов. На сколько я понимаю любой джоин между таблицами ест больше ресурсов железа чем обращение к одной таблице, но с бОльшим количеством полей. Плюс вариант №2 добавляет некоторые неудобства при создании нового юзера или заказа, т.к. при сохранении регистрационной формы нужно сначала создать запись юзера/заказа, вернуть id новой записи для создания внешнего ключа и только потом делать новую запись в таблице адресов. Без особой необходимости не хотелось бы добавлять лишнюю логику в приложение.

Какой вариант на ваш взгляд лучше с точки зрения производительности? Буду благодарен за любую помощь.

Из того что знаю по опыту + то что нагуглил - все же запрос с join - это более ресурсоемкая операция чем простая выборка из таблицы. Поправьте если ошибаюсь. Желательно с ссылкой на ресурс с пояснением. Для общего развития так сказать.


Планируется статистика по районам города, реже по улицам, но всегда в контексте заказа ( будет браться период по размещению/закрытию или по другим полям заказа )


Думаю дублировать данные далеко не идеальный подход, но в данном случае, избегать этого не имеет особого смысла. Исходя из специфики задачи, заказов на один и тот же адрес будет немного, в худшем случае до 10 в год, в среднем 1-2. В целом не критично.


Я не совсем понял. То есть Вы предлагаете сформировать уникальный список из уже внесенных адресов (со всеми вытекающими преобразованиями структуры БД) и дать возможность юзеру выбирать из выпадающего списка, а если адреса в списке нет, то дать возможность внести новый адрес? С учетом того, что при внесении адрес детализируется как до квартиры, так и до дома в целом, то список получится огромный и неочевидный (например ул.Сидорова 8, кв.777 и просто ул.Сидорова 8 - будут два разных адреса). Скорее это запутает пользователя. Если идти по сложному пути и попытаться сформировать уникальный список адресов, то думаю что юзер должен всегда вносить адрес в ручную, а последующие проверки на уникальность делать уже после отправки формы и перед сохранением в базу.


...
Ты же не собираешься всерьёз анализировать свои доставки, группируя их по улицам?..

Аналитические отчеты планируются. По адресам в том числе, но как я писал выше - всегда в контексте заказа.


Вы правильно поняли мои опасения. Скорее всего я попытаюсь избежать формирования уникального справочника адресов т.к. это заметно усложнит задачу и может создать проблемы при внесении и изменении адресов. И соответственно соотношение адресов к заказам будет 1:1. В итоге при вынесении адреса в отдельную таблицу я получу только условную правильность структуры базы. Но при этом я буду вынужден при любом обращении к заказам каждый раз делать джойны к таблице адресов + все неудобства с этим связанные. Что касается адресов в таблице юзеров, то они аналогично не будут использоваться в отрыве от записи юзеров.
Я все же больше склоняюсь к первому варианту. Хоть он и не совсем "красивый", но больше отвечает моей задаче.



В программе будет вестись заказ разных услуг. Ремонт например. Чаще всего их будут заказывать на домашний адрес. А при желании пользователь сможет подписаться на рассылку в которой его будут информировать о разных событиях (в рамках предоставляемых услуг) проходящих по его адресу.