Hi,<br>Big performance issues are usually solved by setting the relationship inside the DBMS architecture. <br>IMHO we could give the user two options: <br>1- Creating a method in the vectordataprovider to build database-based relationships (as does ArcGIS, building relationship tables) and it wouldn't change the already existing code. The only difference would be that the user would load a view or a query, depending on the DBMS. QGIS already support some queries on it's data fetching.<br>
2- Creating on-the-fly relationships. These are a bit nasty as they eat up much memory and system performance. AND, I don't think it would be easy to implement as it would change how our vectordataprovider reads it's features. This relationship should be qgis-based as it must allow the user to relate data in different DBMS. I don't have a clear solution on how to implement this. Maybe changing the attribute methods inside vectordataprovider so that it also shows the other attributes.<br>
With the two options the user would be able to join data from the same DBMS with high performance and data with mixed DBMS with low, but easy, perfomance. <br>What do you guys think?<br>Mauricio de Paulo<br><br><br><div class="gmail_quote">
On Tue, Dec 1, 2009 at 2:15 PM, Marco Hugentobler <span dir="ltr"><<a href="mailto:marco@hugis.net">marco@hugis.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi All<br>
<br>
Isn't it much redesign work to make a model class out of QgsVectorLayer?<br>
<br>
Probably it would be enough to have a function in QgsVectorLayer that fetches<br>
features by attribute value. Then, at runtime, the layer that joins others,<br>
would call those functions and making the join transparent to users of<br>
QgsVectorLayer.<br>
<br>
For performance reasons, there should additionally be the possibility to<br>
create indices on vector layers for certain attributes. Such an index would<br>
not store the feature itself, only the relation between attribute value and<br>
feature id(s), ideally with the possibility to store large indices on disk.<br>
<br>
Just and idea...<br>
<br>
Regards,<br>
Marco<br>
<br>
<br>
<br>
<br>
<br>
<br>
Am Montag, 30. November 2009 22.11:47 schrieb Mailing Lists:<br>
<div><div></div><div class="h5">> Hi Alex and others<br>
><br>
> 8<---------------snip-----------------------------<br>
><br>
> > I had contemplated this a little recently along similar lines. SQLite<br>
> > has a concept of IN-Memory databases. What if we created the procedure<br>
> > to put joins/relates (Any sql relationship) into an in memory DB, that<br>
> > way the procedure just needs to be re-run on project load. It would make<br>
> > accessing the "joined" tables fast and allow querying against them.<br>
><br>
> As I commented on the ticket for table joins, I don't think this is<br>
> the way to go. There are several reasons for this:<br>
><br>
> - if the joined table is very large it wont all fit in memory and will<br>
> ultimately cause a crash or a bogged down OS<br>
> - dba's will hate us for hammering their databases with full table<br>
> queries instead of paging<br>
><br>
> I think that we should implement this using Qt's model view framework.<br>
> It provides a way to abstract data access, provides pagination, and<br>
> can be used in many contexts for 'free' e.g. list and table views.<br>
> Also if we use the built in database drivers for Qt they are easy to<br>
> hook up to a model. And we can create custom models for esoteric<br>
> datasources that are not directly supported.<br>
><br>
> Our custom model can ad hoc fetch data from the related table as each<br>
> page is requested so the need for loading heaps of stuff into memory<br>
> can be avoided.<br>
><br>
> Just my 5c<br>
><br>
> Regards<br>
><br>
> Tim<br>
><br>
> > The Arc model has some really good and some really annoying features,<br>
> > particularly poor handling of many to many and the lack of a full SQL<br>
> > operations as join operators.<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Alex<br>
> > _______________________________________________<br>
> > Qgis-developer mailing list<br>
> > <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> > <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
><br>
<br>
--<br>
</div></div>Dr. Marco Hugentobler<br>
HUGIS - GIS programming and consulting<br>
Webereistrasse 66<br>
CH-8134 Adliswil<br>
<a href="mailto:marco@hugis.net">marco@hugis.net</a><br>
<a href="http://homepage.hispeed.ch/hugis" target="_blank">http://homepage.hispeed.ch/hugis</a><br>
Technical Advisor QGIS Project Steering Committee<br>
<div><div></div><div class="h5">_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br>