Как спроектировать базу данных многопользовательских списков?

Question

[vovchik3003]

Представьте, что вам надо создать многопользовательский сервис со списками задач, то есть каждый юзер может зарегистрироваться и создавать свои списки с задачами. Так вот хочу спросить для таких целей создать 1 табличку со всеми целями и просто делать выборку по юзеру, но тогда такая таблица разрастется очень сильно и запросов будет к ней очень много (вообще на сколько это критично и какие размеры таблицы уже считаются не оптимальными?) или второй вариант сделать под каждого юзера таблицу, но тогда будет много одинаковых таблиц и за раз все изменить (например, добавить новый столбец) будет сложно.

Answer 1

[Денис Смирнов]

Про второй вариант вообще забудьте, это какой-то адский антипаттерн. Насчёт первого варианта - не волнуйтесь про размер, индексы спасут вас. А вот когда они перестанут вас спасать, вы воспользуетесь шардингом... но к этому моменту вы будете знать про большие данные больше всех в этом обсуждении)) Я бы создал таблицу с пользователями, таблицу с задачами и таблицу соответствия пользователей и задач с составным первичным ключом по этим двум колонкам. И не забыл бы про внешние ключи. Индексы бы делал в обеих таблицах типа автоинкрементируемого bigint (не знаю в терминах mysql) для более компактных и быстрых индексов по сравнению с guid. Если бы это был postgresql, то можно было бы таблицу трансляций сделать вида (пользователь, массив задач), но это плохая практика в плане согласованности данных.

Answer 2

[Roman K]

какие размеры таблицы уже считаются не оптимальными

Допустим, несколько миллиардов

под каждого юзера таблицу

Почитай получше учебники по РСУБД.

Answer 3

[Adgh]

1 Табличка + пар­ти­ци­о­ни­ро­ва­ние и шар­динг