Здравствуйте.

Значить хочу спросить, что в этом случае можно-бы сделать.

Проблама:
Хочу изобразить очень большую базу данных в JTable размер строк которой > MAX_INTEGER

При таком случае естественно нужно сделать кешенирование и написать класс унаследуемый от AbstractTableModel. По этому делу есть неплохая статья тут.

Суть проблемы:

где rowCount являеться как BigInteger (или  Long).



Вот что тут делать  

Добавлено @ 01:43
P.S.
На ум приходит только переписать AbstractTableModel, что за собой может повести переписку JTable и другие неприятные моменты.
А что Вы думаете?

Это сообщение отредактировал(а) Ccoder - 9.8.2011, 01:52

Насколько мне известно, есть компоненты Jide Grids (платные), которые могут деражать в себе данных больше, чем MAX_INT. Но точно не уверен. Их можно попробовать бесплатно.

Думаю, в таком случае лучше просто не выводить сразу все-все строки. И использовать обычный JTable. Можно поинтересоваться, зачем такая необходимость выводить сразу все?

По юзабилити напоминает ночной горшок с ручкой на дне. Чтобы эффективно работать с миллиардами строк в любом случае нужны поиск и фильтрация. Гораздо проще показывать сразу результаты фильтра\поиска и не решать проблему отображения заведомо неоперабельных данных. 

Я думаю, что для начала надо посчитать объем памяти, которая понадобится, чтобы просто удержать данные в модели. MAX_INTEGER - это 2Гб. Пусть строка таблицы состоит из одного элемента - строки длиной 5 символов. Тогда мы имеем на строку таблицы по минимуму 10 байт на данные (массив символов) + 8 байт на объект (если я правильно помню) + 12 байт на организацию строки (длина, смещение, ссылка на массив символов) + 4 байта на ссылку на строку в модели. Итого - 34 байта. Это абсолютный минимум. Умножим на 2Гб строк - и получим 68Гб - ШЕСТЬДЕСЯТ ВОСЕМЬ ГИГАБАЙТ!!! - памяти.

Ccoder, Вы все еще хотите показывать всю таблицу, или же перейдете к обдумыванию постраничного просмотра?

Это сообщение отредактировал(а) Skipy - 10.8.2011, 10:51

Skipy, 

Если почитать ссылку, которую дал ТС, то там проблема с памятью худо-бедно решается. А вот юзабилити таблицы с миллиардами строк - вещь очень смонительная.

Проблема с памятью в этой статье решается именно худо и бедно. Перенос 68Гб на диск скажется на производительности волшебным образом. В смысле, нужно будет волшебство, чтобы это приемлемо работало. И в первую очередь - в плане быстродействия (что входит в юзабилити). Для быстрой работы необходимо будет создавать индексы, средства быстрого поиска, - т.е., по сути, повторять базу данных. А в памяти будет тем временем храниться только часть - страница.

Ну и нафига повторять базу, если можно использовать исходную? Грамотно организованная модель, опирающаяся на исходную базу, даст всё то же самое, только без дополнительного кеширования. Это в теории.

А на практике остается открытым вопрос - автор, какому пользователю Вы хотите предоставить возможность читать более двух миллиардов строк? Покажите пользователя, который это сделает! Справка - при просмотре одной записи в секунду на это уйдет 68 лет непрерывного просмотра. 

2Гб строк не нужно никому и никогда. Мы у себя в продукте, при наличии постраничного выбора, тем не менее при превышении размера выборки 1000 строк вообще не выводим результаты и предлагаем сузить критерии поиска. Потому что прекрасно понимаем, что даже 1000 строк никто не будет просмотривать. А Вы хотите выдать 2Гб... Вы себе производительность такой выборки из базы представляете? Сколько нужно времени на это? Вас не линчуют за такие времена ожидания?

Хочу сказать спасибо всем ответившим, особенно Skipy. (поставте ему заслуженный плюс за меня)



Не я пока только интересуюсь. (сразу надо было-бы мне сказать)
Я думаю мне пока что хватит всё пересмотреть что вы написали. Спасибо.