Дерево и плоский список

Приветствую всех. Прошу помощи советом с организацией размещения данных, что-то приходящие мне в голову идеи кажутся мне некрасивыми. Реализую все на С++ + Qt 4.4.3, что, впрочем, особого значения не имеет. Вот что, собственно, имеем:
Массив объектов Client, в гуе он также отображен в QTableWidget
В каждом Client есть массив объектов Invoice, в гуе он также отображен в QTableWidget свой
С клиентами все понятно, GUI просит, скажем, отредактировать Client с индексом 5 - вытаскиваем из массива, редактируем, кладем обратно под тем же индексом. Только вместо массива я использую QList, но не думаю что это особо на что-то повлияет, так как проблема-то не с тем как с этими классами Qt работать и не с классами вообще. Но, получаем мы комманду с GUI о том, что нужно отредактировать счет (Invoice) с индексом скажем 10. Но ведь GUI видит счета как плоский список, а реально имеем дерево. Под индексом я подразумеваю собственно индекс элемента в массиве, ну в случае с GUI и QTableWidget это tableInvoices->currentRow().

Мне же, фактически, для того чтобы отредактировать счет, требуется знать не столько его индекс в плоском списке, сколько индекс клиента в массиве клиентов и индекс счета в массиве счетов этого клиента. Первой мыслью было вести массив размером с кол-во счетов в плоском списке, где по индексу счета в плоском списке можно было бы из этого массива вытащить индекс клиента в массиве клиентов и индекс счета в массиве счетов клиента. Но клиент может быть удален и тогда вся эта таблица отношений поедет - пропадет клиент с индексом 5, туда же отправятся все его счета - значит все индексы клиентов, которые были в массиве с индексом большим 5 сместятся на 1 позицию в сторону уменьшения индекса. Да, можно пробегаться по массиву соответствия индекса счета с клиентом и делать в них clientIndex--, что собственно мне и кажется кривым.

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