{"slug": "why-even-advanced-ai-breaks-stock-registers-12-years-of-snapshot-log-evolution", "title": "Why Even Advanced AI Breaks Stock Registers: 12 Years of Snapshot Log Evolution and RDBMS Physics", "summary": "A developer with 12 years of experience building high-load systems explains why advanced AI assistants and junior developers often break stock registers by applying textbook SQL solutions. The article details four fundamental pain points of stock registers and presents the Snapshot Log architecture, which uses O(1) state snapshots instead of costly SUM queries or window functions.", "body_md": "If you have ever designed inventory accounting, an ERP system, or billing, you know: **calculating stock balances is a minefield**.\n\nIn SQL textbooks, everything looks clean: run `SUM(quantity)`\n\nover transaction history or use a `ROW_NUMBER()`\n\nwindow function — done. But as soon as the system grows to millions of rows, these \"pretty\" academic solutions turn the RDBMS into a sluggish bottleneck. And when real business scenarios appear (negative sales, backdated documents, on-the-fly manufacturing), cost price quietly explodes exponentially.\n\nWhat's worse, modern AI assistants and incoming junior \"optimizers\" think strictly in terms of these textbooks. They see low-level RDBMS hacks in the code, panic, make the code \"clean\"... and a week later, the accounting department receives garbage data.\n\nIn this article, I'll break down 4 fundamental pain points of stock registers, explain the query optimizer physics of MySQL/MariaDB, and demonstrate the **Snapshot Log** architecture we arrived at after 12 years of developing high-load systems.\n\n`SUM()`\n\nand the Physics of the LIMIT Hack\n`SUM()`\n\nand Window Functions Kill the Database\nCalculating stock balance via `SUM(quantity)`\n\nacross the entire transaction history on multi-million row datasets is a classic architectural mistake. $O(N)$ complexity on every single check turns any report into an hour-long wait.\n\nThe second attempt by \"academics\" is using window functions:\n\n```\n-- Pseudo-pretty textbook SQL\nSELECT item_id, warehouse_id, remains_quantity\nFROM (\n    SELECT item_id, warehouse_id, remains_quantity,\n           ROW_NUMBER() OVER (PARTITION BY warehouse_id, item_id ORDER BY dt DESC, id DESC) as rn\n    FROM stock_register\n    WHERE dt <= '2026-07-01'\n) t WHERE rn = 1;\n```\n\n**The Physics of Disaster:** In MySQL/MariaDB, this query on large volumes leads to a fatal `filesort`\n\n. The engine is forced to create a temporary table on disk, scan gigabytes of indexes, and sort them in a temp file. Performance drops by orders of magnitude.\n\nInstead of a simple movement log, we store a **state snapshot (Snapshot Log)**. Every document execution increments two numbers:\n\nremains_quantity(new) = remains_quantity(old) + Δqty\n\nCalculation complexity is O(1). The current balance is always the **last recorded row**.\n\n`LIMIT`\n\nHack and the AI Dead End\nTo fetch the last row without window functions, subquery grouping is used. But RDBMS query optimizers are \"smart\": if you write a standard subquery with `ORDER BY`\n\n, the optimizer simply discards the sorting, and `GROUP BY`\n\nreturns random rows.\n\nTo force the engine to actually sort the data, **forced subquery materialization** is applied:\n\n```\nSELECT \n    r.warehouse_id, \n    r.item_id, \n    IFNULL(remains_quantity, 0) AS remains,\n    IFNULL(remains_costsum, 0) AS sumremains\nFROM (\n    SELECT warehouse_id, item_id, remains_quantity, remains_costsum\n    FROM stock_register\n    WHERE dt <= :target_dt\n      AND warehouse_id IN (:warehouses)\n      AND item_id IN (:items)\n    /* Subquery materialization + sorting triad */\n    ORDER BY dt DESC, is_overplus_neg ASC, id DESC \n    LIMIT 9999999999\n) AS r\nGROUP BY warehouse_id, item_id;\n```\n\nProduction Drama:The same story repeats regularly. A new developer (or AI assistant) arrives, sees the wild`LIMIT 9999999999`\n\n, and thinks:\"What a hack! Let me make this clean and remove the LIMIT\". The query suddenly flies, everyone is happy, and a day later stock balances break because MariaDB grouped random rows.\n\nIn an ideal world, negative inventory doesn't exist. In real business — a cashier makes a mistake, an invoice wasn't posted in time, physical goods were dispatched, but they aren't in the database yet.\n\nIf negative balances are allowed, a mathematical anomaly occurs. If item balance goes down to `-5`\n\nunits at zero cost, and then a batch arrives at $100, basic school math produces a wild distortion in cost price.\n\n`is_overplus`\n\n):`is_overplus = 1`\n\n) that keeps the balance at zero.`remains_costsum`\n\nis `lastprice`\n\n)remains_costsum = remains_quantity * lastprice\n\nIn food service or retail, nobody creates separate \"Production\" documents before selling every burger or cup of coffee. Items are sold \"on the fly\".\n\nAt that exact moment, a transit calculation occurs within a single document:\n\n`parentid`\n\n) are written off the warehouse, establishing cost price.`id`\n\n) is received for the total cost of ingredients and `remains_quantity`\n\nfor the dish itself doesn't change (stays 0), but financial accounting records the exact cost price expense without distorting the warehouse average price.When a user enters a document dated last Tuesday, the entire chain of calculated stock balances (`remains_quantity`\n\n, `remains_costsum`\n\n) after that date becomes invalid.\n\nRecalculating 5 years of history is suicide for the database.\n\nTo solve this, the **\"Point of No Return\" ( $mindt)** algorithm is used. We find the date of the last guaranteed positive receiving transaction for the items:\n\n```\nSELECT warehouse_id, item_id, MAX(dt) AS mindt\nFROM stock_register\nWHERE dt <= :target_dt\n  AND is_overplus = 0 \n  AND quantity > 0\nGROUP BY warehouse_id, item_id;\n```\n\nAll calculations and recalculation cascades are cut off by the condition `dt >= $mindt`\n\n, reducing scanned data volume by 90–95%.\n\nInventory accounting isn't about \"pretty code.\" It's about understanding the query physics of a specific RDBMS, managing transactional integrity, and handling edge-case mathematics.\n\nExplaining these rules every time to new developers or arguing with LLM models that constantly try to drop `LIMIT 9999999999`\n\nor rewrite queries with `ROW_NUMBER()`\n\ngets exhausting fast.\n\nThat's why I packed this entire 12-year architecture, sorting triad, `is_overplus`\n\nlogic, and MariaDB hacks into a **specialized system prompt (AI Trainer)**.\n\nIf you use AI assistants to generate SQL and design backend architecture, you can simply plug this system prompt into context. After that, any AI starts generating verification queries, DDL, and recalculation functions strictly according to senior engineering standards, without rookie mistakes.", "url": "https://wpnews.pro/news/why-even-advanced-ai-breaks-stock-registers-12-years-of-snapshot-log-evolution", "canonical_source": "https://dev.to/alexcrazy74/why-even-advanced-ai-breaks-stock-registers-12-years-of-snapshot-log-evolution-and-rdbms-physics-17j7", "published_at": "2026-07-29 05:11:41+00:00", "updated_at": "2026-07-29 05:30:57.083340+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence"], "entities": ["MySQL", "MariaDB"], "alternates": {"html": "https://wpnews.pro/news/why-even-advanced-ai-breaks-stock-registers-12-years-of-snapshot-log-evolution", "markdown": "https://wpnews.pro/news/why-even-advanced-ai-breaks-stock-registers-12-years-of-snapshot-log-evolution.md", "text": "https://wpnews.pro/news/why-even-advanced-ai-breaks-stock-registers-12-years-of-snapshot-log-evolution.txt", "jsonld": "https://wpnews.pro/news/why-even-advanced-ai-breaks-stock-registers-12-years-of-snapshot-log-evolution.jsonld"}}