atomic redesign

note: change point of view into reports update

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.

We will work under database structure with implementation of the functions and do corrections of data step-by-step until the end of redesign.

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).

The data in the table may be repeated, this way don't get us a lot of data but may help to decrease amount of joins between tables to get work faster. Such approach in use in non-sql databases like moodle. Also duplicate of exchange rate for example, or use gbo as nbo+tax may decrease amount of bugs.

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
box_1st_day	int(null)	box offices 1st atomic record (to bind atomic records into long sequence)
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 0)
used_exchrate	float	the exchange rate used for this record (applied automatically)
record_type	int	the type of the record: 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

possible issue here if the film may be running in several formats (tpfs_id). As I see in current FDM this managed by different names of the same cinema, like “Limegrove” and “Limegrove 3d”. But in box offices we always had only one theather format of movie. So I may say about this is not an issue for now.

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

we may use new table bo_records, where first_atomic is first day when the sequence is started, and then the flag whether the form is locked or not.

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

FDM manual

Table of Contents