Differences

This shows you the differences between two versions of the page.

--- atomic_redesign [2022/11/23 15:04] – yetidi
+++ atomic_redesign [2023/03/02 19:41] (current) – [atomic redesign] yetidi
@@ Line 1: / Line 1: @@
 ====== 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.
@@ Line 9: / Line 11: @@
 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
@@ Line 21: / Line 25: @@
 ===== table atomic structure =====
-Goal: have one table for all data coming for the film. Key: wh, films_id, cinemas_id
+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  |
@@ Line 33: / Line 41: @@
 |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)  |
+|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, maybe 1 -- box office, 2 -- flat, 3 -- premier, etc   |
+|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 =====
@@ Line 42: / Line 52: @@
 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 =====