atomic_redesign
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
atomic_redesign [2022/11/23 09:24] – [Box office form] yetidi | atomic_redesign [2023/03/02 19:41] (current) – [atomic redesign] yetidi | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== atomic redesign ====== | ====== 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. | 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. | 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 | Ok, now we may review each screen where we edit data about each movie to see how the atomic concept will work so | ||
Line 19: | Line 23: | ||
*avoid bugs and crazy situations | *avoid bugs and crazy situations | ||
*get the engine better and stable | *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 | ||
+ | |id | int | primary key | | ||
+ | |wh |date |the date of the record | ||
+ | |films_id | ||
+ | |cinemas_id | ||
+ | |users_id | ||
+ | |box_1st_day | ||
+ | |gbo |float | ||
+ | |nbo |float | ||
+ | |tax |float | ||
+ | |attd |int |attendance | ||
+ | |tpfs_id | ||
+ | |screen_amount | ||
+ | |used_exchrate | ||
+ | |record_type | ||
+ | |fixed_id | ||
+ | |||
+ | 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 " | ||
===== Box office form ===== | ===== Box office form ===== | ||
Line 24: | Line 52: | ||
all days will be locked after whole form clicked as locked | 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 ===== | ===== Flat sale form ===== |
atomic_redesign.1669195483.txt.gz · Last modified: 2022/11/23 09:24 by yetidi