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

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

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

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

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


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


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


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


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

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


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



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

К сожалению в данном случае, это неизбежность.


Чисто из любопытства: зачем? Что-то типа "на третьей строительной заказов на 3% меньше,
чем на второй, надо туда послать пару людей раскидать рекламу по ящикам"?


Я неправильно выразился. Не по конкретным адресам, а по районам за период. Например, сроки выполнения заказов (уложились ли в прогнозируемое время или нет), оценки заказчиков и т.д. Реже это будет формироваться по улицам. В целом статистические отчеты будут формироваться в худшем случае раз в сутки, реально же не чаще раза в неделю. В принципе на производительности системы это не должно сказаться.


В моем случае будут довольно большие объёмы данных. Из старой базы будет перенесено порядка 700к записей заказов + прогнозируемый рост 200 - 250к записей заказов в год. Так что вопрос оптимизации структуры базы актуален.


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

С учетом новых требований и вариантов предложенных в этой теме, набросал новую схему.
1. От таблицы полных адресов отказался. Вместо него добавил справочник домов с ID улицы и номером дома (в дальнейшем там может быть ID района).
2. В таблицах заказов и юзеров оставил номер квартиры, подъезда, этаж, и домофон. Эти данные не будут принимать участия в формировании статистики и будут использоваться только 1 раз при выполнении заказа. Тут с некоторым дублированием данных придется смирится ( например, при нескольких заказах из одной квартиры ).
3. У юзера в профиле будет всегда один адрес - его собственный. Это связанно со спецификой задачи, поэтому вариант с вынесением адресов юзера в отдельную таблицу я не рассматривал. При формировании заказа юзер может указать произвольный адрес совершенно никак с ним не связанный (примерно 20-30% случаев).

Из вышеперечисленного следует такая логика работы с адресами в положении: при внесении или изменении значений в полях улицы или номера дома и сохранении формы (заказа или юзера), нужно делать проверку, есть ли в справочнике домов указанный адрес. Если есть, то вносить ID дома в таблицу заказа/юзера, если нет, то создавать новую запись в справочнике домов, а потом вносить ее ID в таблицу соответствующего заказа/юзера.
В таком случае, если удастся получить справочник домов с привязкой к району, то существующий справочник можно будет безболезненно расширить.

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

Значит это мое субъективное. Впервые работаю с базой такого размера.


Заказчики внешние. Выше я описал предполагаемую логику работы формы адресов.

Юзеру будет доступен только справочник улиц. Номер дома он будет вносить вручную, поэтому ситуации с отсутствием адреса пользователя в справочнике не случится.


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