Database and Operations for Duty-Free Yield Rates

What data for this category looks like

Data related to duty-free yield rates comes primarily from duty-free operator POS sales systems, customs offshore duty-free supervision platforms, and third-party retail data aggregation channels. Data is updated once daily, with full synchronization of the previous day’s data completed during the early morning of the current day. Each data entry is a single product’s daily operating record, containing fields including store identifier, product code, transaction date, purchase unit price, listed unit price, actual settlement unit price, and gross profit amount. Field units are character type, numeric type, date type, yuan, yuan, yuan, and yuan, respectively.

Constraints imposed on database and operations workflows by these characteristics

Differences in format and field naming across multiple data sources require configuring unified data cleaning rules to complete field mapping and format standardization. The daily full update feature requires configuring scheduled scheduling tasks, with the synchronization window set during off-peak daytime business hours to avoid resource contention with online queries. High-frequency queries use trade_date and store_code, so a joint index must be created for these two fields. Query latency will increase significantly without this index. Additionally, data timeliness requirements are high. A data verification mechanism must be configured to ensure that the same day’s data is synchronized and verified before the early morning of the next day.

Configuration settings

Configuration Item	Recommended Setting	Rationale
`DB_SYNC_CRON`	`0 1 * * *`	Execute previous day’s data synchronization at 1:00 AM daily, avoiding peak daytime business hours
`DB_BATCH_INSERT_SIZE`	`600-1000`	Balance write performance and server memory usage, avoiding single write timeouts
`DB_INDEX_CREATE`	Create a joint index for `trade_date` and `store_code`	High-frequency queries use transaction date and store code, improving query efficiency
`DB_CONN_TIMEOUT`	`30 seconds`	Stable intranet database connections; 30 seconds is sufficient for a single connection handshake and authentication
`TOOL_DB_VAR_ESCAPE`	Enable automatic escaping	Avoid SQL syntax errors when passing variables, and prevent injection risks
`DB_DATA_RETENTION_DAYS`	`180 days`	Daily report broadcasts only require the past six months of historical data; data beyond this retention period can be archived to cold storage

The parameter values provided on this page are common recommended starting points for configuration. Actual values are affected by data format, data volume, and business rules. Specific issues require individual analysis, and it is recommended to test against local samples before finalizing settings.

Three common configuration mistakes

Symptom: Database tools return SQL syntax error near '?' or query results return empty fields. Cause: The TOOL_DB_VAR_ESCAPE configuration is not enabled, and special characters in variables damage SQL statement structure.
Symptom: Database write timeouts occur after the daily early morning synchronization task triggers, returning a 504 Gateway Timeout error. Cause: DB_BATCH_INSERT_SIZE is set too large, exceeding the database’s single write processing limit.
Symptom: MongoDB connection fails, returning a connection refused error. Cause: Correct MongoDB port or access whitelist is not configured, or container network policies restrict access to the MongoDB instance.

How to confirm configurations are correct

Run a manual data synchronization task, check synchronization logs for error messages, and confirm that the scheduled scheduling configuration is active.
Initiate a query using trade_date and store_code, check if the number of returned records matches expectations, and confirm that the index configuration is active.
Test the execution logic for passing variables via the database tool, check if expected results are returned, and confirm that the variable escaping configuration is correct.
Check database storage usage, confirm that the automatic expired data cleanup logic complies with configuration requirements.

Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.