Флажок данных в столбце?

Question

база данных учебного курса должна получить обновление.Прямо сейчас каждый новый пользователь (редактируемый клиентом клиента) сохраняется в данном учебном курсе (редактируемом клиентом).количество пользователей учитывается, так что для каждого учебного курса не может быть более 12 пользователей.

хорошо, это была старая концепция.

для нового,каждый новый пользователь может быть подписан на большее количество курсов, чем один с флажками.для меня сейчас проблема в том, что у меня возникают проблемы с концепцией массива в инструкциях SELECT / DELETE / UPDATE в данном столбце (sID, который является идентификатором обучения)

Таблицаучебные курсы:

id | from_date             | til_date |          | ...   
---+-----------------------+---------------------+---------
2  |  2012-04-16 08:30:00  | 2012-04-16 08:30:00 | ...

Таблица обучения пользователей:

id | sID | name     | ...                          
---+-----+----------+---------------------------------------
1  |  2  | User A   | ...
2  |  6  | User B   | ...

мне понравилась концепция написания различных курсов в одной колонке (2,47,9) разделены ",".но у меня возникнет проблема, заключающаяся в том, что я больше не могу делать COUNT для этого столбца.также сохраненные данные курса только выводят проверенные курсы на флажки.но клиент клиента должен обновить участников курса вручную.так что я не могу «жестко» закодировать каждый курс в чекбоксе.

У кого-нибудь есть идеи, как это сделать правильно?

спасибо и привет, Бернард

Answer 1

Вам понадобится как минимум три стола.

courses: (id, name, etc....)
users: (id, name, etc....)
user_courses: (user_id, course_id)

Добавление / удаление пользователя из курса повлечет за собой обновления только таблицы user_courses. Новый пользователь: добавить запись, старый пользователь: удалить запись. Каждое соединение пользователь / курс получает ОДНУ запись для себя в user_courses, и вы все еще можете довольно легко выполнять подсчет.

Внедрение разделенных запятыми значений в поле сводит на нет всю цель реляционных данных. Вы теряете возможность связывать данные друг с другом, потому что ваши приятные чистые пользовательские <-> отображения курсов находятся в этом большом куске цифр / запятых, которые БД не может интерпретировать для вас.

Answer 2

Я бы сделал три таблицы. userInformation, courseInformation и userCourseInformation. userCourseInformation сохранит, какой пользователь и какие курсы посещает.

userInformation
user_id, user_name, etc..

courseInformation
course_id, course_name, etc..

userCourseInformation
user_course_id, user_id, course_id, etc..

Все записанные курсы идут по userCourseInformation и ссылаются на две другие таблицы id как внешние ключи. Если вы хотите предложить новый курс, вы добавляете его к courseInformation. Добавьте нового пользователя, создайте нового userInformation. Большинство ОБНОВЛЕНИЕ / УДАЛЕНИЕ / ВЫБОР произойдет на userCourseInformation, как студенты приходят и уходят. Вы также можете просто использовать флаг (логический), чтобы показать, активен или нет. Это означает, что вы всегда можете вернуться и посмотреть на прошлые данные.

Answer 3

Если у вас есть отношение «многие ко многим» (например, курсы для студентов), вам, как правило, следует использовать таблицу между ними. То есть у вас должен быть свой стол для курса, стол для ученика, а затем стол для ученика курса (или стол для зачисления). Таблица регистрации может выглядеть следующим образом:

Id | Student | Course | Grade    |
1  | A       | 10     | Pass     |
2  | B       | 10     | Fail     |
3  | A       | 12     | Withdraw |

Здесь показан студент А на двух курсах (10 и 12) и два студента (А и В) на курсе 10. Преимущество такого подхода заключается в том, что вы можете хранить данные, относящиеся к зачислению, такие как оценки или прохождение / отказ (как показано в примере).

Answer 4

Я бы предложил создать объединенную таблицу между users и courses.Использование поля, разделенного запятыми, довольно неприятно для того, что вы здесь делаете.

Пользователи:

user_id | user_name | ...

Курсы:

user_id | course_name | ...

User_Course_Union

union_id | user_id | course_id | ...

Тогда вы можете легко выполнять запросы на основе SELECT COUNT(union_id) AS count WHERE ... и получать все необходимые данные.