Помогите БД и изобретатель велосипедов

[lolifrag]

В процессе изучения java я дошёл до работ с базами данных. Ради примера делаю плагин на точки домов. В конечном итоге у меня появился целый набор данных, с которыми мне нужно работать.
Допустив, что на неком гипотетическом сервере будет играть ~100 юзеров, я подсчитал что возможно массивы данных, которые будет грузить плагин окажутся очень большими, что возможно может сказаться как-либо на сервере (возможно и нет). Плюс к тому же, так как я делаю плагин для себя, то пусть будет так как удобно мне, то есть стандартное

PlayerName
  UUID:
  Location:
  ...

мне явно не подходит. Прикинув, я составил таблицу и тут наткнулся на то, что работать с ней очень даже не удобно, по крайней мере в ручную. Погуглил я про базы данных, почитал, но чё-то я не догоняю немного как с ними работать. Поэтому я решил отложить немного дома и пробнуть сделать свой мини инструмент для работы с бд.
Суть в том, что я задаю количество столбцов, могу менять их количество, могу получить все данные одного столба или хешмап из нескольких, обновлять и сохранять его. Возможно я изобретаю велосипед=)

В чём собственно мой вопрос: есть ли какие-нибудь особые тонкости при работе плагина, точнее взаимодействия сервера с базами данных? Или простого чтения файла (построчный цикл занесения в копии объекта всех данных) достаточно?

 

[kirill2011s]

Асинхронность

 

[ql_Nik_lp]

массивы

Если речь идет действительно о массивах - забудь о них.

~100 юзеров

очень большими

Если ты имел ввиду 100 миллионов юзеров - да. Для сервера даже пять тысяч итераций - работа не сложная (Если ты конечно не производишь ее каждые 5 мсек)

В чём собственно мой вопрос: есть ли какие-нибудь особые тонкости при работе плагина, точнее взаимодействия сервера с базами данных? Или простого чтения файла (построчный цикл занесения в копии объекта всех данных) достаточно?

1) Если записей у тебя до нескольких тысяч - храни захешированную БД в плагине и с ней работай. В базу обращайся только при записи и удалении
2)

Асинхронность

3) Всегда проверяй подключение перед работой с базой.

Если же тебя интересуют инструменты, то варианта 3
1) Руками совсем (Пишешь запросы и т.д.)
2) Тоже самое но через через Bukkit (Использует настройки базы из bukkit.yml)
3) Одно из двух выше но с использованием ORM

 

[lolifrag]

Если ты имел ввиду 100 миллионов юзеров - да. Для сервера даже пять тысяч итераций - работа не сложная (Если ты конечно не производишь ее каждые 5 мсек)

Самый обычный цикл for для строк с 0 до N (их количества), я не знаю какой у него интервал работы)

Храни захешированную БД в плагине

Записей думаю до сотен четырёх, может пяти максимум.
Не понимаю, ты имеешь ввиду что бы выделить в каком-то из классов или отдельный класс и использовать его для хранения?

Асинхронность и проверка подключения пока вне моих познаний. Я знаю только три вещи: есть сейв, данные корректны; есть сейв, данные не читаются; нет сейва. Беру сейв и гружу в память. Потом периодические автосохранения и финальное сохранение при выключении сервера