(Untitled)

[n1919]

есть задача

Comments

[iq_21]

Если размеры таблиц известны и известно, что большая часть полей не будет пустовать,
то можно сделать просто двухмерный массив.

Или вариант 1 + два массива типа стринг для заголовков.

[n1919]

никакие размеры заранее не известны

[n1919]

"Или вариант 1 + два массива типа стринг для заголовков."

а вот это не понял, поясните плиз

[iq_21]

У вас табличка n x m вида

| b1 | b2 | ...|b_m
-----------------------
a_1 | 1.0| 2.0|
-----------------------
a_2 | 4.2| 10|
-----------------------
a_n | 3 | 0 |

она состоит из чисел {1.0.2.0,4.2 ....} и заголовков {a1 ... a_n}, {b1...b_m} по краям. Заголовки строчек и столбцов тоже нужно где-то хранить и лучше всего в ArrayList

[radio_radar]

http://makdns.blogspot.com/2011/08/matrix-report-using-sql-server-xml-and.html

[n1919]

неплохо, но по ряду причин, не подходит

[metaclass]

Эту хрень еще называют шахматной ведомостью или кросс-отчетом.
Я ее делал таким образом:
1) метаданные заголовков по X,Y - список описаний каждого заголовка, хранятся в том порядке, в котором группируются. В описании имя поля, формат и прочее по мелочи, типа "кастомная функция форматирования"
2) метаданные ячеек. список описаний каждого поля отображаемого в ячейке на пересечении. тоже - имя поля, формат, иногда функция аггрегирования.
3) данные заголовков: как и в предложенной модели, список списков
4) данные ячеек: как и в предложенной модели, Map из пары координат в список значений полей ячейки

[m_a_m_o_n]

Да, BIRT например умеет строить такие отчёты по выборке
SELECT x_name, y_name, sum(value)
FROM ...
GROUP BY x_name, y_name
ORDER BY x_name, y_name

P.S. это не значит что нужно его использовать.

[n1919]

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

[metaclass]

Сейчас загляну в код. Я там что-то мудрил с правильной сортировкой.
Да, я делал еще более злым образом, оказывается.
У меня на вход генератора отчетов передается три итератора - для значений X, для значений Y и для ячеек. Первые два нужны(но не обязательны) чтобы некоторые ячейки показывались даже если для них нету данных в списке ячеек.
А в качестве координат используются не индексы в массивах значений X и Y, а сами эти значения, специальным образом отформатированные, чтобы сортировались в правильном порядке. Т.е. при заполнении из итератора одновременно заполняются и заголовки и ячейки, сортировка не портится.

[n1919]

это таблица MxN
но M, N динамические (это раз)
каждый заголовок не строка, а запись (несколько полей)

пример -

[категория]
[товар]
[дата] [клиент] [сумма заказа]

аггрегирующие ячейки?
вообще да, есть
но данной структуре это должно быть по барабану

[chinoock]

Это кросстаблица, чемпионат по футболу, например.

Или, например, продажи товаров по регионам. Строки - товары, а столбцы - регионы. Но регионы - это тоже таблица, которая может меняться, так что количество столбцов неизвестно. Вот типа этого - http://www.basegroup.ru/deductor/screenshots/olap/cross_table/

PowerBuilder умел сам такие таблицы строить.

[pash7ka]

По п. 1 и 2 - вариантов, видимо нет.
А вот с 4-м вопрос: при рисовании таблички это-ж надо каждый индекс искать в мэпе... Как-то не быстро получается.
Может для 4 - тоже массивчики использовать - вида ArrayList ? (3 тогда не нужен)
Да, и может быть заменить ArrayList на обычный массив, если число полей всё-таки известно в момент заполнения всего хозяйства?
Конечно, если таблица по большей части пустая, то памяти много отъест... Зато никаких поисков по мапу.

[n1919]

массив не пойдет
см. выше

неизвестна размерность, пока не прочитан ResultSet

[pash7ka]

А COUNT() вызвать проблемно?
Тут надо думать что быстрее - один раз вызвать каунт или х-з сколько раз заниматься копированием памяти внутри ArrayList-а.