Сообщение Re[4]: и еще один вопрос по реляционной структуре от 31.10.2024 13:02
Изменено 31.10.2024 13:07 Pavel Dvorkin
Re[4]: и еще один вопрос по реляционной структуре
Здравствуйте, paucity, Вы писали:
P>Ты бы начал с формализации требований/ТЗ/спецификаций (назови как хочешь) для твоей учебной задачи -- основные моменты без растекания.
P>Например, если в требованиях будет зафиксированно, что студент может быть только в одной группе и историю переводов из группы в группу, или с факультета на факультет хранить не надо, то и вопросов меньше.
Да, ты прав, я как-то не подумал. Надо было с самого начала объяснить, что это модельная учебная задача, а вовсе не для production.
Исправляюсь.
В общем, есть у меня учебное упражнение по основам SQL а потом MyBatis и Hibernate.
Задача простая — факультет, группы, студенты, предметы
Цель — освоить SQL и остальное. PK, FK, WHERE всякие, JOIN и т.п. В общем, основы SQL , начальный курс. Без триггеров и SP.
Ну и 1:many (student : group) и many:many (group:subject).
Институт я в этой модели опустил. Лес факультетов с группами и студентами в них. Естественно, только текущее состояние, никакой истории.
А с другой стороны, правила тут должны быть именно те, что в реальности. Предметная область студентам очень уж хорошо знакома
И вот я подумал, не расширить ли задачу, добавив институт. В исходной задаче принадлежность студентов замалчивается. Они члены групп или не члены, а те, что не члены, явно ни чему не принадлежат.
Ну и возникли 2 вопроса. Первый — про единственную запись в таблице институт, а вторая — к чему принадлежат студенты, не входящие в группы.
P>Ты бы начал с формализации требований/ТЗ/спецификаций (назови как хочешь) для твоей учебной задачи -- основные моменты без растекания.
P>Например, если в требованиях будет зафиксированно, что студент может быть только в одной группе и историю переводов из группы в группу, или с факультета на факультет хранить не надо, то и вопросов меньше.
Да, ты прав, я как-то не подумал. Надо было с самого начала объяснить, что это модельная учебная задача, а вовсе не для production.
Исправляюсь.
В общем, есть у меня учебное упражнение по основам SQL а потом MyBatis и Hibernate.
Задача простая — факультет, группы, студенты, предметы
Цель — освоить SQL и остальное. PK, FK, WHERE всякие, JOIN и т.п. В общем, основы SQL , начальный курс. Без триггеров и SP.
Ну и 1:many (student : group) и many:many (group:subject).
Институт я в этой модели опустил. Лес факультетов с группами и студентами в них. Естественно, только текущее состояние, никакой истории.
А с другой стороны, правила тут должны быть именно те, что в реальности. Предметная область студентам очень уж хорошо знакома
И вот я подумал, не расширить ли задачу, добавив институт. В исходной задаче принадлежность студентов замалчивается. Они члены групп или не члены, а те, что не члены, явно ни чему не принадлежат.
Ну и возникли 2 вопроса. Первый — про единственную запись в таблице институт, а вторая — к чему принадлежат студенты, не входящие в группы.
Re[4]: и еще один вопрос по реляционной структуре
Здравствуйте, paucity, Вы писали:
P>Ты бы начал с формализации требований/ТЗ/спецификаций (назови как хочешь) для твоей учебной задачи -- основные моменты без растекания.
P>Например, если в требованиях будет зафиксированно, что студент может быть только в одной группе и историю переводов из группы в группу, или с факультета на факультет хранить не надо, то и вопросов меньше.
Да, ты прав, я как-то не подумал. Надо было с самого начала объяснить, что это модельная учебная задача, а вовсе не для production.
Исправляюсь.
В общем, есть у меня учебное упражнение по основам SQL а потом MyBatis и Hibernate.
Задача простая — факультет, группы, студенты, предметы
Цель — освоить SQL и остальное. PK, FK, WHERE всякие, JOIN и т.п. В общем, основы SQL , начальный курс. Без триггеров и SP.
Ну и many :1 (student : group) и many:many (group:subject).
Институт я в этой модели опустил. Лес факультетов с группами и студентами в них. Естественно, только текущее состояние, никакой истории.
А с другой стороны, правила тут должны быть именно те, что в реальности. Предметная область студентам очень уж хорошо знакома
И вот я подумал, не расширить ли задачу, добавив институт. В исходной задаче принадлежность студентов замалчивается. Они члены групп или не члены, а те, что не члены, явно ни чему не принадлежат.
Ну и возникли 2 вопроса. Первый — про единственную запись в таблице институт, а вторая — к чему принадлежат студенты, не входящие в группы.
P>Ты бы начал с формализации требований/ТЗ/спецификаций (назови как хочешь) для твоей учебной задачи -- основные моменты без растекания.
P>Например, если в требованиях будет зафиксированно, что студент может быть только в одной группе и историю переводов из группы в группу, или с факультета на факультет хранить не надо, то и вопросов меньше.
Да, ты прав, я как-то не подумал. Надо было с самого начала объяснить, что это модельная учебная задача, а вовсе не для production.
Исправляюсь.
В общем, есть у меня учебное упражнение по основам SQL а потом MyBatis и Hibernate.
Задача простая — факультет, группы, студенты, предметы
Цель — освоить SQL и остальное. PK, FK, WHERE всякие, JOIN и т.п. В общем, основы SQL , начальный курс. Без триггеров и SP.
Ну и many :1 (student : group) и many:many (group:subject).
Институт я в этой модели опустил. Лес факультетов с группами и студентами в них. Естественно, только текущее состояние, никакой истории.
А с другой стороны, правила тут должны быть именно те, что в реальности. Предметная область студентам очень уж хорошо знакома
И вот я подумал, не расширить ли задачу, добавив институт. В исходной задаче принадлежность студентов замалчивается. Они члены групп или не члены, а те, что не члены, явно ни чему не принадлежат.
Ну и возникли 2 вопроса. Первый — про единственную запись в таблице институт, а вторая — к чему принадлежат студенты, не входящие в группы.