# Internal Data StorageThe data should be stored in a SQL database. Every piece of data is in a separate field to the extent that is practical.Data is organized into fields (columns) records (rows) and tables. Fields related to each other are in thesame table. Every record has a unique, permanent, numerical id often called a "key" or "primary key". Forthe SNAC Co-op we have decided that records are never overwritten during update. An update operation creates a new record identical to the old record except for updatedfields. All old records are available for viewing via special interface. The old records are invisible tooperations that are intellectually acting on "current" data.Version history, including past versions of a field and record, users that made changes to that data, institution history, and timestamps must be kept in the internal data storage.Provenance of each element must be captured as well, including across merges and splits of identity constellations.The application must avoid storing mixed markup as much as possible. (Brad Westbrook sugests we avoid mixed markup).## Captured actions on dataPrior to human edits, merged records can be algorithmically split by the computer, assuming we write code toperform such a split. After human edit, a split must be performed by a human. It is a requirement that allprevious versions can be viewed (read-only) during the human-mediated split operation so the human can referback to previous information.After human edits, rollback only applies to human edited versions. There is a fire-break where rollback cannotcross from human edits back to machine-merged descriptions. The policy group needs to supply policyrequirements for the tech folks to implement.The broad requirements for the application are: edit data, split records, merge records. Secondary features tomake the system useful include: work flow enforcement, search, reporting (including "watch" features),administration, authorization (data privileges).