All Ticketmatic data is stored in a Postgres relational database. The tables in this database are not directly accessible. Ticketmatic instead provides a set of publicly available views on the database, called the public data model. The public data model gives you fine grained, low level access to the data stored in Ticketmatic. Access is limited to read-only. For higher level access or read/write access use the Ticketmatic API.

In order to retrieve data using the public data model, you use SQL queries. The supported sql syntax strongly conforms to the ANSI-SQL:2008 standard.

Using the public data model you can:

* create custom Filters * create custom Field definitions to be used in Views, Ticket layouts or Documents * create custom Reports * use the console to perform ad-hoc queries * perform ad-hoc queries through the API by using the [tools/queries api endpoint](api/tools/queries)

The views in the public data model are contained in the namespace tm, so you should use this as prefix to reference a view in the public data model, for example tm.pricetype.


The public data model is roughly structured in 4 parts:

* events, tickets and prices * orders and saleslog * contacts * settings

Events, tickets and prices

This part contains the information on the defined events, tickets and pricing. The most important views are:

* [tm.event](db/event) * [tm.tickettype](db/tickettype) * [tm.ticket](db/ticket) * [tm.pricetype](db/pricetype) * [tm.pricelist](db/pricelist) * [tm.tickettypeprice](db/tickettypeprice)

Orders and saleslog

This part contains the information on actual orders and sold tickets. The most important views are:

* [tm.order](db/order) * [tm.orderlog](db/orderlog) * [tm.payment](db/payment) * [tm.ticket](db/ticket) * [tm.saleslog](db/saleslog) * [tm.saleslogitem](db/saleslogitem) * [tm.batchprint](db/batchprint)


This part contains information on the contacts. The most important views are:

* [](db/contact) * [tm.contactaddress](db/contactaddress)


This part contains information on the settings. Some important views are:

* [tm.deliveryscenario](db/deliveryscenario) * [tm.paymentscenario](db/paymentscenario) * [tm.saleschannel](db/saleschannel)

Some examples

Below you will find some examples to get you started. Go to Settings -> Console to try out these examples for yourself.

To retrieve a list of all the Pricetypes available:

1select * from tm.pricetype

To retrieve a list of the last 10 payments:

2    id, 
3    paidts, 
4    orderid, 
5    amount 
6from tm.payment 
7order by id desc 
8limit 10

You can join tables to combine info. For example to retrieve contact info for the last 10 orders:

3    contact.firstname, 
4    contact.lastname
5from tm.order
6left join on
7order by desc
8limit 10

To make a summary for the number of orders per month for orders in 2014:

2    date_trunc('month',tm.order.createdts),
3    count(*) 
4from tm.order 
5where tm.order.createdts>='2014-01-01' and tm.order.createdts<'2015-01-01'
6group by date_trunc('month',tm.order.createdts)
7order by date_trunc('month',tm.order.createdts)

To get a list of all contacts that created an order in 2014:

2    id,
3    firstname,
4    lastname 
6where id in (
7    select distinct contactid from tm.order where tm.order.createdts>='2014-01-01' and tm.order.createdts<'2015-01-01'
9order by lastname, firstname

Multilanguage fields

Multilanguage fields have a different value for each language. The name for an event is an example of a multilanguage field. In the public data model you will always retrieve the value of these fields for all active languages. As a convention, we use <fieldname><languagecode> as name for the language-specific value for the field.

In an account with languages en and nl active, you can try out:

1select id, nameen, namenl from ev.event

This will return both the english and the dutch translation of the name field for an event.

More info

Consult the reference for each table for more detailed info on available fields and foreign keys.


We're always happy to help! Send us an e-mail