Positioning electronic price tag data construction method based on distributed database

Abstract

The invention discloses a distributed database-based positioning electronic price tag data construction method, which relates to the field of electronic price tags, and constructs a multi-level position data model, generates a unique and traceable structured position code for each physical hanging point, and then constructs a multi-attribute commodity data model. The method comprises the following steps: directly associating a commodity core attribute with an independent commodity identifier, flexibly associating a position identifier with the commodity identifier by creating a dynamic binding relationship including binding time, a state, a type and a display template identifier, and intelligently responding to business events such as sales promotion and the like; and finally, based on the dynamic binding relationship, the commodity data and a preset template, generating a personalized display data packet, and efficiently and reliably issuing the personalized display data packet to the target electronic price tag through the message-oriented middleware and the edge gateway, and through three-in-one dynamic data construction, realizing inventory accurate visualization, marketing automatic presentation and omni-channel inventory integrated management, and improving the marketing efficiency. And the operation efficiency of the retail store and the customer experience are obviously improved.

Description

Technical Field

[0001] This invention relates to the field of electronic price tags, specifically to a method for constructing location-based electronic price tag data based on a distributed database. Background Technology

[0002] In retail scenarios such as apparel, products possess multi-dimensional attributes such as color and size, and are displayed in various ways (hanging, stacking, etc.). Traditional electronic shelf label systems typically employ centralized databases, which struggle to handle the data storage and concurrency pressures brought about by massive product attributes, precise location information, and frequent price changes. Existing solutions often fail to achieve integrated, accurate mapping and efficient management of the multi-dimensional attributes of products, their physical display locations, and electronic shelf labels in their data models. This results in inaccurate inventory management, inefficient shelf label updates, and an inability to support location-based, refined operations. Summary of the Invention

[0003] The purpose of this invention is to provide a method for constructing location-based electronic price tag data based on a distributed database. By designing an innovative hierarchical and cascaded data model and combining it with a distributed database architecture, it achieves efficient and reliable management and synchronization of massive, multi-attribute commodities and their precise physical location information, thereby solving the problems mentioned in the background art.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a method for constructing location-based electronic price tag data based on a distributed database, comprising the following steps:

[0005] S1: Construct a multi-level product location data model, which includes location area level, display area level, shelf level and hanging point level, and assign a unique location identifier to each electronic price tag at the hanging point level;

[0006] S2: Construct a multi-attribute product data model, wherein the product data model includes configuring independent product identifiers for different specifications of the same product and storing their corresponding product attributes in association;

[0007] S3: Create a dynamic binding relationship, which includes associating the location identifier of the product in step S1 with the product identifier of the product in step S2, and recording the binding time and binding status;

[0008] S4: Based on the dynamic binding relationship, the multi-attribute product data model, and the preset display template, generate a display data package that matches the location identifier and the product identifier, and send the display data package to the target electronic shelf label corresponding to the location identifier to drive it to update the display content.

[0009] Preferably, in step S1, each electronic shelf label is assigned a unique location identifier at the hanging point level. Specifically, this includes generating a structured location code based on the store identifier, display area identifier, shelf identifier, shelf layer number representing the hanging point level, and the sequential index at that layer, where the electronic shelf label is located. The location code is stored in the product location data model as the location identifier.

[0010] Preferably, the construction of a multi-attribute product data model in S2 specifically includes: receiving product master data from an enterprise resource planning system, wherein the same standard product unit corresponds to multiple product variants containing different color and size attributes, generating an independent product identifier for each product variant, and storing the product attributes containing color, size, and price attributes as inherent fields associated with the product identifier.

[0011] Preferably, the dynamic binding relationship in S3 also includes a binding type field and a display template identifier field. When a product price promotion event is detected, the binding type in the dynamic binding relationship record is updated to the promotion type, and the display template identifier is updated accordingly to trigger the electronic price tag to switch to the promotion display style.

[0012] Preferably, generating the display data packet in step S4 specifically includes the following steps:

[0013] Based on the product identifier associated in the dynamic binding relationship, query the multi-attribute product data model to obtain the current product price, color, and size information;

[0014] Based on the display area level or current marketing status of the electronic price tag, a target display template is matched from multiple preset display templates. The display template defines the text content, layout, and style in a structured data format.

[0015] The acquired product information is populated into the target display template to generate a display data package containing location identifiers, product information, and template rendering instructions.

