Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > СУБД, общие вопросы > Проектирование отношений master-detail


Автор: M1ndAction 6.2.2010, 04:55
Добрый день,
БД давно уже не занимался, да и тогда это было не серьезно - теперь приходится опять вспоминать и вникать во все заново smile
Вопрос в следующем: я получил ТЗ, где уже была прописана структура БД, но при этом ее составлял человек, профессионально этим не занимающийся. Я посмотрел - вроде на первый взгляд все в порядке. Но когда приступил к программированию, то обнаружил ряд спорных моментов, а именно: есть две таблицы - Persons и Places. В Places есть ключевое поле idPlaces, в Persons три поля: peridBirthPlace, peridDeathPlace и peridBurialPlace. Все эти три поля являются внешними ключами на idPlaces. Вопрос, насколько это верно? Меня это с самого начала смущало, а при программировании столкнулся с тем, что вообще как это можно описать? Т.е. раз это внешний ключ, то мне надо, чтобы курсор в наборе данных находился сразу в трех местах одновременно (соответственно три разных значения для каждого из полей peridBirthPlace, peridDeathPlace и peridBurialPlace) smile Можно, конечно, формально убрать эти ключи, и тогда "вручную" забивать нужные значения, но пока хотелось бы более цивилизованно решить проблему.
Привожу все поля таблицы Perosons:

idPersons INT(11) - Ключевое поле
perSex INT(1)
peridMParent INT(11)
peridFMParent INT(11)
perBirthdayFrom DATE
perBirthdayTo DATE
perBirthdayType INT(1)
peridBirthPlace INT(11)
perBirthPlaceComment TEXT
perDeathdayFrom DATE
perDeathdayTo DATE
perDeathdayType INT(1)
peridDeathPlace INT(11)
perDeathPlaceComment TEXT
peridBurialPlace INT(11)
perBurialComment TEXT

Таблица Places:
idPlaces INT(11) - Ключевое поле
plaName VARCHAR(20)
plaidParentPlace INT(11)
plaType INT(1)

СУБД - MySQL 5.1 Embedded, среда программирования Delphi 2009, компоненты доступа MyDAC.

Автор: Simpliest 6.2.2010, 11:59
Цитата(M1ndAction @  6.2.2010,  03:55 Найти цитируемый пост)
Places есть ключевое поле idPlaces, в Persons три поля: peridBirthPlace, peridDeathPlace и peridBurialPlace. Все эти три поля являются внешними ключами на idPlaces. Вопрос, насколько это верно?

А что в этом такого?

Цитата(M1ndAction @  6.2.2010,  03:55 Найти цитируемый пост)
то мне надо, чтобы курсор в наборе данных находился сразу в трех местах одновременно 

Зачем?

Автор: M1ndAction 6.2.2010, 12:35
Цитата

Зачем?

А как тогда связь организовать между двумя наборами данных? Ведь обычная схема: есть два набора данных - один master, другой detail. Для detail указываем master-dataset и ключевое поле master-dataset, а для detail-dataset указываем "подчиненные" поля, которые и являются внешними ключами. Затем, когда добавляем новую запись в detail, во внешних ключах автоматически проставляется значение из master-dataset, притом из той записи, на которой установлен курсор в наборе данных в данный момент времени. Ведь так? Поэтому, если я правильно рассуждаю, нужно три курсора, чтобы добавить запись, поэтому и загвоздка возникла smile

Автор: Simpliest 6.2.2010, 15:40
Цитата(M1ndAction @  6.2.2010,  11:35 Найти цитируемый пост)
. Затем, когда добавляем новую запись в detail, во внешних ключах автоматически проставляется значение из master-dataset, притом из той записи, на которой установлен курсор в наборе данных в данный момент времени. Ведь так? Поэтому, если я правильно рассуждаю, нужно три курсора, чтобы добавить запись, поэтому и загвоздка возникла

Я несколько не понимаю, вы работаете с БД прямым доступом что ли?

Насколько я помню в API MySQL есть mysql_real_query() которой дается таки SQL запрос.
Код

int mysql_real_query(MYSQL *mysql, const char *stmt_str, unsigned long length) 


Ну а связать 5ть таблиц в одном запросе - это легко.

Код

SELECT * FROM table1
JOIN table2 ON table1.idChild2 = table2.id
JOIN table3 ON table1.idChild3 = table3.id
JOIN table4 ON table1.idChild4 = table4.id


Собственно вместо имен таблиц и ключей подставить свои названия.
При INSERT/UPDATE у вас будет несколько запросов. Для вставки в каждую таблицу.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)