Trainwreck Database

Rattail defines a basic / common schema for POS Transactions, for what it calls a "Trainwreck" database. (This is in the rattail.trainwreck.db.model module.) Again you're free to extend this schema, in fact Rattail defines it in such a way that you "must" extend it technically, even if you add nothing to it. The idea is that this Trainwreck DB would be robust enough to store all "pertinent" info about transactions, in a POS-neutral way. This has a few advantages, namely:

The schema for Trainwreck which is defined by Rattail, only includes transaction "header" and "detail" (line item) tables, at this time. You're free to add columns to either, as well as additional tables. You are expected to "extend" the web app views also, however minimally.

There is some basic support for "sharding" in a sense. Ideally you would have one DB for "current" transactions (going back how far, is up to you), plus a separate DB for each "year" of transactions. These two "types" of DB's need not be exclusive, meaning if today is Jan 1, 2019 then we may have a separate 2018 DB but our "current" DB might still also include all of 2018's transactions. So when you split off a year (or just a day) at a time from "current" DB would be up to you. The web app supports exposing a "DB picker" so each user can locate "current" or "archived" transactions.

It's worth noting some "cons" for this Trainwreck approach:

Pros outweigh the cons here though, IMHO.

Trainwreck (last edited 2019-08-15 03:35:03 by LanceEdgar)