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 15:04] – 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 21: | Line 25: | ||
===== table atomic structure ===== | ===== 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 | |field | ||
|id | int | primary key | | |id | int | primary key | | ||
+ | |wh |date |the date of the record | ||
|films_id | |films_id | ||
|cinemas_id | |cinemas_id | ||
|users_id | |users_id | ||
+ | |box_1st_day | ||
|gbo |float | |gbo |float | ||
|nbo |float | |nbo |float | ||
Line 33: | Line 41: | ||
|attd |int |attendance | |attd |int |attendance | ||
|tpfs_id | |tpfs_id | ||
- | |screen_amount | + | |screen_amount |
|used_exchrate | |used_exchrate | ||
- | |record_type | + | |record_type |
|fixed_id | |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 42: | 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.1669215899.txt.gz · Last modified: 2022/11/23 15:04 by yetidi