*SQL exportd module

Report a Bug/Enhancement
#1

i think a generic *SQL interface could be a nice way for exportd to integrate in a lot of external IT systems.
A lot of IT Systems use relational Databases like MariaDB, PostgresSQL and SQlite (yes… and MSSQL) to store Object-Data. It also can also be a multi-purpose interface for e.g. syncing data to a SQL backend for OTRS CMDB, asterisk-realtime or freeradius and many many more!

This could be the driver to enable DataGerry to achieve world domination. :wink:

1 Like
#2

Hi @andsch

thanks for your enhancement request. I opened an issue for that in our backlog:

  • [NET-364] Generic SQL plugin for Exportd

Just have a look at it. What do you think, do we need to support multiple database tables (that are combined with foreign keys) within one export?

#3

hrm… i think it’s hard to think about any tools and database model that can be integrated with a SQL exporter scheme.

But, in the end of the day everything is about simple 2-dimensional tables. The question is on which side you want to do the job to map komplex data to these tables!

What are the options:

  1. the database consists of one or more complete unnormalized tables -> Easy job because every value can be mapped 1:1 to a table.field tuple.
  2. the database consists of a lot of normalized tables: Now there are two choices:
  • a) you can create views in the SQL Server to map multiple normalized tables to a single unnormalized view.
  • b) the mapping to the database model can be performed by DataGerry itself. In this case some sort of “Object Relational Mapper” function has to be implemented into DataGerry.

I think by implementing a ORM, DataGerry would be capable to do any sync job you think about. But even with a simple 1:1 Field mapping and the use of SQL views it shold be possible do perform a wide range of jobs.