For performance, no, we have no plans to read from such tables, but I don't see why we couldn't maintain such tables or at least, make it export-ready via API.

Export ready via API sounds like a plan, not having these mapping in the DB (redundant data that we want to keep in files)

Of course, ideally the API would be used for everything, now that the Live! plugin (#44) has an extensive API to return the data from the piwik_log_* tables.

Ok thanks for your reply.

For the purpose of discussion, I'm going to refer to this static data as System Tables.

We could add an API method for each system table in the closest/corresponding plugin, e.g., PluginName.getSystemTableName($parameters_if_any) for:

• SitesManager: Currencies
• UserCountry: Countries, Continents
• LanguagesManager: Languages, LanguageToCountry
• Referers: SearchEngines
• UserSettings: Browsers, OperatingSystems, Plugins, Screens

Example: SitesManager.getCurrenciesSystemTable()

We could also have API.getSystemTableMetaData().

System Tables are not required for any use of the API, since the API gives friendly name in output.

System tables are only used for low level SQL requests. I think API.getSystemTableMetaData() is less code & better to have all in 1 place, since one typically needs all system tables or none. Maybe named getSystemTables() ?