A schema turns requirements into an explicit database structure: data types, fields, tables, relationships, keys, and constraints. Getting requirements wrong can undermine later storage, access, and query decisions, so schema design belongs alongside broader architectural choices. section 12.2
A schema is the database-facing shape of a model, distinct from domain types that represent the real world. In a relational setting, it describes tables and columns; in a key–value setting, it can describe typed entities encoded as strings, JSON, compressed data, or binary values. section 11.2.1 section 12.2
A practical schema design addresses:
- Which fields and database-supported types represent each entity. section 12.2.2
- Which table name and primary key identify each row. section 12.2.2
- How tables, relations, normalization, indexes, views, stored procedures, and SQL queries support application behavior. section 12.2
- How database entities are converted to and from domain values. section 11.2.1
Listing 12.3 DBMeteor table definition
import Database.Beam (Columnar, Beamable)
data DBMeteorT f = DBMeteor #1
{ _id :: Columnar f Int #2
, _size :: Columnar f Int
, _mass :: Columnar f Int
, _azimuth :: Columnar f Int
, _altitude :: Columnar f Int
, _timestamp :: Columnar f UTCTime
}
deriving (Generic, Beamable) #3
A Beam table schema models a meteor table as an Haskell record: each Columnar field represents a column, while deriving Generic and Beamable enables library integration. section 12.2.2
Meteor schema
A meteor table can expose identifier, size, mass, azimuth, altitude, and timestamp fields. The schema then associates the table with its name and primary key, and a database record collects that table for queries such as filtering meteors by size. section 12.2.2
