Есть конечно вариант использовать не таблицу employee, а ее просмотр, в котором для каждого поля внешней таблицы city сделать свой ключ - копию ключа city. Например так:
CREATE VIEW vw_employee AS
SELECT ID, Name, City AS city_name, City AS city_post_index, City AS city_phone_code , Country
FROM employee
А потом в приложении написать:
model->setTable("vw_employee");
model->setRelation(2, QSqlRelation("city", "id", "name"));
model->setRelation(3, QSqlRelation("city", "id", "post_index"));
model->setRelation(4, QSqlRelation("city", "id", "phone_code"));
Этот вариант прокатит, но не хотелось бы использовать такие "костыли" - некрасиво. И возможность редактирования таблицы employee здесь теряется...
Цитата(SABROG @ 26.6.2009, 18:36)
Я чего-то не понимаю. В отношении всегда 2 объекта:
- объект, который ссылается
- объект на который ссылаются
Если есть Петя, в поле "адрес" у которого ключ 1. В другой таблице по ключу 1 стоит "Мухосранск, 10, кв.20".
Ключ "1" не может ссылаться сразу на 2 и более объекта. Например "номер пасспорта", "телефонный номер" и "приводы в милицию".
Вернее, теоретически может. Но обычно все PRIMARY ключи - автоинкрементируемые. Если только в одну из перечисленных полей добавится запись, то ключи перестанут совпадать. Это должна быть какая-то синхронность редактирования БД чтоль.
Все правильно, в отношении "один-к-одному" всегда 2 объекта. Но, у каждого из этих объектов может быть несколько атрибутов. Например, у Пети может быть задан день рождения и место рождения, а может еще что-то. Так вот, у проживающего по адресу "Мухосранск, 10, кв.20" я хочу знать ФИО, дату рождения и где он родился. Или мне для каждого атрибута отдельную таблицу заводить? Отдельно таблицу для дат рождения с двумя полями, отдельно таблицу мест рождений тоже с двумя полями. Так что ли?