AIAZHコアテーブル：商品とカテゴリ
商品テーブルは基盤となります。フィールドにはproduct_id（PK）、sku（在庫管理単位）、barcode、product_name、description、category_id（FK）、brand、unit_price、cost_price、tax_rate、unit_type（piece/kg/liter）、is_active、image_urlが含まれます。カテゴリテーブルは商品を階層的に整理します：category_id（PK）、name、parent_category_id（サブカテゴリ用の自己参照FK）、sort_order。適切に設計されたカテゴリツリーは部門別レポートをサポートします。
在庫管理
在庫テーブルは複数の拠点で在庫量を追跡します：inventory_id（PK）、product_id（FK）、store_id（FK）、quantity_on_hand、quantity_committed（未完了注文向けに確保済み）、reorder_point、reorder_quantity、last_count_date。在庫移動テーブルはすべての在庫変動を記録します：movement_id（PK）、product_id（FK）、store_id（FK）、movement_type（入荷/売上/返品/調整/移動）、quantity、reference_document、movement_date、performed_by。この監査証跡は棚卸し時の差異特定に不可欠です。
売上トランザクションのスキーマ
売上スキーマはヘッダー・明細パターンに従います。sales_ordersテーブル（ヘッダー）には、order_id（PK）、store_id（FK）、customer_id（FK）、employee_id（FK — レジ担当）、order_date、order_time、subtotal、discount_total、tax_total、grand_total、payment_status、order_statusが記録されます。sales_order_itemsテーブル（明細）は各商品行を記録します：order_item_id（PK）、order_id（FK）、product_id（FK）、quantity、unit_price_at_sale、discount_percent、line_total、returned_quantity。商品価格は時間とともに変動するため、unit_price_at_saleの保存は非常に重要です。
決済処理
支払いテーブルは1取引あたりの複数の支払方法を処理します：payment_id（PK）、order_id（FK）、payment_method（cash/card/UPI/credit/voucher）、payment_amount、reference_number（カード/UPI取引用）、payment_date、is_verified。分割払いの場合、複数の行が同じorder_idに紐付けられます。別途のレジテーブルでは現金drawer操作を管理します：register_id（PK）、store_id（FK）、opening_balance、closing_balance、opened_by、closed_by、opening_date、closing_date、expected_cash、variance。
顧客関係管理
顧客テーブルには、customer_id（PK）、first_name、last_name、phone、email、date_of_birth、anniversary_date、loyalty_points、total_spent、registration_date、is_vipが格納されます。ポイント取引テーブルでは注文ごとの獲得・消化ポイントを追跡します。チェーン店向けの顧客住所テーブルは複数の住所を持つ配達注文をサポートします。顧客テーブルはsales_ordersのcustomer_id FKを通じて売上スキーマと連携し、購入履購入履歴やパーソナライズされたオファーなどの機能を実現します。
マルチストアアーキテクチャ
チェーン店向けに、storesテーブルは各拠点を定義します：store_id（PK）、store_name、address、city、state、phone、tax_registration_number、is_active。店舗間の転送注文にはtransfer_ordersテーブルを使用します：transfer_id（PK）、from_store_id（FK）、to_store_id（FK）、product_id（FK）、quantity、status（requested/approved/shipped/received）、request_date、completion_date。この構造により、集約レポートと分散型オペレーションの両方をサポートします。
POSデータベースのベストプラクティス
すべての売上にデータベーストランザクションを使用してください — いずれかの明細行の挿入が失敗した場合、注文全体がロールバックされます。レジでのミリ秒以下の商品検索のためにbarcodeカラムにインデックスを付与してください。ハイコンカレンシー期間中の過剰販売を防ぐため、在庫テーブルに楽観的ロック（バージョン番号カラム）を実装してください。過去の売上クエリを高速化するため、sales_order_itemsをorder_dateでパーティショニングしてください。浮動小数点の丸め誤差を防ぐため、金額は常に最小通貨単位（セント/ペニ）で整数として保存してください。
