Подскажите, отношение категоризации mysql

wotka · 22.05.2011

Подскажите, отношение категоризации mysql

Здравствуйте, пишу себе курсовую по БД. mysql+php.
Вот кусок модели, в которой у меня возникла проблема:

⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.

В чем смысл:
Есть агенство недвижимости, в нем присутствуют частные дома и квартиры. типы сделки(offer_type) - аренда/продажа.
Отношением категоризации я разделил сущность Объект на Дом и Квартиру, а общие для них параметры вынесены в родителе.
В чем, собственно, проблема покажу на примере:
Квартира№1 object.id_object = 1, flat.id_object=1;
Дом№1 object.id_object = 2, house.id_object=2;
Квартира№2 object.id_object = 3, flat.id_object=3;
Квартира№3 object.id_object = 4, flat.id_object=4;
Дом№2 object.id_object = 5, house.id_object=5;
То есть, мне надо дублировать в Квартиру или Дом определенную id.
надеюсь, я понятно объяснил в чем суть.

reflect · 22.05.2011

Зачем дублировать? Если таблица не нужна, не создавай её. И в таблице Object лушче ввести поле isHouse, чтобы не искать тип обекта лишним sql запросом.

wotka · 22.05.2011

Я хотел обойтись без object_type, сделать через представление.
Вообще я не знаю как записать именно ту айдишку, которая необходима, то есть Flat не 1,2,3,4....N, а грубо говоря 1,2,5,19. Получается это и есть дублирование нужного айди, хотя, может не верно выражаюсь

Это ж я хочу сделать добавление объекта через админку сайта, я ж не могу глупо вручную вписывать там необходимые айдишки. А просто вбил район, улицу, площадь, номер квартиры и получаю в базе набор правильных айди. В Object то автоинкримент стоит, а вот в Флет и Хауз не знаю как вбивать.
Я бы мог убрать разделения и оставить всё в 1 таблице Object, но получится лишний мусор(пачка null значений), за который получу люлей на сдаче курсовой.
Заметил, что в Flat и House есть только поле Primary, а в Ервине оно мне к нему еще и FK дописывало. Я не знаю должно ли так быть.
Ах да, а Object.id_img тоже ж автоинкрементом делать?

BFG-9000 · 22.05.2011

Исходя из реалий описываемой области - таблицы Хауз и Флэт (которые кстати нихера не референсные, как это подразумевает название

) не имеют смысла.

Они задуманы как справочные - то есть типа есть множество однотипных квартир и домов. Но по совокупности признаков - разнотипных квартир/домов тоже будет дохера и больше.

Далее исходя из реалий работы с базой информация из этих таблиц в большинстве случаев будет востребована вместе с информацией из основной таблицы - и смысл ее отделять от основной таблицы кроме как для демонстрации своего умения пользоваться JOIN?

Kompot · 22.05.2011

да и картинки через кросс-таблицу не мешало бы прикрутить.

Ferox · 22.05.2011

BFG-9000 прав. На практике так оно и есть. А в учебных целях - дублируйте id не понятно в чем проблема? Сначала пишете запись в общую таблицу, там айдишники с автоинкрементом, после вставки получаете айдишник и знаете с каким айдишником писать строки во вспомогательные таблицы.

Kompot сказав(ла):
да и картинки через кросс-таблицу не мешало бы прикрутить.

В общем кросс-таблицы не надо. Просто в таблице с картинками добавить поле - id объекта-овнера.

wotka · 23.05.2011

То есть мне приставку _reference убрать из таблиц?
Ферокс, спасибо, теперь я понял как продублировать айдишку

BFG-9000 сказав(ла):
Далее исходя из реалий работы с базой информация из этих таблиц в большинстве случаев будет востребована вместе с информацией из основной таблицы - и смысл ее отделять от основной таблицы кроме как для демонстрации своего умения пользоваться JOIN?

Если я правильно Вас понял, то Вы предлагаете убрать разделение на Флет и Хауз, но так будет пачка null"ов при добавлении разных объектов, я за такое на сдаче курсача по шапке получу.

И я еще про картинки не понял, связь в другую сторону развернуть если добавлять ид объекта овнера?
типа: object- - - *img, а не как сейчас: img- - - *object.

joker · 23.05.2011

wotka сказав(ла):
То есть мне приставку _reference убрать из таблиц?
Ферокс, спасибо, теперь я понял как продублировать айдишку

Если я правильно Вас понял, то Вы предлагаете убрать разделение на Флет и Хауз, но так будет пачка null"ов при добавлении разных объектов, я за такое на сдаче курсача по шапке получу.
И я еще про картинки не понял, связь в другую сторону развернуть если добавлять ид объекта овнера?
типа: object- - - *img, а не как сейчас: img- - - *object.

А я бы скорее выписал люлей за неправильную нормализацию. А в продакшене заставил бы переделывать - очень много лишнего головняка для поддержки. (Да посоветуйтесь с руководителем проекта в конце концов)
(кроме того... часть полей совпадет... так что не так много нуллов)

насчет картинок - добавить в нее id_object - тогда и кол-во их станет любым и от лишних проверок избавишься.

Ferox · 23.05.2011

wotka сказав(ла):
но так будет пачка null"ов при добавлении разных объектов, я за такое на сдаче курсача по шапке получу.

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

reflect · 23.05.2011

---

Ferox · 23.05.2011

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

сами-знаете-кто · 23.05.2011

бесполезных связей "один-к-одному" с утра вообще советовали избегать.
во всех мыслимых вариантах любых информационных систем.

Ferox · 23.05.2011

Не, ну связи один-к-одному бывают нужны на практике. Но с адресом это не тот случай.

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

сами-знаете-кто · 23.05.2011

Ferox сказав(ла):
Не, ну связи один-к-одному бывают нужны на практике. Но с адресом это не тот случай.

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

проблемы с переферическим зрением?
ты слово "бесполезных" совсем не заметил или не смог прочесть?

wotka · 23.05.2011

Так, мужики, в общем я убрал то разделение и вынес всё в Object. в Images теперь есть id_object(FK). На этом всё, или как-то предложите нормализовать?
Или reflect уже всё сделал?

reflect · 23.05.2011

Ferox

Да, в данном случае таблицу "адрес" можно и не выносить. Но повторяющиеся записи для быстрого поиска по адресу я бы вынес.

Подскажите, отношение категоризации mysql

Вкладення