пусть есть таблица institute с одной строкой. Или как-то иначе. Это здесь не обсуждаем.
Есть факультеты. Таблица faculty с FK (или без него, как хотите) на institute
На факультете есть группы. Таблица `group` с FK на faculty.
А еще есть студенты. Таблица student и вот тут вопрос
Студент входит в группу, но ей не принадлежит. После приказа ректора о зачислении он на короткое время становится студентом вне группы, пока его в группу декан не определит. Если уйдет в академотпуск, то до возвращения из него будет опять студентом вне группы.
Значит, FK на `group' с разрешением NULL и с ON DELETE SET NULL. Допустим.
Но если он не в группе, то он все же на факультете. Впрочем, если и в группе, то тоже.
Получается еще один FK на faculty, и тут уже без разрешения NULL, так как вне факультета он быть не может.
В итоге у студента должно быть 2 FK — на группу и факультет. Но группа имеет FK на факультет. Получается, что студент фактически имеет 2 FK на факультет — один явно, а другой косвенно, через свой FK на группу и FK группы на факультет.
Убрать его явный FK на факультет нельзя — при выходе из группы он станет не пойми какого факультета.
Убрать его FK на группу тоже нельзя.
На императивном языке можно было бы ограничиться одной ссылкой на некий интерфейс или базовый класс. Если студент член группы, то на Group (а она на Faculty), если не член — прямо на Faculty. Может, и не лучшее решение, но возможное. А тут одним FK можно обойтись ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Пусть та же система, что и тут
PD>На императивном языке можно было бы ограничиться одной ссылкой на некий интерфейс или базовый класс. Если студент член группы, то на Group (а она на Faculty), если не член — прямо на Faculty. Может, и не лучшее решение, но возможное. А тут одним FK можно обойтись ?
Можно, имитация наследования. Базовая таблица для факультета и группы, к ней 1 к 1 таблицы факультета и группы и у студента внешний ключ на нее, в зависимости от ситуации это будет или факультет или группа.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>На императивном языке можно было бы ограничиться одной ссылкой на некий интерфейс или базовый класс. Если студент член группы, то на Group (а она на Faculty), если не член — прямо на Faculty. Может, и не лучшее решение, но возможное. А тут одним FK можно обойтись ?
Одним FK можно, но не одной таблицей. Нужна новая сущность — студенты без групп с FK на факультет.
Здравствуйте, Qt-Coder, Вы писали:
QC>Одним FK можно, но не одной таблицей. Нужна новая сущность — студенты без групп с FK на факультет.
Существенно усложнит запросы. Если принадлежность или нет к группе не существенна в запросе, то придется делать что-то вроде UNION в лучшем случае, а в худшем 2 запроса.
Плюс исключение/добавление в группу превратится из простого UPDATE к переносу
Виртуальная группа (одна на каждый факультет) в таблице `group` c FK на faculty.
Помещать туда студентов без группы.
В таблицу `group` добавить колонку с типом группы (обычная или имеет особый смысл).
Здравствуйте, Qulac, Вы писали:
Q>Можно, имитация наследования. Базовая таблица для факультета и группы, к ней 1 к 1 таблицы факультета и группы и у студента внешний ключ на нее, в зависимости от ситуации это будет или факультет или группа.
Как юмор оценил, а если серьезно
Плюс дискриминатор в этой таблице , чтобы отличать группы от факультетов
Плюс не знаю какие CONSTRAINT или еще что-то, чтобы группы не включались в группы, факультеты в группы или факультеты, а только группы в факультеты.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Qulac, Вы писали:
Q>>Можно, имитация наследования. Базовая таблица для факультета и группы, к ней 1 к 1 таблицы факультета и группы и у студента внешний ключ на нее, в зависимости от ситуации это будет или факультет или группа.
PD>Как юмор оценил, а если серьезно
Это не юмор был.
PD>Плюс дискриминатор в этой таблице , чтобы отличать группы от факультетов
Это за чем?
PD>Плюс не знаю какие CONSTRAINT или еще что-то, чтобы группы не включались в группы, факультеты в группы или факультеты, а только группы в факультеты.
А не будет проблем, fk группы будет указывать на факультет, а не на базовую таблицу.
Здравствуйте, Qulac, Вы писали:
Q>>>Можно, имитация наследования. Базовая таблица для факультета и группы, к ней 1 к 1 таблицы факультета и группы и у студента внешний ключ на нее, в зависимости от ситуации это будет или факультет или группа.
Q>Это не юмор был.
А зачем тогда смайлик поставил ?
PD>>Плюс дискриминатор в этой таблице , чтобы отличать группы от факультетов
Q>Это за чем?
Ну этот тот же instanceof.
Получил по студенческому FK элемент из базовой таблицы, а теперь куда второй запрос ? На факультет или группу ?
PD>>Плюс не знаю какие CONSTRAINT или еще что-то, чтобы группы не включались в группы, факультеты в группы или факультеты, а только группы в факультеты.
Q>А не будет проблем, fk группы будет указывать на факультет, а не на базовую таблицу.
То есть у группы будет 2 FK — на факультет и на базовую таблицу ?
M>>Виртуальная группа (одна на каждый факультет) в таблице `group` c FK на faculty.
PD>Наверное, все же не в таблице группы, а на факультете ?
Нет, именно в таблице `group`. Студент без группы будет иметь FK на такую виртуальную группу.
PD>Ответил на аналогичное здесь PD>https://rsdn.org/forum/db/8843915.1
Здравствуйте, m2user, Вы писали:
M>Нет, именно в таблице `group`. Студент без группы будет иметь FK на такую виртуальную группу.
M>В предлагаемом мной варианте не добавляется новых таблиц. M>Перенос студента между группами в т.ч. в состояние "без группы" будет в один update.
Теперь понял. Похоже, это и впрямь наилучшее решение.
Меня смутил термин "виртуальная". Просто группа тех, кто не в обычной группе.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Qulac, Вы писали:
Q>>>>Можно, имитация наследования. Базовая таблица для факультета и группы, к ней 1 к 1 таблицы факультета и группы и у студента внешний ключ на нее, в зависимости от ситуации это будет или факультет или группа.
Q>>Это не юмор был.
PD>А зачем тогда смайлик поставил ?
Я его всегда ставлю.
PD>>>Плюс дискриминатор в этой таблице , чтобы отличать группы от факультетов
Q>>Это за чем?
PD>Ну этот тот же instanceof.
PD>Получил по студенческому FK элемент из базовой таблицы, а теперь куда второй запрос ? На факультет или группу ?
На ту таблицу где есть соответствующая строка в fk на ключ.
PD>>>Плюс не знаю какие CONSTRAINT или еще что-то, чтобы группы не включались в группы, факультеты в группы или факультеты, а только группы в факультеты.
Q>>А не будет проблем, fk группы будет указывать на факультет, а не на базовую таблицу.
PD>То есть у группы будет 2 FK — на факультет и на базовую таблицу ?
Павел, ты пытаешься смешивать в кучу атрибуты сущностей и соотношения между сущностями.
По классике, нужны таблицы соотношений, а не ссылки на другие сущности.
Но если это задача из типа "учебных", то и не парься.
Как сделаешь, так и будет.
Здравствуйте, Qulac, Вы писали:
PD>>А зачем тогда смайлик поставил ?
Q>Я его всегда ставлю.
Я же не знал В ответе он был один, было бы много — может, и догадался бы.
PD>>>>Плюс дискриминатор в этой таблице , чтобы отличать группы от факультетов
Q>>>Это за чем?
PD>>Ну этот тот же instanceof.
PD>>Получил по студенческому FK элемент из базовой таблицы, а теперь куда второй запрос ? На факультет или группу ?
Q>На ту таблицу где есть соответствующая строка в fk на ключ.
Где, в базовой таблице или в таблице группы или факультета ? Если в базовой, то там, значит, 2 FK и один из них NULL ? Если в таблице группы или факультета, то как мне узнать, в какой ?
PD>>>>Плюс не знаю какие CONSTRAINT или еще что-то, чтобы группы не включались в группы, факультеты в группы или факультеты, а только группы в факультеты.
PD>>То есть у группы будет 2 FK — на факультет и на базовую таблицу ?
Q>Да.
Здравствуйте, Alex.Che, Вы писали:
AC>Павел, ты пытаешься смешивать в кучу атрибуты сущностей и соотношения между сущностями. AC>По классике, нужны таблицы соотношений, а не ссылки на другие сущности. AC>Но если это задача из типа "учебных", то и не парься. AC>Как сделаешь, так и будет.
Да, учебная, но все же хотелось бы знать наилучшее решение в рамках SQL.
30.10.2024 16:26, Pavel Dvorkin пишет:
PD> Да, учебная, но все же хотелось бы знать наилучшее решение в рамках SQL.
очень сильно зависит от "академичности" препода.
если он фанат К.Дж.Дейта, то это одно, а если Дж.Грея, то совсем другое.
если есть методичка, следуй указаниям, и не парься.
а то сделаешь слишком умно — препод не поймёт...
Здравствуйте, Alex.Che, Вы писали:
AC>очень сильно зависит от "академичности" препода. AC>если он фанат К.Дж.Дейта, то это одно, а если Дж.Грея, то совсем другое. AC>если есть методичка, следуй указаниям, и не парься. AC>а то сделаешь слишком умно — препод не поймёт...
Я и есть тот самый "препод", и хотел получить мнение коллег о том, какое решение они считают лучшим , чтобы рекомендовать именно его.
