| |
|
|
| | Доброго времени суток.
Посоветуйте наиболее гибкую структуру для движка "Недвижимости".
У меня есть несколько мыслей:
Первая: Делаем несколько таблиц, для каждого вида недвижимости (дома, квартиры, участки) свою. И строение у таблиц разное: для квартир - кол-во комнат, этаж, балкон, сан/узел; для домов - площадь участка, удаленность от населенного пункта, площадь дома и т.п.
Т.е. отдельная таблица для своего вида недвижимости...
Вторая: Делаем одну таблицу для разных видов и перечисляем в ней все возможные столбцы: id, id категории, кол-во комнат, этаж, балкон, сан/узел, площадь участка, удаленность от населенного пункта, площадь дома и т.п. И таблицу для категорий, в которой перечислим все виды недвижимости (дома, квартиры, участки).
И при добавлении просто не заполняем ненужные столбцы.
Скрипт планируется без всяких пользователей и регистраций...
Прошу совета
Заранее спасибо... | |
| |
|
|
| |
|
|
| |
для: provodnik
(02.05.2007 в 13:41)
| | | Вторая,
либо третья -
таблица объектов places (в ней все виды недвижимости,без характеристик)
и таблица характеристик ( в ней параметры объектов (id_place, option_name, option-value)) | |
| |
|
|
| |
|
|
| |
для: Trianon
(02.05.2007 в 14:47)
| | | Trianon - прокомментируйте пожалуйста потенциальные минусы и плюсы предложенных трех схем.
Просто я думаю, если использовать 1-ю схему, то отпадает таблица для категорий, т.к. каждая таблица будет являться как-бы отдельной категорией (я планирую минимум 4: квартиры, дома/дачи/коттеджи, земля/участки, нежилая недвиж.)
При использовании 2-й схемы отпадает надобность плодить таблицы.
Предложенную Вами схему немного не понял:
т.е. первая таблица places:
id | vid_nedvijimosti
1 | квартиры
2 | дома
3 | земля
4 | нежильё
и 2-я таблица harakteristiki:
id | id_place | option_name | option-value
1 | 1 | Адрес | г.Москва
2 | 1 | кол-во комнат | 3
3 | 1 | площадь | 60кв.м.
Спасибо... | |
| |
|
|
| |
|
|
| |
для: provodnik
(02.05.2007 в 15:02)
| | | нет.
vid_nedvijimosti:
id| name
1 | квартиры
2 | дома
3 | земля
4 | нежильё
options
id| name| unit| type| comment
1 | Адрес |
2 | кол-во комнат |
3 | площадь | кв.м
4 | расстояние до ст.метро | м
objects
id| id_vid | humman_key
1 | 1 | Твоя квартира
2 | 1 | Моя квартира
harakteristiki
id | id_obj | id_option | val
1 | 1 | 1 | г. Москва, Измайловский пр.2, 15
2 | 1 | 2 | 3
3 | 1 | 3 | 60
4 | 2 | 1 | г. Санкт-Петербург, Гражданский пр.24, 55
5 | 2 | 2 | 5
6 | 2 | 3 | 80
|
В таком примерно ключе | |
| |
|
|
| |
|
|
| |
для: Trianon
(02.05.2007 в 15:18)
| | | - | |
| |
|
|
| |
|
|
| |
для: provodnik
(02.05.2007 в 15:02)
| | | >Trianon - прокомментируйте пожалуйста потенциальные минусы и плюсы предложенных трех схем.
Первая мысль , которая приходит в голову - если база не нормализована, то с ней крайне тяжело будет работать, и еще тяжелее - расширять, если понадобится. | |
| |
|
|
| |
|
|
| |
для: Trianon
(02.05.2007 в 15:21)
| | | Блин, ну Вы Trianon даёте. Это ж структура более подойдет для ВсеРоссийского Сервера Недвижимости, с почти неограниченными возможностями BackOffice, и т.д. и т.п... )
Я думаю - слишком громоздко будет для нас.пункта с населением в 100 000 человек и нагрузкой в 1000 хостов в сутки. Я замучаюсь всю логику расписывать (. Лень.
Продолжаю принимать Советы и идеи.
Trianon спасибо... | |
| |
|
|
