Меню
Что нового?

стурктура бд

Keil

Guest
стурктура бд

Возникла слeдующая ситуация:
Мы работаем с недвижимостью, вся недвижимость обладает базовыми параметрами (Цена, Площадь, Адрес, ...), помимо этого каждый конкретный вид недвижимости обладает дополнительными параметрами, которые различны для разных видов. Подскажите как правильно постpоить базу данных ?

Как вариант,
все базовые параметры занесены в базовую таблицу, все дополнительные в соответствующие дополнительные, но тогда возникает проблема прохода по базовой таблице ( не leftjoin'ить ведь все доп. таблицы )

10х
 

DimbIch

Новичок
а зачем ???
я бы сделал так....
1. таблица base скажем - там цена прощадь и че там еще и последнее поле - Вид недвижимости...
2. таблица вид недвижимости 1 - и поля которые ему присущи
и тд тд тд
 

Keil

Guest
отлично, как теперь достать все данные с соответствующими полями ?
например:
квартира N1, размер балкона х, размер кухни y, ...
склад N1234, площадь z, кондиционер 1, ...
магазин N343, ....
 

DimbIch

Новичок
SELECT * FROM base AS b, flat AS f LEFT JOIN ON b.id=f.id
вот и все....
и по аналогии....
 

Keil

Guest
нет не всё, у меня есть с десяток видов недвижимости и для того чтобы достать все мне нужно будет делать десяток left join
 
Breeze

Breeze

goshogun
Команда форума
Партнер клуба
Keil

мыслишь правильно.. все базовые х-ки хранятся в одной таблице под уникальным item_id..

для остальных -- достаточно 4-х таблиц:

1. item_type <-- здесь тип недвижимости(дом, квартира, комната и т.д.)

| type_id | name |

2. item_q <-- параметры(габариты, материал и т.д.)

| param_id | type_id | name |

3. item_v <-- варианты параметров(для чекбоксов, радиобатонов и т.д.)

| var_id | param_id | name |

4. item_a <-- а здесь хранятся заполненные варианты, соотносящиеся с основной таблицей по тому самому item_id..

| item_id | type_id | param_id | var_id | text

примерно так..
 

Keil

Guest
угу, понятно, данное решение думаю было бы идеальным если бы изначально не были известны все дополнительные параметры (у меня используется подобная структура для возможности произвольного добавления юзером нужных ему полей)
однако, я вижу несколько проблем:
во-первых, если сджойнить все указанные таблицы, то ризалт значительно возрастёт
во-вторых, сложность обработки ,т.к. добавится миллион if'ов.

Как насчёт следующей структуры :
BaseProperties - базовая таблица (`PropID`, `Size`, `Price`, `DetailsTableName`, `Method1`, `Method2`,..., еtc.)
Аpartments - квартиры (`PropID`, `ASpecific1`, `ASpecific2`, etc)
Storerooms - складские помещения (`PropID`, `SSpecific1`, `SSpecific2`, etc)
...

Предположим нужно пройти по всей таблице BaseProperties и выполнить определённое действие (распечатать специфицеское для каждого вида недвижимости поле)

PHP: 
$sql = "
(
   SELECT Method{i} #, Method{i} specific Appartments fields
   FROM Apartments INNER JOIN BaseProperties USING(PropID)
)
UNION
(
   SELECT Method{i} #, Method{i} specific Storerooms fields
   FROM Storerooms INNER JOIN BaseProperties USING(PropID)
)
#UNION ...
";

//и далее 
$res = mysql_query($sql) or die('not today :-((<br>'.mysql_error());
while($row = mysql_fetch_assoc($res))
{
    eval($row["Method{$i}"]);
}
то есть эмуляция ооп
???
 
Breeze

Breeze

goshogun
Команда форума
Партнер клуба
возможно, но мне данное решение с джоинами тоже не кажется оптимальным, в плане оперативной масштабируемости.. про скорость говорить не буду :)

во-первых, если сджойнить все указанные таблицы, то ризалт значительно возрастёт
Нажмите для раскрытия...
а зачем их джойнить?

во-вторых, сложность обработки ,т.к. добавится миллион if'ов.
Нажмите для раскрытия...
за все время использования данной схемы не встречалось мне миллионов ифов :)

В общем слишком общая задача поставлена, чтобы найти оптимальное решение.

Например, для организации каталога предложенное мной решение вполне подходит, т.к. поиск по такой структуре делается очень хорошо. все поля, которые должны выводится в списковом контексте, хранятся как раз в общей таблице. А вывод целиком одной записи из всех таблиц делается тремя простыми запросами SELECT.
 

Keil

Guest
Breeze
ок, предположим реальную ситуацию:
у квартир есть площадь, этаж, номер, номер дома, кол-во комнат
у стоянки есть название, номер, дом к которому прилегает, ...
у магазина есть площадь, площадь складских помещений , номер, номер дома...
...

нужно выдать полный информационный блок по каждой единице недвижимости
как ?
 
Дмитрий Попов

Дмитрий Попов

сторож
Есть. Если Вам эти данные только выводить нужно, то не вижу смысла в этих извращениях - храните всю доп. информацию в одном поле в сериализованном виде и не парьтесь.
 

Keil

Guest
ясно, но выборки естественно есть по всем полям
 
Breeze

Breeze

goshogun
Команда форума
Партнер клуба
Breeze

Breeze

goshogun
Команда форума
Партнер клуба
Keil

хм.. вопрос интересный.. но мешать гаражи с магазинами в одну кучу ИМХО как-то неправильно. хотя может и недопонял чего..

Дмитрий Попов
здОрово, натолкнул меня на очень интересную мысль с сериализацией :)
 

Keil

Guest
Originally posted by Breeze
Keil

хм.. вопрос интересный.. но мешать гаражи с магазинами в одну кучу ИМХО как-то неправильно. хотя может и недопонял чего..
Нажмите для раскрытия...


оказывается логично, например контракт может включать несколько квартир, складское помещение и пару парковок;
или в доме есть этажи желые, есть занятые служебными помещениями, офисами, стоянками, ...,
 
Breeze

Breeze

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

Keil

Guest
Originally posted by Breeze
с этого и надо было начинать.. при просмотре контракта надо указывать его составляющие в развернутом виде.. так?
Нажмите для раскрытия...
так, плюс ещё масса скриптов выводящих схему здания например.
 
Войдите или зарегистрируйтесь для ответа.
Сверху