This is an old revision of the document!
Table of Contents
atomic redesign
Right now most calculations going with help of module calc which combine data from different tables into one big structure located in memory.
Only this way get us to see “the same” numbers in reports.
But the module eats a lot of memory and cpu having run a lot of small sql queries for each day data.
So the goal of atomic redesign is to keep the film-cinema-day tripples in the database without of care about this module.
This we help us to minimize amount of cpu spent to calculate reports and get the database less confuse.
Ok, now we may review each screen where we edit data about each movie to see how the atomic concept will work so
what this concept should bring us
ok, the concept should help us to get next things
- fix invoice feature
- modified exchange rates
- good user's logging
- avoid bugs and crazy situations
- get the engine better and stable
table atomic structure
Goal: have one table for all data coming for the film with three keys (wh, films_id, cinemas_id).
field | Type | Description |
id | int | primary key |
wh | date | the date of the record |
films_id | int | films id |
cinemas_id | int | cinemas id |
users_id | int | the id of the user who entered this record |
gbo | float | GBO |
nbo | float | NBO |
tax | float | TAX |
attd | int | attendance |
tpfs_id | int | format of video (from box office record) |
screen_amount | int | amount of screens (from box office record, or 1) |
used_exchrate | float | the exchange rate used for this record (applied automatically) |
record_type | int | the type of the record, maybe 1 – box office, 2 – flat, 3 – premier, etc |
fixed_id | int(null) | optional parameter used for fixed invoice feature – fix of the entered data in future |
Box office form
contains 7 atomic days; each day can be edited while the form is not locked; note though the days prior day current may be locked for correct everyday dgbos data;
all days will be locked after whole form clicked as locked
Flat sale form
enough simple: one atomic day when the sale is happened
Premier form
also simple: one day being added and locked at once
Terms form
terms applied to all atomic data used anywhere so no changes both in logic and data
Exchange rates
Exchange rates applied for the atomic day at the moment when it's entered.
so here we may have a rule: never change old exchange rate; maybe change the table to use exchange rate for every day, not month as today