[Qgis-developer] table join

[Maurício de Paulo]

Hi,
Big performance issues are usually solved by setting the relationship inside
the DBMS architecture.
IMHO we could give the user two options:
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.
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.
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.
What do you guys think?
Mauricio de Paulo


On Tue, Dec 1, 2009 at 2:15 PM, Marco Hugentobler <marco at hugis.net> wrote:

> Hi All
>
> Isn't it much redesign work to make a model class out of QgsVectorLayer?
>
> Probably it would be enough to have a function in QgsVectorLayer that
> fetches
> features by attribute value. Then, at runtime, the layer that joins others,
> would call those functions and making the join transparent to users of
> QgsVectorLayer.
>
> For performance reasons, there should additionally be the possibility to
> create indices on vector layers for certain attributes. Such an index would
> not store the feature itself, only the relation between attribute value and
> feature id(s), ideally with the possibility to store large indices on disk.
>
> Just and idea...
>
> Regards,
> Marco
>
>
>
>
>
>
> Am Montag, 30. November 2009 22.11:47 schrieb Mailing Lists:
> > Hi Alex and others
> >
> > 8<---------------snip-----------------------------
> >
> > > I had contemplated this a little recently along similar lines. SQLite
> > > has a concept of IN-Memory databases. What if we created the procedure
> > > to put joins/relates (Any sql relationship) into an in memory DB, that
> > > way the procedure just needs to be re-run on project load. It would
> make
> > > accessing the "joined" tables fast and allow querying against them.
> >
> > As I commented on the ticket for table joins, I don't think this is
> > the way to go. There are several reasons for this:
> >
> > - if the joined table is very large it wont all fit in memory and will
> > ultimately cause a crash or a bogged down OS
> > - dba's will hate us for hammering their databases with full table
> > queries instead of paging
> >
> > I think that we should implement this using Qt's model view framework.
> > It provides a way to abstract data access, provides pagination, and
> > can be used in many contexts for 'free' e.g. list and table views.
> > Also if we use the built in database drivers for Qt they are easy to
> > hook up to a model. And we can create custom models for esoteric
> > datasources that are not directly supported.
> >
> > Our custom model can ad hoc fetch data from the related table as each
> > page is requested so the need for loading heaps of stuff into memory
> > can be avoided.
> >
> > Just my 5c
> >
> > Regards
> >
> > Tim
> >
> > > The Arc model has some really good and some really annoying features,
> > > particularly poor handling of many to many and the lack of a full SQL
> > > operations as join operators.
> > >
> > >
> > >
> > >
> > >
> > > Alex
> > > _______________________________________________
> > > Qgis-developer mailing list
> > > Qgis-developer at lists.osgeo.org
> > > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
>
> --
> Dr. Marco Hugentobler
> HUGIS - GIS programming and consulting
> Webereistrasse 66
> CH-8134 Adliswil
> marco at hugis.net
> http://homepage.hispeed.ch/hugis
> Technical Advisor QGIS Project Steering Committee
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20091201/ca8481ab/attachment-0001.html