[0016] Preferably, the distributed database uses a strategy of horizontal sharding based on location region hierarchy to store the location data model and the dynamic binding relationship, and the product data model uses a strategy of horizontal sharding based on product brand identifier to store the product.

[0017] Preferably, when the display data packet is sent to the target electronic price tag corresponding to the location identifier, an update instruction is sent through a message middleware, specifically including the following steps:

[0018] The display data set is encapsulated into a lightweight JSON message and published to a specified topic in the message middleware;

[0019] Gateway devices deployed at the store site subscribe to the topic and receive update instructions for electronic shelf labels within their jurisdiction;

[0020] The gateway device sends update commands to the target electronic price tag via a low-power wireless communication protocol.

[0021] Preferably, the dynamic binding relationship in S3 also stores at least one time condition field to record the effective time range of the binding or the planned price change time. Based on the comparison result between the current time and the time condition field, the system automatically triggers the update of the binding status, binding type or display template identifier in the dynamic binding relationship.

[0022] Preferably, generating the display data package in S4 further includes matching the target display template from a set of multiple preset display templates based on the category attributes in the product data model or preset marketing rules, wherein different template layouts and visual emphasis elements are preset for different product categories or different marketing rules.

[0023] Preferably, before issuing update instructions via a low-power wireless communication protocol, the gateway device also performs local instruction queue management and priority scheduling. Promotional instructions or inventory correction instructions marked as high priority are issued first, and instructions that fail to be issued are retried locally according to a preset retry strategy. At the same time, the final execution result is fed back to the cloud system.

[0024] In summary, the beneficial effects of this invention are:

[0025] This invention achieves precise and automated management of electronic price tags by constructing a multi-level location data model and a multi-attribute product data model, combined with dynamic binding relationships and intelligent template rendering. It significantly improves operational efficiency, allowing price and promotional information to be synchronized to all stores in real time and in batches, avoiding the tediousness and errors of manually replacing paper price tags; it significantly optimizes the customer experience, with price tags clearly displaying multi-dimensional information such as color and size, as well as eye-catching promotional styles, facilitating rapid decision-making; it enables refined operations, supporting intelligent inventory management, rapid product retrieval, and data-driven display analysis through precise mapping of "product-location-tag"; and it possesses high scalability and reliability, based on a distributed architecture and asynchronous communication via message queues, enabling the system to stably support large-scale store networks, laying a solid foundation for omnichannel retail and digital marketing. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of the invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a schematic diagram of the overall process framework of the location-based electronic price tag data construction method based on a distributed database of the present invention;

[0028] Figure 2 This is a schematic diagram of the dynamic binding process framework structure in the location-based electronic price tag data construction method of the present invention based on a distributed database;

[0029] Figure 3 This is a schematic diagram of the process framework for generating display data packets in the location-based electronic price tag data construction method based on a distributed database of the present invention. Detailed Implementation

[0030] The present invention will now be described in further detail with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention. These drawings are simplified schematic diagrams, which are only used to illustrate the basic structure of the present invention in a schematic manner, and therefore only show the components related to the present invention.

[0031] To facilitate understanding of the present invention, a more complete description of the invention will be given below with reference to the accompanying drawings, which illustrate several embodiments of the invention. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that the disclosure of the invention will be more thorough and complete.

[0032] All features disclosed in this specification, or steps in all methods or processes disclosed herein, may be combined in any way, except for mutually exclusive features and / or steps.

[0033] Any feature disclosed in this specification (including any appended claims, abstract, and drawings) may be replaced by other equivalent or similar features, unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is merely one example of a series of equivalent or similar features.

[0034] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection, a direct connection, or an indirect connection through an intermediate medium; they can refer to the internal communication of at least two elements or the interaction relationship of at least two elements, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0035] Please see Figure 1-3 The present invention provides an embodiment of a method for constructing location-based electronic price tag data based on a distributed database, comprising the following steps:

[0036] Step 1: Construct a multi-level product location data model

[0037] The physical space of the store is deconstructed into a tree-like structure that progresses from macro to micro, ensuring that every physical point can be uniquely and accurately digitally defined. Specifically, this includes:

[0038] Location-based hierarchy: This is the basic unit for business management and data isolation of stores; management attributes include: store ID, name, address, type, and business hours. It defines the ownership and boundaries of data and is the main dimension of data sharding in a distributed architecture.

