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


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


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


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


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

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

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

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