Atomic fdm idea

Goal: make FDM more reliable, stable and recent.

Full redesign of the database.

Concept of atoms.

One atom = film + screen(in cinema) + day

each atom has fixed exchange rate for local currency for this cinema

• number of attendance (sold tickets)
• cost of them
• gbo
• nbo
• users_id
• …

Of course we may also store each ticket. But I think enough to summarize them into 'atomic day'.

The atom should be never modified (or their modification time restricted for example by the day when it was added). Only new atom which refer to this one may be applied in the next dates.

That I've describe main processing being with films (box office)

For cost calculation we may also review and write how it should be look as.

Also other atomic based things we need to process somehow to have then invoices and payments.

• never delete old records
• never change old records
• the reports should calculate data by adding to atoms all modifiers which whatever happening

Ok, this approach in use in blockchain for example – all data being stored forever. Easy to know what was happened in past time.

The database after the update may be have less tables. I think we will use InnoDB engine and transactions.

• well work with correct exchange rates
• fix invoice feature
• not need to lock months
• less bugged calculation engine
• simplified logic of calculations

The goal to use the recent technologies which getting much better in last years. C# now has future methods and a lot of other logical improvements.

I think to create atomic structure using current database.

When engine will be ready – we will run all tests to compare old reports with new reports may be even in automic mode which will go through excel reports and compare each cell automatically.

Then from some day we will go to fdm_2

23-nov-2022 keep old UI completely; only change the core; this way help us to keep old working style without of headache about teaching users;

so this way:

• create new database structures and describe each one
• make the conversion scripts which may convert the current database to this style
• arrange new engine on some great place (like third level domain)
• test all report & work to see all is nice
• use new engine for some days
• update old vps for new engine
• move the database from testing place to main website
• continue life with new FDM

ok, this is my draft about how it could be