Загрузите исходный код для SQuirreL SQl и посмотрите на реализацию таблицы.
Некоторые вещи на заметку:
Таблицы базы данных не являются Java JTables. Таблица в базе данных на самом деле является набором (проклинайте дурака, который использовал неправильный термин) с элементами, и у каждого элемента есть свойства (обычно называемые «столбцами», которые не являются JColumn, что объясняет, почему их так сложно сопоставить) .
Набор может вырасти до любого размера. У него нет внутреннего порядка. Вы можете выполнять множество операций над множествами, например: объединение, различие, подмножество.
Следовательно, не таблица, особенно таблица UI.
Не существует простой парадигмы пользовательского интерфейса, которая отображает «set» в «table». Вы можете
Загрузка N записей и просмотр результатов.
Вы можете загрузить больше, когда пользователь прокручивает вниз
Вы можете посчитать размер набора и настроить полосу прокрутки соответственно. Когда пользователь прокручивает данные, они извлекаются из БД и отображаются.
Плюсы + минусы:
Решение 1 является наиболее простым для реализации и тем, которое пользователи ненавидят больше всего. Почему им нужно ждать, чтобы увидеть данные снова, когда идти назад? Это особенно расстраивает, если каждый выбор занимает 15 секунд. Страница ... подожди ... страница ... упс! Там это было! Черт! Подожди, подожди, подожди ... назад ... подожди ... ааааа.
Кроме того, базы данных часто испытывают трудности с поиском данных. Для некоторых запросов производительность может быть катастрофической.
Решение 2 простое в реализации, особенно если вы можете держать ResultSet
открытым навсегда. Но 100% времени вы не можете. Он начнет терпеть неудачу, если вы будете держать его открытым в течение пары часов или дня. По истечении этого времени БД будет думать «о, он мертв, Джим» и закроет соединение, и ваш пользователь получит приятное сообщение об ошибке, и вы получите злой пользователя.
Так что вам тоже нужно побывать здесь, но не так часто. С другой стороны, пользователям не нужно снова ждать данных, которые у них уже есть. Один важный момент: если набор содержит миллионы строк, пользователи интуитивно понимают, что им нужно атаковать проблему под другим углом при прокрутке вниз. В конце концов, они устают и просят лучшего решения (вместо того, чтобы сердиться на вас, потому что ваша глупая программа не может отобразить 15 миллионов строк менее чем за 0,0000000001).
Решение 3 хуже, чем # 2, опять же. Если таблица будет расти, пользовательский интерфейс станет непригодным для использования: даже если смотреть на прокрутку, вы попадете в случайное место в таблице. Так что это делает вашу мышь бесполезной. А ваши пользователи злые.
Поэтому я обычно пробую решение, которое:
Читает 1000 строк, макс. Плюс я останавливаюсь после 100 строк (поэтому у пользователя есть хотя бы некоторые данные), если чтение строк занимает более 1 секунды. Обычно запрос выполняется медленно, и чтение результирующего набора практически не занимает времени, но мне нравится защищаться здесь.
Вверху каждого столбца находится фильтр и «порядок по», который можно сопоставить непосредственно с SQL. Таким образом, я могу убедиться, что если вы хотите, чтобы данные сортировались по столбцу, они сортируются по всем значениям (а не только по тем, которые вы видите на экране).
Это позволяет пользователям разделять огромные объемы данных на значимые подмножества.