Как построить бд, подходящую для работы с большим количеством людей?

Question

[Мимокрокодил]

В рамках изучения Java я дошёл до JDBC, а точнее до MySQL*. Используя его я делаю приложение таск-менеджер. Пока там один только я, то всё понятно - хватит одной таблицы. Но что если там будет не 1, а, скажем, 100 или 10к людей? Как уместить все эти данные в одной таблице? Или нужно сделать главную таблицу со всеми пользователями и для каждого выделить свою отдельную таблицу, по которой уже искать данные выбранного пользователя?

Данные такие: INT-порядковый номер, VARCHAR-название, VARCHAR-описание, VARCHAR-теги(категории), TINYINT-срочность, BOOLEAN-статус, VARCHAR-список шагов, SMALLINT-прогресс выполнения, DATETIME-крайний срок.

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

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

* MySQL я выбрал после того, как просмотрел вакансии на junior java. Там чаще всего или MySQL или PostgreSQL. Я не вижу между ними большой разницы на данном этапе, поэтому выбрал наугад.

Comments

[Василий Банников]

* MySQL я выбрал после того, как просмотрел вакансии на junior java. Там чаще всего или MySQL или PostgreSQL. Я не вижу между ними большой разницы на данном этапе, поэтому выбрал наугад.

btw лучше взять постгрес, у него фич больше => можно будет во время изучения поиграться. + он полностью свободный, в отличие от mysql

Answer 1

[Василий Банников]

Как уместить все эти данные в одной таблице? Или нужно сделать главную таблицу со всеми пользователями и для каждого выделить свою отдельную таблицу, по которой уже искать данные выбранного пользователя?

Одна таблица для пользователей, а другая для задач.
Между ними - Foreign Key, который сопоставляет задачи и пользователей.

10к - это мало, так что даже не заметишь просадок.

Чтобы выборки делать быстрее - можно добавить индексы.

VARCHAR-теги(категории)

Категории имеет смысл вынести в отдельную таблицу и пусть будет связь Many-Many

TINYINT-срочность

А вот в постгресе можно было бы сделать ENUM :)

BOOLEAN-статус

А что у задачи может быть только два статуса? Для расширяемости стоит сделать это тоже енамом (строкой или числом)

VARCHAR-список шагов

Шаги тоже стоит вынести в отдельную таблицу и Связывать их с задачей

SMALLINT-прогресс выполнения

Типа текущий шаг?

Comments

[Мимокрокодил]

Спасибо за ответ.

[Василий Банников]

Богдан, дополнил ещё немного его

[Мимокрокодил]

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

Я изучаю бд и MySQL в частности только ради будущего трудоустройства. Не знаю, хочу ли я работать с бд очень тесно, но с этими знаниями у меня определённо будет плюсик в резюме. Лучше учить PostgreSQL?

[Василий Банников]

Богдан, Как я вижу - новые проекты чаще выбирают именно постгрес, так что да

[Мимокрокодил]

Василий Банников, спасибо вам ещё раз. Пошёл грызть гранит ̶н̶а̶у̶к̶и̶ PostgreSQL.