У меня есть две таблицы, пользователь и программы. Теперь у меня есть, скажем, 5-10, программы и десятки тысяч пользователей, которые могут быть зарегистрированы в любой из программ (также могут быть записаны в несколько программ). Поэтому в случае отношений многих и многих людей я думал создать отдельную таблицу, например link_user_program, для хранения программ, в которые пользователь зачисляется.Дизайн базы данных для многих (нескольких) ко многим (на самом деле слишком многих) отношений
Но если у меня есть десятки тысяч пользователей и всего 10 программ, не будет ли это потреблять дополнительное пространство и увеличить время запроса, чем просто хранить программы, занесенные в таблицу пользователей (возможно, идентификаторы программ с разделенной запятой или логический столбец для каждой программы)?
Каковы плюсы и минусы вышеуказанных двух конструкций или есть лучшая альтернатива? Что делать, если в будущем могут быть добавлены новые программы (но все же намного меньше, чем количество пользователей)?
Прочитайте введение в реляционные СУБД и дизайн базы данных. (Это то, что ваш вопрос задает в качестве ответа.) Третья таблица - соответствующий дизайн. Вам явно нужно больше узнать о простом использовании РСУБД, прежде чем вы начнете беспокоиться о ручной оптимизации. – philipxy