Model periods, not one endlessly edited record
A member represents the person or customer identity. A membership period represents a defined service relationship over time. One member can have multiple periods: an expired first period, a renewal and an active subsequent period. Creating a new period should not delete or overwrite the previous one.
Record lifecycle events with effective and recorded time
Meaningful events include activation, renewal, freeze, resume, extension, plan change, expiry, cancellation and correction. Each event should identify its type, effective date/time, recorded date/time, reason or context and actor where appropriate. Event time tells you when it was entered; effective time tells you when it became true for the business.
Preserve plan versions, prices and entitlements
A membership is not the same as a reusable plan. If a plan configuration or price changes later, historical membership terms must remain explainable. Store the plan/version and historical price context that applied to each period or event. Do not silently replace old context with today’s configuration.
Keep related histories linked but separate
Seat and shift allocation, attendance, invoices, payments, receipts, discounts and concessions have their own histories. Link them to the relevant membership period or lifecycle event rather than flattening them into a single current membership row. Historical seat allocation should not be overwritten by today’s allocation.
Treat corrections and backdated events carefully
A correction fixes incorrect data, such as a mistyped date. It is not a replacement for a genuine freeze, plan change or renewal event. Backdated changes deserve stronger validation because they can alter capacity, finance, attendance and reports already relied upon. Conflicting or overlapping effective periods should be detected rather than silently accepted.
Archive for operational clarity without falsifying history
Expired records may be archived or soft-deleted from routine screens when that supports operations, but the approach must not make historical business truth disappear. Hard deletion of consequential records should be tightly controlled and aligned with applicable privacy, contractual and operational requirements; there is no universal retention period to invent here.
Business history is not the audit log
Business history answers what happened to the membership relationship. An audit log answers which user or system action recorded, edited, approved or attempted an operation. They complement each other but should not be treated as the same dataset. Permissions should limit who can apply consequential changes and corrections.