[0039] Display area hierarchy: mainly display areas / functional areas; large areas divided according to business functions or physical characteristics; management attributes include: area ID, type (e.g., women's wear area, men's wear area, promotional area, refrigerated display area), temperature range, and orientation. This solves the problem of adapting to business scenarios and facilitates regional marketing and performance analysis.

[0040] Shelf hierarchy: primarily refers to shelves / display racks; the specific physical equipment that carries the goods; management attributes include: shelf ID, type (hanging rack, shelf cabinet, island rack), capacity, dimensions (length, width, height), and orientation; enabling refined management of display resources. Capacity and dimensions provide data support for space optimization and display planning.

[0041] Hanging point level: mainly hanging points / location points; atomic-level positions binding products and price tags; management attributes include: location index, price tag angle, device status (battery level, online status). This is the finest granularity of the entire model and the ultimate point for precise "one item, one location, one tag" management.

[0042] The hierarchical relationship is constructed as follows: Store (1): Owns → Display Area (N): Contains → Shelf (N): Carries → Hanging Point (N). This ensures that the complete ownership path can be traced back from any hanging point.

[0043] Generation and Value of Structured Location Identifiers (Location Codes)

[0044] An example of an encoding rule is as follows:

[0045] [Store Signage] - [Display Area Signage] - [Shelf Signage] - [Layer Number] - [Sequence Index]

[0046] Store sign: ST001;

