Кажется я неправильно все таки задал вопрос:)
1) да объект group не нужен.
2) Вот в целостности бд то вся проблема, мне как раз таки и нужны все фишки использования внешнего ключа на уровне базы и каскадное удаление, и невозможность вставить не правильный id. Но вот самое главное, я пытаюсь описать структуру с помощью аннотаций jpa, чтобы при первом запуске приложения хибернейт сам сгенерил структуру бд. И получается так что если не указать @ManyToOne и @JoinColumn, то предётся делать дополнительный sql скрипт который пропишет мне внешние ключи:) я конечно понимаю что в будущем мне не раз придется патчить базу после обновлений и изменений структуры, но на начальном этапе хотелось бы на этом не зацикливаться. Так как с помошью аннотаций можно описать практически все и индексы и ограничения на размер и все остальное)
Спасибо за ответ! Проблема в том, что мне нужна именно структура про которую я говорил, в силу специфики моей задачи. Странно то что в интернете я ничего подобного не нашел, хотя мне кажется такие идеи должны были у кого-нибуль возникнуть, хотя бы опровержение моей задумки. Вы можете с полной уверенностью сказать, что средствами хибернейта такое реализовать невозможно?
Спасибо за ответ! Нет такой вариант, как я уже писал, не подходит. 2- й вариант я тоже пробовал выдает "Repeated column in mapping for entity (should be mapped with insert="false" update="false")", его можно использовать, но поле изменять нельзя.
Я бы сравнил MongoDB с красивой популярной блондинкой, про нее пишут в прессе, внешне дико красивая и удобная(возможность хранить неструктурированные данные, удобное построение запросов), вся такая новая и необычная, и ты под впечатлением - "Ну все женюсь!")) а после свадьбы начинается самое интересное, твои расходы (оперативка) начинают увеличиваться со стремительной скоростью, ты выясняешь что тривиальные вещи типа готовки и глажки (транзакции, acid) она делать не умеет, также постоянные капризы и неприятные сюрпризы(потеря данных).. И ты такой пожил с ней месяц другой и решил пора брать в жены нормальную женщину, и возвращаешься к postgresql - которая ждет тебя дома, все чисто и наглажено, никаких проблем голова не болит, все деньги на месте и аккуратно сложены:))
Как я понял у вас вся логика выборки на стороне приложения выполняется? Т.е вы вначале из базы достаете по условию - "Выбираем все активные задачи, где старт меньше нужной даты и стоп равен нулю или больше нужной даты.", а затем уже на питоне высчитываете попадание и отсеиваете ненужное? Правильно я понял.
Я вот надеялся на то что есть способ сделать все это на стороне базы и на клиенте получить готовый данные)
Тогда у меня к вам еще вопросы))
Какое примерно количество юзеров и задач в вашей системе? и соответственно время выполнения выборки на ваших данных для среднестатистического запроса? если конечно вы подобные тесты делали.
Тоже думал над первым вариантом, но как вы уже и сказали нет возможности сделать выборку в будущем или прошлом
Второй вариант интересен, но вот только, как я понял объемы данных будут очень большие в таблице экземпляров. И еще при добавлении/изменении задачи нужно будет удалять и создавать все экземпляры? или я не совсем правильно понял идею.
пользователь создает себе задания и время их выполнения, например
"Помыть машину" - выполнить 1-го числа каждого месяца
или
"Уборка в квартире" - выпонять каждую неделю в субботу
Далее ему нужно выбирать задание по заданному промежутку, например за сегодня или за неделю, соответственно система должна проанализировать текущую дату с заданием и сделать выборку
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
