0

What is the core database system used by QGIS?

When you launch an existing project that has multiple .shp files (with associated .dbf tables), is the core db system used to convert that data to its own internal format as the project loads?

How about joining a simple CSV; does the core database have that import functionality, or does a Python script run independent of the core database, perform a conversion on the fly, then the core database takes the data from that script?

Once you have a project fully loaded, including a .shp file plus a .dbf, plus another CSV joined, are all the data in one common database system, so performance should be crisp and brisk? Or, does the system read in only the data needed to render the scale and scrolling you are at on the canvas, and continually re read that external CSV join as you zoom and pan around?

Suspect PostgreSQL at the core, or SQLite at the core? (So, any bug issues with those db systems will show through to QGIS?)

Are there any notes on import/export to the core database used, particularly any "rough spots" (CSV joins for instance, appears to trip many new users up.) Are those QGIS issues or the underlying db issue?

I see PosgreSQL is really Ingress (which lacked SQL), with nicely compliant SQL finally added (evolving to Post Ingress), with some object features added (including possibly spacial objects like point, line and poly)?

If PostgreSQL lies at the heart of QGIS, I'd expect performance "rotating" / manipulating relational data to be outstanding? (Ingress on pure relational data in its original form was outstanding as I recall... Do the "add ons" later on come at a cost of the core relational performance?

closed as too broad by Vince, John Powell, PolyGeo Feb 1 '16 at 21:53

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Why would it be necessary for any GIS software to have a "core database system" or if one did, how that would make datatbase operations suddenly "crisper"? This question doesn't align with the way software development, or database use, or even computing really works. Since QGIS is open source, you can review the code itself, to better see how it actually works. – Vince Feb 1 '16 at 12:44
  • Question is architectural. If there was a single, core database system, as part of the overall design, all data would need to be drawn into that structure first, and it would operate like a service to the UI and screen rendering componentry. All the data providers would then be responsible to that core db system alone. See ndawson comment below. CSV data, for example, here in QGIS works very “different”; its data provider works different. Advice to just look at the code is excellent! (but still need to know up front where to look: QGIS project, db project, ancillary provider project, etc.) – rjlabs Feb 1 '16 at 13:38
  • 1
    No one in the real world would architect software like that, which makes this a hypothetical question. – Vince Feb 1 '16 at 14:01
  • I don't understand. Model|View|Controller (Presentation|logic|data, etc.) is a viable real world architecture (e.g. Oracle-SAP, DB2-WebSphere, any database driven design.) Strikes me (but I may be wrong, been only looking at it for about a week) that QGIS is very much about the View (or Presentation - i.e. rendering the canvas, zooming, panning) and isn't (shouldn't ?) be overly concerned directly with the Model (data) and its management. Why not leave the data and its purely relational manipulation to a highly refined extrinsic db system? – rjlabs Feb 1 '16 at 18:45
  • 2
    MVC is too simplistic for the reality of GIS. It's foolish to map all data to one model, especially when not all data maps cleanly to that model, and especially when you can use it as-is faster than you can map it. QGIS is certainly not implemented according to a single core database model. A complete discussion of the past 30 years of GIS development is out of scope with the "Focused Question/Best Answer" model used here in GIS SE. – Vince Feb 1 '16 at 19:12
4

QGIS has its own internal handling of layers and features. Different data "providers" are used to pull layers in from a variety of sources (eg PostGIS, OGR file types, WFS servers, etc) and translate them into QGIS' own internal formats.

Once you have a project fully loaded, including a .shp file plus a .dbf, plus another CSV joined, are all the data in one common database system, so performance should be crisp and brisk? Or, does the system read in only the data needed to render the scale and scrolling you are at on the canvas, and continually re read that external CSV join as you zoom and pan around?

It's a bit of a mix. CSV for instance will import all the features and cache them using internal data structures, but also watch the source CSV for changes and update the internal structures accordingly. Other providers, eg PostGIS, will fetch features on demand (such as when panning the map or viewing attributes).

  • Question was - "QGIS - what is the core database system?" Above response was most helpful. Also Vince's comment -- "QGIS is not implemented to a single core database" -- concludes it. The initial question is therefore answered. Apparently the design rational for (no db system at the core) is either obvious to those more experienced in the history of GIS, or can't be easily "answered in a few paragraphs" here. – rjlabs Feb 2 '16 at 4:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.