Здравствуйте уважаемые коллеги.
Я обращаюсь к вам за советом. Прошло 3 года с тех пор, как я спроектировал БД для агентства недвижимости. По ряду причин, 3 года спустя, я понимаю, что совершил много архитектурных ошибок и БД тормозит. Особенно запросы где много JOIN'ов и преобразований из XML-полей в плоские данные. На данный момент в базе более 9 000 контрагентов и около 11 000 объектов недвижимости.
Настала пора рефакторинга.
Ниже я расскажу о структуре БД на сегодня и опишу проблемы с которыми столкнулся.
Конфигурация: SQL Server 2005 Standart.
1.
Для работы с адресами использую КЛАДР. Экспортировал в базу as is (те же названия таблиц, та же структура).
2.
Таблица объектов недвижимости.
На сегодня у нас 6 типов объектов недвижимости на продажу (квартиры, дома, участки, дачи, коммерция, гаражи) + аренда (представлена как отдельный тип объекта недвижимости). Все типы объектов хранятся в одной таблице. С периодичностью раз в месяц риэлторы просят добавить какое-нибудь поле к объекту или удалить.
Сейчас в таблице 136 полей.
Все бы ничего, но больше всего усложняют жизнь поля типа XML. в них я храню множественный выбор. Например агент отмечает чекбоксами куда в квартире выходят окна.
В поле таблицы этот выбор сохраняется в таком виде
1.
2.
3.
4.
<Items>
<Item id="16">на улицу</Item>
<Item id="17">во двор</Item>
</Items>
у меня есть плоский справочник вида
id - выше в XML это как раз id_item из плоского справочника.
И все бы ничего, но когда приходится фильтровать данные по значениям этих XML-полей (например: выбрать все квартиры с окнами во двор) - база начинает жутко тормозит.
Вторая головная боль это КЛАДР. То как у нас построена иерархия краев, городов и улиц и как это реализовано в КЛАДР просто взрывает мой мозг. Но может быть на тот момент это был наилучший вариант. Разработчикам КЛАДР виднее. НО - в таблице объектов недвижимости мне приходится хранить все 5 уровней адреса из справочника КЛАДР
1.
2.
3.
4.
5.
6.
7.
8.
9.
AddressLevel1
AddressLevel1Code
AddressLevel2
AddressLevel2Code
AddressLevel3
AddressLevel3Code
AddressLevel4
AddressLevel4Code
AddressLevel5
AddressLevel5Code
Это на тот случай, если в КЛАДР отсутсвует Н/П или улица, то риэлтор вводит ее название руками и я сохраняю это название в нужном уровне (например если он ввел руками улицу, то сохраняю в поле AddressLevel5)
Сейчас я понимаю, что очень жестко ошибся при проектировании БД и все нужно было сделать по другому. Но как это сделать правильнее и оптимальнее я не знаю и прошу помощи у вас.
