Здравствуйте, помогите понять, какая должна быть модель базы данных? Я хочу, чтоб каждый пользователь, моего тестового приложения, мог создавать собственный список дел, помимо нескольких стандартных (списков).
Связь, между юзером и его делами, более-менее понятно . А вот, как разбить дела по спискам? Например каждый по стандарту должен иметь такие списки Day, Month, Year и еще иметь возможность создать свой список.
Как я понимаю, должна быть отдельная таблица, а в ней 2 колоки (Id и name) и потом на каждое дело, в таблицу дел, просто присваивать id списка, через FK?
А потом, что мне кажется самым странным. В проекте я создаю класс TaskType (наверно не лучшое название, пробывал TaskList, но с геттерами и сеттерами в классе получается путаница), и если я хочу получить все списки юзера,
я должен создавать в репозитории, сервисе такой метод как List getAll(int userId);
Не смотря, на то что мне нужны просто именна, будет создаваться целый класс? Тоисть в моём проекте, с использование MVC, я ради этого должен создать кучу интерфейсов и кучу классов?
Еще, вот в чём главная сложность, у меня в репозитории есть метод, получить все списки пользователя
List getAll(int userId);
Как я могу получить стандартные Day, Month, Year списки, если дел у юзера еще нет? А взять с таблицы листов не могу, так как в ней только (ид и name) и она для всех пользователей.
У Вас не сильно нагружена операционная часть (создание, изменение, удаление задач пользователя), поскольку самих задач у пользователя много не бывает. В сутках только 24 часа, и в году только 365 дней. Гораздо бОльшая нагрузка падает на поиск и фильтрацию списка задач (или дел, как Вы это назвали).
Возможным решением будет многомерное представление данных. Например, по схеме "звезда": есть таблица задач и несколько таблиц измерений, по которым можно проводить выборку (пользователь, тип задачи, проект или категория задачи, место встречи, дата и время и т.п.). Это требует некоторой денормализации и бОльших затрат на операции с отдельными записями, но упрощает агрегацию и выборку списков.
Кстати, я бы дату в таблице измерения по дате задачи хранил не как единое поле, а в отдельных полях дату, месяц, год. Как минимум. Это сильно упрощает работу с многомерными данными.
Благодарю за ответ! Выглядит неплохим решением. Сейчас мало что про неё знаю, но буду искать инфу и пробовать построить своё приложение, именно по этой схеме.
Простой
Сложный