LINUX.ORG.RU

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

 


0

3

Есть пользователь. У пользователя есть друзья. У меня два варианта:

Первый: одна таблица.

user | friends
1         2
1         3
1         4
1         5
2         1
2         3
2         6

Второй: для каждого пользователя своя таблица в базе. И соответственно нужно своя база. Количество друзей неограниченно.

Как лучше? Еще варианты?

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

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

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

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

anonymous ()
Ответ на: комментарий от postman_

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

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

anonymous ()

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

henewuge ()
Ответ на: комментарий от henewuge

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

anonymous ()
Ответ на: комментарий от henewuge

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

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

proud_anon ★★★★★ ()
Ответ на: комментарий от bookman900

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

anonymous ()
Ответ на: комментарий от anonymous

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

bookman900 ★★★★★ ()
Ответ на: комментарий от x3al

есть же монга

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

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

bookman900 ★★★★★ ()
Ответ на: комментарий от bookman900

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

bookman900 ★★★★★ ()
Ответ на: комментарий от bookman900

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.