[0047] Display area signage: WF (Women's Fashion);

[0048] Shelf label: A01 (Shelf 1 in Section A);

[0049] Layer number: L02 (Layer 2);

[0050] Sequential index: P15 (the 15th hanging point of this layer);

[0051] Example of the final generated location code: ST001-WF-A01-L02-P15.

[0052] In the database, this structured location code can be stored as a core field.

[0053] Method 1: Store it as an independent field `position_code` (VARCHAR) and create an index on it. At the same time, retain foreign key fields such as `store_id`, `area_id`, `shelf_id`, and `position_index` to maintain the model's flexibility and the ability to perform related queries.

[0054] Method 2: Utilizes "derived fields" generated by business logic, concatenated through join queries when needed. However, storing these fields separately offers better performance.

[0055] Within the entire system, this code uniquely corresponds to a physical attachment point, fundamentally eliminating confusion regarding the location of goods or price tags, and forming the basis for inventory accuracy.

[0056] The code itself contains complete hierarchical information, which can be parsed and traced. The system does not need to look up the database; it can determine which store, area, and shelf the point belongs to simply by parsing the code, which facilitates rapid path planning and location calculation.

[0057] Using human-readable abbreviations and sequence numbers makes it easy for store staff to quickly locate items. When the system prompts "Please go to ST001-WF-A01-L02-P15 for restocking", the staff can intuitively understand its location.

[0058] The code is bound to the physical location and does not change with the products or price tags placed on it. Even if the products are replaced or the price tags are discarded and reset, the digital identity of that location point is permanent, ensuring the long-term stability of the location data model.

[0059] Step 2: Construct a multi-attribute product data model

[0060] In constructing a multi-attribute product data model, the core concept is "one item, one code; attribute association; and independent variants." This concept has completely changed the way traditional retail systems treat products as single entities, and fully considers the actual business characteristics of industries such as clothing and footwear.

[0061] In traditional retail systems, an item (such as "a brand of pure cotton T-shirt") is typically considered a unit of management. However, in the apparel industry, the actual transaction and inventory object is its specific variant—"a brand of pure cotton T-shirt, black, size M." These two concepts must be strictly distinguished.

[0062] Standard Product Unit (SPU): Defines a product's "identity" and "lineage." It carries attributes common to all variations: brand, category, series, product name, main image, material, design style, and season of release. It is the core object of marketing, customer awareness, and product management.

[0063] Product Variation (SKU): This is the smallest unit of inventory that a product can be sold, stored, and priced. It is derived from the Standard Product Unit (SPU) and is defined by the two most core and common "dimensions" in the apparel industry: color and size.

[0064] The advanced nature of this model lies in its mandatory generation of a unique product identifier for each variant. This means that in the digital world, "black-M code" and "white-L code" are considered two completely independent entities with unique "identity numbers." This atomized decomposition is an absolute prerequisite for achieving all refined operations.

[0065] Key design decisions and advantages of model building

[0066] The core attributes are stored in inherent fields: storing color, size, price, etc. as inherent fields directly associated with the product identifier, rather than indirectly referencing them through complex association tables, is a design with great practical significance.

[0067] Extremely optimized query performance: When the system needs to quickly generate display information for tens of thousands of electronic price tags, it can directly read a single record to obtain all key attributes (color, size, current price), avoiding the performance overhead caused by multi-table join queries and ensuring instantaneous response to price tag update commands.

[0068] The business logic is extremely clear: price and inventory status are directly tied to specific variants, making the logical processing of business scenarios such as "black-M size is discounted but white-L size is not discounted" and "a certain color and size is out of stock" simple, direct, and unambiguous.

[0069] Data consistency is easier to ensure: it reduces complex dependencies between data, making the path for information maintenance and updates shorter and more controllable.

[0070] Collaboration with Enterprise Resource Planning (ERP) systems

[0071] The model's starting point is "receiving product master data from ERP," which clarifies the system boundaries and the authoritative source of data. ERP serves as the "single source of fact" for product information, procurement, and costs. This model, acting as a "front-end data mirror" for store operations and customer outreach, focuses on:

[0072] The product and variation information provided by ERP is transformed into a storage structure that is more suitable for high-frequency reading and real-time synchronization, and associated with the operational attributes such as templates and locations required for display.

[0073] Real-time inventory data (based on price tag binding and unbinding) and sales data from stores are fed back to the ERP system, forming a closed loop from the supply chain to the sales terminal.

[0074] Although the model emphasizes treating core attributes as inherent fields, its architecture is not closed. Through the core "product identifier", more extended attributes can be easily associated.

[0075] Dynamic attributes, such as "washing recommendations," "place of origin," and "environmental certifications," can be managed through a separate attribute table and linked as needed to meet the requirements of product detail display.

[0076] Marketing attributes, such as "whether it is a new product", "whether it is a featured product", and "related bundled products", are used to support precise marketing rules and recommendation algorithms.

[0077] Synergy with "Location Data Model": Achieving a unified "Object-Location-Signature" system

[0078] Precise mapping: A "product variant identifier" is strongly associated with a "structured location code" through a price tag binding relationship. It not only knows how much inventory of "black-size M T-shirts" there is, but also precisely knows which shelf, which floor, and which hanging point they are on in the store.

[0079] Driving business scenarios:

[0080] Intelligent replenishment and inventory: The system detects that the "black-size M T-shirt" at the hanging point ST001-WF-A01-L02-P15 has been sold. It can automatically trigger the decrement of the inventory of this variant in the store and generate a replenishment order that is accurate to the location and variant when the inventory is below the safety line.

[0081] Personalized service: When a customer views a "black - size M T-shirt" online and it shows as in stock, the system can display a map showing the store's exact location and even guide staff to find it quickly. If the item is out of stock in the store, customers can immediately check for the same variation in other stores or warehouses.

[0082] Dynamic display analysis: By combining sales data, it can be found that "the red S-size dress (specific variant) placed on the third floor (specific location) at the entrance of the women's clothing area" has the highest conversion rate, thus turning display knowledge into data assets.

[0083] Integrated omnichannel inventory: After an online order is placed, the system can accurately locate a specific color and size item in a specific location within the store closest to the customer and assign store staff to quickly pick up the item, providing ultimate efficiency for "online ordering, in-store pickup / flash delivery".

[0084] Data-driven product decisions: Analyze the sales speed, discount sensitivity, and inventory turnover of various variations (such as different colors and sizes) to provide highly granular decision-making basis for future product design, procurement planning, and pricing strategies.

[0085] Seamless promotion engine: Promotional rules can be easily configured to specific variations (such as "all size M items are eligible for discounts") and instantly displayed in the physical world via the price tag system. Promotional effectiveness can also be evaluated at the variation level.

[0086] Step 3: Create dynamic binding relationships

[0087] In traditional retail, a product is labeled and placed in a fixed location—a fixed, "hard connection." In the digital model designed in this invention, this connection is deconstructed into a traceable, changeable, and context-rich dynamic record.

[0088] The binding relationship itself becomes a managed object: This record has an independent lifecycle (binding time, unbinding time, binding status), making each product listing, relocation, delisting, or price tag change an auditable business operation.

[0089] The components and business implications of dynamic binding relationships

[0090] The association between location identifiers and product identifiers: This is the cornerstone of the binding, establishing a precise link between "where" (e.g., ST001-WF-A01-L02-P15) and "what" (e.g., SKU_black_size M_T-shirt).

[0091] It achieves a precise mapping between physical space and merchandise inventory. This is an absolute prerequisite for realizing advanced functions such as "visualized inventory," "one-click product search," and "automatic inventory counting."

[0092] Binding time and binding status: Binding time records the moment the association was established; binding status (such as active / inactive) describes whether the association is currently valid.

[0093] It can accurately analyze the turnover of goods (how long a certain item stays in a certain position before it is sold).

[0094] When a product is sold, returned to the warehouse, or transferred, its binding status is set to inactive. The system then knows that the slot is "empty" and can arrange for a new product to be listed. This ensures real-time consistency between system data and the actual situation in the store.

[0095] Binding type field: Used to classify and identify the business scenario served by the current binding relationship, such as: default (regular sales), promotional (promotion), temporary (temporary display), seasonal (seasonal theme), or clearance (clearance).

[0096] It tags each display with a business label. Management can easily filter and view "all tie-ins currently being promoted" to evaluate their effectiveness.

[0097] Different types of bindings can trigger different subsequent processes. For example, a clearance binding may not require restocking after the product is sold and can be associated with a specific low-price template.

[0098] Display Template Identifier Field: Points to a predefined display template that controls the screen layout, fonts, colors, icons, and other visual elements of the electronic price tag.

[0099] Product data (price, product name) is decoupled from display style. By switching template identifiers, the same product can instantly present completely different visual styles.

[0100] Ensure that all stores have a unified and professional visual presentation for marketing activities such as "member prices" and "limited-time offers," avoiding confusion caused by each store defining its own.

[0101] Intelligent Closed Loop of "Promotion Event Response": When an ERP or promotion management system initiates a promotion activity (e.g., "SKU_black_M_size_T-shirt" will be on sale at 30% off starting at 8 am tomorrow), the event is published to the message center.

[0102] The electronic price tag system consumes the event and automatically performs the following operations:

[0103] Update binding type: Change the binding type of all active binding records related to this product from default to promotional.

[0104] Associate promotion template: At the same time, update the display template identifier to the pre-designed PROMO_RED_BANNER (e.g., a template with a red background, enlarged promotion price, and possibly a flashing "SALE" icon).

[0105] Instruction issuance and front-end presentation: Based on the updated binding relationship, the price tag management system generates specific display content and style instructions, and issues them to the corresponding physical price tags via wireless network.

[0106] Instantaneous switching: At the preset promotion time point, all relevant price tags synchronously and automatically refresh the screen and switch to a prominent promotion style.

[0107] Zero manual work and zero errors: It avoids the heavy work of store clerks manually replacing thousands of paper price tags and possible omissions and errors.

[0108] Ensure that "price change" and "style change" occur simultaneously and precisely in tens of thousands of stores and locations, seizing the best marketing opportunity.

[0109] Powerful visual impact is directly transmitted through the price tags, maximizing the in-store conversion effect of the promotion activity.

[0110] More extensive dynamic scenario applications

[0111] This mechanism is also applicable to other rich business scenarios:

[0112] Theme display switching: During the Spring Festival, mark all binding types as seasonal_spring_festival and associate a Spring Festival theme template (e.g., adding a gold border and Chinese character "Fu" elements) to create a festive atmosphere at one click.

[0113] Reminder for approaching expiration date goods: For food or fresh food approaching the expiration date, the system can automatically update their binding type to expiring_soon and associate a special template with a yellow exclamation mark to remind customers to purchase as soon as possible.

[0114] VIP Exclusive Display: When the system detects a VIP customer approaching (via Wi-Fi or Bluetooth), it can temporarily switch the binding of specific products in that area to the vip_preview type, displaying exclusive prices or information visible only to members.

[0115] By binding the type and display template identifier—two key fields—it dynamically couples the backend business strategy (whether it's a promotion, what theme) with the frontend presentation (how it's displayed). This not only achieves a leap from "price management" to "visual value management," but also builds a neural network capable of automatically responding to market changes and executing complex marketing instructions.

[0116] This transforms physical store shelves from static display spaces into dynamic, interactive, and data-driven media interfaces, becoming the final touchpoint and powerful lever connecting brand strategy and consumer perception. This is one of the core secrets behind digital retail's transcendence of traditional retail, achieving operational automation and personalized experiences.

[0117] Step 4: Generate and send out display data packets

[0118] The process of generating display data packets is a perfect embodiment of the modern software design concept of separating "data", "style" and "logic".

[0119] Step 1: Query product data – Obtain “content raw materials”

[0120] Using the product identifier in the dynamic binding relationship as the unique key, query the multi-attribute product data model to obtain the latest and most accurate core information triple for that product variant: price, color, and size. For example: ¥599.00, black, M.

[0121] The query retrieves the current status in the database, thus immediately reflecting any price adjustments recently initiated by the ERP or promotion system.

[0122] Step 2: Match Display Template – Select “Visual Style”

[0123] This is an intelligent judgment process, and the rules are based on the context implied in the dynamic binding relationship:

[0124] Based on display area: If the binding relationship shows that the price tag is located in cold_cabinet (refrigerated cabinet area), then the "low temperature product template" will be automatically matched (may have larger font and snowflake icon).

[0125] Based on marketing status: If the binding type in the binding relationship is promotional, then match the corresponding "promotional template" (such as red background, exploded graphic).

[0126] Based on product type: the templates for hanging garments and folded garments may differ to optimize space utilization and viewing angles.

[0127] The essence of a template: A template is a "style blueprint" defined in a structured format such as JSON. It does not contain specific product data, but only defines the layout (where to put the price, where to put the size), style (font, size, color, background) and static elements (such as the currency symbol "¥" and the label "Size:").

[0128] Step 3: Fill in the generated data package – synthesize the “final product”

[0129] The "content material" (¥599.00, black, M) obtained in step one is filled and assembled according to the format and position specified in the "style blueprint" selected in step two. The resulting display data package is a lightweight data structure containing complete rendering instructions. It typically includes:

[0130] Target address: Location identifier to ensure accurate delivery of instructions.

[0131] Core data: The populated product information.

[0132] Rendering instructions: The template ID to be referenced and the specific formatting requirements.

[0133] Control metadata: such as command priority, validity period, and retry policy.

[0134] Message-based command delivery: Sending generated instructions to physical price tags faces challenges such as network instability, massive concurrency, and differences in store IT environments. Using message middleware (such as Kafka, MQTT Broker) is a classic architectural pattern for addressing these challenges.

[0135] The data packet will be encapsulated into a lightweight JSON message and published to a theme such as esl-update-command.

[0136] Asynchronous processing and peak / valley smoothing. After the rendering engine instantly generates 100,000 update commands, it can quickly store them in the message queue and return success, without waiting for all price tags to be updated, resulting in extremely high system responsiveness. The queue acts as a buffer, smoothing out traffic spikes.

[0137] Gateway device subscription and filtering: Each store's smart gateway (such as the Huawei AirEngine AP you mentioned, which has built-in IoT gateway functionality) subscribes to this topic. The gateway's built-in logic only consumes and processes messages whose target location identifier belongs to its own store.

[0138] Decoupling and intelligent edge computing. The cloud system does not need to be aware of the network topology and price tag communication details of specific stores. The gateway, as an "edge node," undertakes responsibilities such as instruction filtering, protocol conversion, and local retries, improving the overall reliability and scalability of the system.

[0139] The wireless protocol is finally issued: the gateway sends the instructions to the target price tag via a low-power wireless communication protocol (such as your custom BLE 5.4 protocol).

[0140] Adapting to hardware constraints. The BLE protocol stack is simple and consumes extremely low power, making it ideal for battery-powered price tags. The "last mile" communication from the gateway to the price tag uses a protocol deeply optimized for the Internet of Things, ensuring energy efficiency and stability.

[0141] In another embodiment, the distributed database uses a strategy of horizontal sharding based on location region hierarchy to store the location data model and the dynamic binding relationship, and the product data model uses a strategy of horizontal sharding based on product brand identifier to store the product.

[0142] The above description is merely a specific embodiment of the invention, but the scope of protection of the invention is not limited thereto. Any variations or substitutions conceived without inventive effort should be included within the scope of protection of the invention. Therefore, the scope of protection of the invention should be determined by the scope defined in the claims.

Claims

1. A method for constructing location-based electronic price tag data based on a distributed database, characterized in that: Includes the following steps: S1: Construct a multi-level product location data model, which includes location area level, display area level, shelf level and hanging point level, and assign a unique location identifier to each electronic price tag at the hanging point level; S2: Construct a multi-attribute product data model, wherein the product data model includes configuring independent product identifiers for different specifications of the same product and storing their corresponding product attributes in association; S3: Create a dynamic binding relationship, which includes associating the location identifier of the product in step S1 with the product identifier of the product in step S2, and recording the binding time and binding status; S4: Based on the dynamic binding relationship, the multi-attribute product data model, and the preset display template, generate a display data package that matches the location identifier and the product identifier, and send the display data package to the target electronic shelf label corresponding to the location identifier to drive it to update the display content.

2. The method for constructing location-based electronic price tag data based on a distributed database according to claim 1, characterized in that: In step S1, each electronic shelf label is assigned a unique location identifier at the hanging point level. Specifically, this includes generating a structured location code based on the store identifier, display area identifier, shelf identifier, shelf layer number representing the hanging point level, and the sequential index at that layer. The location code is stored in the product location data model as the location identifier.

3. The method for constructing location-based electronic price tag data based on a distributed database according to claim 1, characterized in that: The construction of a multi-attribute product data model in S2 specifically includes: receiving product master data from an enterprise resource planning system, wherein the same standard product unit corresponds to multiple product variants containing different color and size attributes, generating an independent product identifier for each product variant, and storing the product attributes containing color, size, and price attributes as inherent fields associated with the product identifier.

4. The method for constructing location-based electronic price tag data based on a distributed database according to claim 1, characterized in that: The dynamic binding relationship in S3 also includes a binding type field and a display template identifier field. When a product price promotion event is detected, the binding type in the dynamic binding relationship record is updated to the promotion type, and the display template identifier is updated accordingly to trigger the electronic price tag to switch to the promotion display style.

5. The method for constructing location-based electronic price tag data based on a distributed database according to claim 1, characterized in that: The process of generating the display data packet in step S4 includes the following steps: Based on the product identifier associated in the dynamic binding relationship, query the multi-attribute product data model to obtain the current product price, color, and size information; Based on the display area level or current marketing status of the electronic price tag, a target display template is matched from multiple preset display templates. The display template defines the text content, layout, and style in a structured data format. The acquired product information is populated into the target display template to generate a display data package containing location identifiers, product information, and template rendering instructions.

6. The method for constructing location-based electronic price tag data based on a distributed database according to claim 1, characterized in that: The distributed database uses a strategy of horizontal sharding based on location region hierarchy to store the location data model and the dynamic binding relationship, while the product data model uses a strategy of horizontal sharding based on product brand identifier.

7. The method for constructing location-based electronic price tag data based on a distributed database according to claim 1, characterized in that: When the display data packet is sent to the target electronic price tag corresponding to the location identifier, an update instruction is sent through the message middleware, specifically including the following steps: The display data set is encapsulated into a lightweight JSON message and published to a specified topic in the message middleware; Gateway devices deployed at the store site subscribe to the topic and receive update instructions for electronic shelf labels within their jurisdiction; The gateway device sends update commands to the target electronic price tag via a low-power wireless communication protocol.

8. The method for constructing location-based electronic price tag data based on a distributed database according to claim 4, characterized in that: The dynamic binding relationship in S3 also stores at least one time condition field, which is used to record the effective time range of the binding or the planned price change time. Based on the comparison result between the current time and the time condition field, the system automatically triggers the update of the binding status, binding type or display template identifier in the dynamic binding relationship.

9. The method for constructing location-based electronic price tag data based on a distributed database according to claim 5, characterized in that: The generation of the display data package in S4 also includes matching the target display template from a set of multiple preset display templates based on the category attributes or preset marketing rules in the product data model. Different template layouts and visual emphasis elements are preset for different product categories or different marketing rules.

10. The method for constructing location-based electronic price tag data based on a distributed database according to claim 7, characterized in that: Before issuing update instructions via the low-power wireless communication protocol, the gateway device also performs local instruction queue management and priority scheduling. Promotional instructions or inventory correction instructions marked as high priority are issued first, and instructions that fail to be issued are retried locally according to a preset retry strategy. At the same time, the final execution result is fed back to the cloud system.

Images