Объекты и классы

[olehs]

К сожалению, сам справочник Расположений (таблица locations) плоский. Полностью в нем структуру не построишь.

Но, кроме "логики", есть ли какие-то различия в свойствах или методах у классов Квартира, Гараж, Подвал? Есть ли у них вообще свойства или методы?
Если нет, можно просто в Расположения завести Квартира, Гараж, Подвал, а уже в объектах Rooms конечные помещения (кухня, кладовка, паркоместо) с указанием нужного Расположения.
А в классы объектов, зависящих от помещений (например, датчики), как и говорил Сергей, добавлять свойство LinkedRoom, в котором ссылаться на объект из Rooms (но уже без указания местоположения, чтобы не возникло противоречивости данных).

[ErmolenkoM]

Есть квартира. Есть подвал, в котором тоже несколько помещений: кладовка, подвал, холодильник.

А почему бы не наследовать подвал от квартиры, кладовку от подвала, а холодильник от кладовки? Это ведь решает проблему.

[Михаил_Калуга]

Всем спасибо.
Во вложении структура БД МЖД. Пока могу сказать, что в двух разных таблицах locations и objects у нас одни и те же значения Bathroom, Bedroom, Hall, Kinderroom и тд. Хотя мое знакомство с базами достаточно поверхностное и лет 10 я не в теме, но помню , что это неправильно. Пока думаю

[Михаил_Калуга]

Вдогонку вопрос к знатокам.
посмотрите таблицу pvalues
почему названия отличаются от названия таблиц?
PROPERTY_ID, а таблица называется properties
OBJECT_ID а таблица называется objects

[olehs]

Всем спасибо.
Во вложении структура БД МЖД. Пока могу сказать, что в двух разных таблицах locations и objects у нас одни и те же значения Bathroom, Bedroom, Hall, Kinderroom и тд. Хотя мое знакомство с базами достаточно поверхностное и лет 10 я не в теме, но помню , что это неправильно. Пока думаю

Сергей и говорил, что в инсталяторе не самая оптимальная структура.
locations и objects - это разные сущности: Расположения - это то, где кто-то/что-то находится, Объекты - то, с чем можно взаимодействовать.
Но, если есть необходимость расширить функционал Расположений за счет возможностей Объектов, то нет ничего плохого в создании связей 1 к 1 между ними. Избыточностю здесь может быть, разве что, поле Название. Но и эту особенность можно использовать с пользой.

У меня, например, нет в структуре разных локаций, как у Вас (Гараж, Подвал и т.д.), а есть одна Квартира с комнатами. Я бы мог в locations указать только квартиру, но тогда потеряется польза от Расположений вообще.
Потому я в locations храню сущности уровнем ниже - комнаты, так же как и в объектах.

посмотрите таблицу pvalues
почему названия отличаются от названия таблиц?
PROPERTY_ID, а таблица называется properties
OBJECT_ID а таблица называется objects

Если Вы про PROPERTY_ID/PROPERTIES, то это соответсвует одной из общепринятых конвенций именования сущностей/атрибутов баз данных.
В кратце:
1. Имена таблиц во множесвенном числе
2. Имена полей в единственном числе
3. Ключевое поле - ID
4. Суффикс _ID у полей с внешним ключем.

[Михаил_Калуга]

Если Вы про PROPERTY_ID/PROPERTIES,

Я попробовал для наглядности создать связь между таблицами. Одни создались без проблем. А связь с таблицей pvalues не создается (вложение) подумал, что проблема в неточности написания, а потом увидел, что там где связи установились написано аналогично. Попробовал указать варианты при обновлении/удалении связь устанавливать не хочет. Это непринципиально.

По поводу местоположения. Вернулись к тому чего я хотел в начале.
Хочу на местоположение взглянуть шире. Т.е. даже просто в квартире может возникнуть ситуация, когда под местоположением могут пониматься предметы из разных классов. Также есть ситуации когда нужно вручную вводить какие то объемы информации и местоположение важно.
Пример:
У меня есть класс продукты (питания)
Есть класс холодильники ( установлены в квартире кухня, коридор и подвал)
Есть ящики для продуктов (назовем так) установлены в квартире кухня и подвале)

При поступлении продуктов и раскладке их по местам хранения я заношу вручную данные в базу данных через панель управления. И здесь логично и удобно выбирать конкретный ящик или холодильник, те я должен выбрать класс холодильники или ящики и выбрать конкретный холодильник или ящик куда положил продукты.
В результате. Когда я захочу свежего пива с воблой, то получу ответ, что свежее пиво в холодильнике в коридоре, а вобла в ящике в подвале.
Еще раз уточню рассматриваем ситуацию периодического ручного ввода объема информации где важно местоположение.

[olehs]

Идея понятна, но в виду большой специфичности задачи, я бы либо взялся за написание отельного модуля с нужной структурой таблиц, либо выбрал готовую логистическую прикладуху с возможностью интеграции в МЖД.

[Михаил_Калуга]

А в чем специфичность? Классы есть, объекты есть.
Когда в панели инструментов для объекта выбираем местоположение имеем два пути:
1. Местоположение неважно
2. Местоположение выбрать из класса -> Выбираем класс -> Выбираем конкретный объект. Все

[ErmolenkoM]

Местоположение выбрать из класса -> Выбираем класс -> Выбираем конкретный объект. Все

Приведите пожалуйста пример кода на PHP где вы собираетесь использовать ссылки на объект.
Даже если предположить что укладка в базу произведена - как этим пользоваться? Напишите код.
Еще вопрос: Пиво - это объект?

[Alien]

Сорри за оффтоп. Пиво - никак не объект, ибо оно как мед. Если он есть, то его сразу нет (с).