База данных для конторы которая будет предоставлять информацию о спросе и предложении по объектам недвижимости. То есть с их помощью можно найти объект или оставить заявку для продажи/аренды своего объекта.
К объектам относятся:
квартира, дом, гараж, коттедж, земля, торговое или складское помещение, "готовый бизнес" - сам толком не понял что это значит..., возможно что-то еще.
Так же нужно хранить информацию о клиентах которых интересует спрос и клиентах которым интересно предложение.

На данный момент придумал такую модель данных, которая мне не очень нравится.
Может быть лучше не разделять объекты на "спрос" и "предложение", а хранить все в одних таблицах добавив столбец указывающий что это "спрос" или "предложение"? (Но не будет ли долгим поиск в объединенных таблицах при большом количестве записей...?)
Покритикуйте пожалуйста схему =)

наутилус,

если честно с начала у меня была примерно такая же, структура.
Но потом я подумал, что поиск по одной большой таблице Object будет долгим.
Хотя думаю что я ошибаюсь, потому, что какая разница... поиск все равно будет по ключам а уж потом фильтрация выбранных строк...
Буду переделывать и выложу новый вариант :)

наутилус,

а можно по подробнее про правильные запросы?

наутилус,

понятно, спасибо, можно ещё пару вопросов?
Возможно они глупые, но все же.
1) Объекты могут находиться в разных городах, потому лучше сделать отдельные таблицы "Город", "Район", Улица дабы избежать избыточности данных и в табл. "Объект" хранить всего лишь ссылки на "Город", "Район" или лучше хранить все в таблице "Объект"?

2) На каком типе данных (домене) лучше определить атрибут "Телефон" на целочисленном или символьном? Нас в институте учили, что домен должен накладывать ограничения для повышения надёжности, вот и хочу выбрать целочисленный тип, да бы нельзя было записать в телефон буквы. Но во многих примерах используют символьный тип, да и не только цифры в телефоне указывают а скобки ещё и тире.

всем большой спасибо!