0

QTreeView を作成して、SQL データベースのデータを表示しようとしています。これは大規模なデータベースであるため、単純にデータを QStandardItemModel にロードするのは不可能に思えます。

Qt のビルド済み SQL モデル クラスはどれも、このタスクに十分ではありません。したがって、QAbstractItemModel をサブクラス化する必要があるようです。

そもそもこれをやっている例が見当たらないので、正しいやり方なのか気になります。

QAbstractItemModel::data の実装は非常に簡単です。QAbstractItemModel::parent の実装方法がわかりません。

Qt の「Simple Tree Model Example」の例は参考になりますが、その例ではツリー構造は TreeItem クラスでメモリ内に表現されています。それをコピーすることもできますが、データベース構造を複製する場合は、QStandardItemModel を使用するのと同じくらい簡単です。ツリー構造を表すために (データベースと QAbstractItemModel サブクラスに加えて) 別のデータ構造を維持する必要がある場合、QStandardItemModel を使用するよりも QAbstractItemModel をサブクラス化する利点はありますか?

4

1 に答える 1

0

ツリー構造での課題は、常にモデル インデックスの親を識別できるようにすることです (つまり、parent() メソッドをオーバーロードします)。シンプル ツリーの例では、これは 3 つの構造を別のデータ構造に格納することによって行われます。大規模な SQL クエリの場合、これは実用的ではありません。適切なデータベース構造については、子から適切な親ノードを計算できる場合がありますが、それは保証ではありません。私が想像できる唯一の代替手段は、項目の親をエンコードする QAbstractItemModel::createIndex に quint32 を渡すことです。

役立つ可能性のあるパフォーマンスに関する考慮事項の 1 つ。QAbstractItemModel のサブクラス化をあきらめた後、データベースから QStandardItemModel を作成してみました。約 1200 のアイテムをモデルにロードし、2 つの別々のデータベース呼び出しで各アイテムに 4 つの子アイテムをロードしました。これには、2009 年のラップトップで約 3 秒かかりました。それは私が予想していたよりも速いです。(また、クエリを繰り返す代わりに単一のクエリを使用すると、パフォーマンスが向上します。)

最後に、私は別のルートに行きました。GUI に複数の QTableView を配置し、信号とスロットを使用してデータのさまざまな側面を表示しました。私のコードははるかに単純で、適切な機能が配置されているため、これは「正しい」ソリューションのように感じます.

于 2013-01-31T06:47:59.870 に答える