My second talk at PG Conf EU was a joint talk, so I only briefly mentioned my work on the NORM project. However, since many conference attendees heard about it for the first time, I feel that I need to fill them in (even if I sound like a broken record for many others:))
So here comes a second summary.
- What problem are you trying to solve? I am trying to solve the whole hierarchy of problems. Application developers tend to use ORMs instead of writing embedded SQL statements because of insufficient knowledge of SQL and pressure to deliver MVP. ORMs generate a large number of “small queries,” most often selecting multiple records by their primary key values. These queries block the optimization capabilities of PostgreSQL (and any other database, for that matter), and the application response time grows linearly while all queries perform very well. We are giving application developers a tool to interact with databases in terms of complex objects, thus drastically reducing the I/O overhead.
- Who is driving the database design when using NORM methodology? Database design is driven by database developers. We do not automatically generate tables or indexes of other storage structures. A transport object defined by a JSON schema describes a hierarchy used in a microservice or a controller. There can be multiple hierarchies needed by different applications or different parts of the same application, and we can provide support for all these hierarchies using the same database tables. The only database objects we generate are user-defined types and functions.
- Does it mean we need a separate JSON schema for each application controller? Most likely, yes. The worst thing application developers can do with NORM is to reuse several existing mappings to create a new one.
- How is NORM different from ORM? Isn’t it just another ORM? NORM is different because it allows applications to operate on data sets rather than on individual records of simple structure. Without exposing it to an application developer, NORM opens opportunities to utilize the power of relational search.
- Is it necessary to use functions? No, if application developers are capable and willing to construct the necessary SQL statements, functions will not be needed.
- Why do application developers often have difficulties with SQL? Because SQL is a declarative language and operates on sets, while OO languages are imperative and operate on individual objects.
Same as with the previous post, please leave a comment if I missed any questions (or if you have more :))