Динамическое определение table для entity

@StudentJava · Регистрация: 24.01.2017

Студворк — интернет-сервис помощи студентам

Доброго дня, уважаемые знатоки, не подскажите как мне реализовать вот такую штуку.
у меня есть entity Quotes которая собой представляет котировку финансового инструмента

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class Quotes implements FinancialEntity{
    
    private Integer id;
 
    @Enumerated(EnumType.STRING)
    private Сurrency currency;
 
    @Enumerated(EnumType.STRING)
    private Period period;
 
    @JsonFormat
        (shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd HH:mm")
    @Convert(converter = LocalDateTimeConverter.class)
    private LocalDateTime data;
 
    private BigDecimal open;
 
    private BigDecimal close;
 
    private BigDecimal high;
 
    private BigDecimal low;
}

и вот у меня вопрос, помечая аннтоацией @Table я жестко привязываю эту entity к таблице, дальше я возьму в spring data jpa репозиторий и у меня все будет замечательно, но лишь до той поры пока у меня один финансовый инструмент. То как я бы хотел это реализовавать это так:
в зависимости от значения в поле enum currency мне хотелось бы сохранять в ту или иную таблиц. формально да, можно было бы наплодить кучу классов к примеру AUDUSD, EURUSD и тд. на каждый создать репозиторий и... но ведь это ад адовый, может быть есть какое то более правильное решение?
Спасибо за помощь.

@neske · 21.05.2018, 17:15

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

@xoraxax · 21.05.2018, 17:21

зачем одно и то же сохранять в разные таблицы, если можно сохранить в одну?

@StudentJava · 21.05.2018, 21:03 **[ТС]**

Сообщение от neske

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

а у меня ни какой связи между таблицами нет. каждая таблица в моем представление это набор котировок по отдельно взятой валютной паре (всех таймфреймов). Если честно, я не совсем понял, что значит неизвестная валюта... это как? Если Вы имеете в виду, что надо будет добавить еще одну, пока еще не известную мне? ну, при такой архитектуре это проше простого - добавляешь таблицу / добавляешь entity / добавляешь репозиторий... все так просто, только если у меня инструментов будет 56 это просто ад адовый.
нет смысла, согласен, наверное нет, просто меня смущает... у меня данных по каждому инструменту получается около 0,8гб * 56 .. не знаю как это будет себя вести в одной таблице и как быстро(медленно) будет осуществляться поиск по ней.

Добавлено через 2 минуты

Сообщение от xoraxax

зачем одно и то же сохранять в разные таблицы, если можно сохранить в одну?

спасибо за вопрос. я ответил выше. у меня получается порядка 40 с лишним гб данных и мне становится немного не по себе от того, что все это будет в одной таблице... впрочем можно поэкспериментировать и посмотреть как это будет... если все это в одной таблице, потом добавить индексов - посмотреть, потом потестировать mongo интересно, будет ли она быстрее на таком объеме.

@xoraxax · 21.05.2018, 21:11

мне кажется, для этого есть более подходящие хранилища, чем реляционная БД. А если у тебя там сотни гигабайт то может есть смысл на hadoop, например, посмотреть или на спарк

@StudentJava · 21.05.2018, 21:17 **[ТС]**

Сообщение от xoraxax

мне кажется, для этого есть более подходящие хранилища, чем реляционная БД. А если у тебя там сотни гигабайт то может есть смысл на hadoop, например, посмотреть или на спарк

может быть, просто, я его пока знаю чуть меньше, чем чуть чуть, посмотрю, наверное, как ведет себя mongoDB, но все таки ))) вопрос был изначально - можно ли динамически определять в какую таблицу (SQL) я буду сохраниять свою entity (в зависимости от значения поля) )) просто с 0,8 гб sql база норм справляется (ну, я не супер тюнер, так что даже из коробки postgres меня с таким объемом удовлетворяет более чем) а вот запихать все в одну базу... чет я пока не пробовал и почему то мне показалось это не очень правильным решением.

