Проектировка базы даних.

Очень толсто.

Это небезопасно. Ни в коем случае нельзя разных пользователей помещать в одну базу. Твоё решение будет уязвимо к атакам на переполнение базы данных. Если тебя на этом поймают, то это капец не только курсовику, но ты будешь тащить это клеймо позора до конца своих дней.

На самом деле грамотные проектировщики баз данных выносят пользователей в отдельные базы данных, это обеспечивает возможность разделения полномочий средствами системы управления базой данных и, что немаловажно, возможность масштабирования системы по мере увеличения пользовательской базы и реализации high-availability конфигурации на основе имеющейся инфраструктуры.

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

На сегодняшний день, учитывая накопленный опыт, можно с уверенностью сказать, что любой проект, предполагающий более одного пользователя на базу данных - автоматически обречён на провал. Поэтому даже не заикайся никому, что ты хотел пользователей объединить в рамках одной БД, пусть и в разных таблицах.

Очень толсто.

Ну ты не справедлив, скорее всего топик-стартер просто впервые столкнулся с проблемой, не знаком с проблемами, озвученными выше другим анонимусом и поэтому стремится напихать пользователей в одну базу данных. Возможно ему такое решение даже кажется слишком сложным для его задачи, хотя известный однострочник, решающий все проблемы, на ЛОРе уже лет десять назад как опубликовали.

1. Берем графовую базу данных 2. ??? 3. Profit

Берем графовую базу данных

Кстати да, вполне современное решение - изолировать каждого пользователя в собственной графовой базе данных, что позволит свести к минимуму недостатки других подходов, которые то и дело демонстрируют незадачливые проектировщики, незнакомые с современными подходами к проектированию многопользовательских вычислительных комплексов.

по прогнозам не будет много отношений между пользователями. Табличка/таблички друзей и все. Остальную часть я хочу перевалить на кеш, т.к она временная.

Поэтому создавать для каждого пользователя свою базу, я не вижу особого смысла. Но я вижу проблему в росте одной таблички.

Никто не мешает тебе создавать базы в разных файловых системах. Допустим у тебя тысяча пользователей не имеет вообще друзей, сто имеют по тысяче друзей, а десять - по миллиону. Ну и распихиваешь их графовые базы данных по разным файловым системам, ведь каждая из трёх категорий поторебует примерно однакового дискового пространства в сумме. А если пользователь вдруг начинает обрастать друзьями - переносишь его базу в более подходящий раздел твоего кластера.

Поэтому создавать для каждого пользователя свою базу, я не вижу особого смысла.

Они же стебутся над тобой.

http://qntm.org/gay

man MariaDB

Тебе не совестно за такие советы? Он же не графовая.

Совестно, но у меня есть оправдание: ТЗ четче нужно описать

http://en.m.wikipedia.org/wiki/Relational_algebra

Советую тебе прочитать учебник по сабжу, без него ты курсач свой завалишь.

http://grimoire.ca/mysql/choose-something-else относится и к MariaDB. Не надо её советовать как дефолтную.

А если хотел потроллить — есть же монга.

О пасиба, сегодня с чаем под пледом прочитаю :))

есть же монга

Я уже многое читал про монгу.

Я хоть только и познаю мир БД, но в NoSQL меня больше всего привлекает CouchDB

О пасиба, сегодня с чаем под пледом прочитаю :))

Ирония в том, что даже чтение умных изысканий о том, почему нельзя использовать MySQL - это тоже напрасная трата времени и мозгов на MySQL, чего призывает не совершать автор текста по ссылке. Правительства всего мира должны объединиться и запретить MySQL чтобы как-то остановить распространение этой заразы, ежесуточно бессмысленно убивающей тысячи часов жизни людей.

Потому что оно инфицировано Oracle?

Но есть же коммунистический MariaDB?))

Ладно. Понял. Ты должен потерять этот час жизни и вдумчиво прочитать тот текст.