@KEKCoGEN · 21.05.2018, 22:11

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

@StudentJava · 21.05.2018, 22:16 **[ТС]**

Сообщение от KEKCoGEN

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

гран мерси. уже начал тестировать.

Новые блоги и статьи Все статьи Все блоги /
Модульный подход на примере F# DevAlt 06.03.2026 В блоге дяди Боба наткнулся на такое определение: В этой книге («Подход, основанный на вариантах использования») Ивар утверждает, что архитектура программного обеспечения — это структуры,. . .	Управление камерой с помощью скрипта OrbitControls.js на Three.js: Вращение, зум и панорамирование 8Observer8 05.03.2026 Содержание блога Финальная демка в браузере работает на Desktop и мобильных браузерах. Итоговый код: orbit-controls-threejs-js. zip. Сканируйте QR-код на мобильном. Вращайте камеру одним пальцем,. . .	SDL3 для Web (WebAssembly): Синхронизация спрайтов SDL3 и тел Box2D 8Observer8 04.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-sync-physics-sprites-sdl3-c. zip На первой гифке отладочные линии отключены, а на второй включены:. . .	SDL3 для Web (WebAssembly): Идентификация объектов на Box2D v3 - использование userData и событий коллизий 8Observer8 02.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-collision-events-sdl3-c. zip Сканируйте QR-код на мобильном и вы увидите, что появится джойстик для управления главным героем. . . .
Реалии Hrethgir 01.03.2026 Нет, я не закончил до сих пор симулятор. Эта задача сложнее. Не получилось уйти в плавсостав, но оно и к лучшему, возможно. Точнее получалось - но сварщиком в палубную команду, а это значит, в моём. . .	Ритм жизни kumehtar 27.02.2026 Иногда приходится жить в ритме, где дел становится всё больше, а вовлечения в происходящее — всё меньше. Плотный график не даёт вниманию закрепиться ни на одном событии. Утро начинается с быстрых,. . .	SDL3 для Web (WebAssembly): Сборка библиотек: SDL3, Box2D, FreeType, SDL3_ttf, SDL3_mixer и SDL3_image из исходников с помощью CMake и Emscripten 8Observer8 27.02.2026 Недавно вышла версия 3. 4. 2 библиотеки SDL3. На странице официальной релиза доступны исходники, готовые DLL (для x86, x64, arm64), а также библиотеки для разработки под Android, MinGW и Visual Studio. . . .	SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .

@neske 1552 / 918 / 193 Регистрация: 26.03.2010 Сообщений: 3,105
	21.05.2018, 17:15
	если я все правильно уловил, то ад адовый это именно то, что описано) нету никакого смысла делить котировки на разные таблицы по валюте, что в орм моделе, что в sql. Интересно, как ты планируешь другие таблицы линковать сюда с такой архитектурой, к примеру когда еще одна таблица должна будет содержать линк на котировку, с неизвестной валютой естественно 0

@xoraxax 3639 / 2971 / 918 Регистрация: 05.07.2013 Сообщений: 14,220
	21.05.2018, 17:21
	зачем одно и то же сохранять в разные таблицы, если можно сохранить в одну? 0

@xoraxax 3639 / 2971 / 918 Регистрация: 05.07.2013 Сообщений: 14,220
	21.05.2018, 21:11
	мне кажется, для этого есть более подходящие хранилища, чем реляционная БД. А если у тебя там сотни гигабайт то может есть смысл на hadoop, например, посмотреть или на спарк 0

@KEKCoGEN 2399 / 2224 / 565 Регистрация: 28.12.2010 Сообщений: 8,672
	21.05.2018, 22:11
	StudentJava, выше верно сказали. Нет смысла делить на таблицы только из-за кол-ва данных. Для этого у БД есть свои фишки типа партишнинга и.т.д. Если очень волнует объем данных, используй какую нибудь монгу 0