Changes between Version 2 and Version 3 of RelationalModel


Ignore:
Timestamp:
04/20/26 00:11:23 (13 days ago)
Author:
231169
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • RelationalModel

    v2 v3  
    99- Релациониот модел е строго модуларен и е поделен на четири главни потсистеми: '''Identity''' (корисници и улоги), '''Catalog''' (производи и категории), '''Inventory & Fulfillment''' (складирање и физички примероци) и '''Sales & Engagement''' (продажба и корисничка интеракција). Оваа поделба овозможува висока скалабилност и полесно одржување на интегритетот на податоците.
    1010
    11 - '''Модул за Идентитет (Identity):''' Централниот ентитет е табелата `USERS`, која е разделена од `USER_PROFILES`. Оваа нормализација е направена со цел автентикациските податоци (`email`, `password_hash`) да бидат изолирани од личните податоци (`first_name`, `last_name`, `phone_number`). Врската е 1:1, каде `user_id` во профилот е UNIQUE. Улогите (admin, customer, seller) се чуваат во шифрарникот `ROLES` и се доделуваат преку меѓутабелата `USER_ROLES`, што овозможува еден корисник да има повеќекратни улоги во системот.
     11- '''Модул за Идентитет (Identity):''' Централниот ентитет е табелата `USERS`, која е разделена од `USER_PROFILES`. Оваа нормализација е направена со цел автентикациските податоци (`email`, `password_hash`) да бидат изолирани од личните податоци (`first_name`, `last_name`, `phone_number`). Врската е 1:1, каде `user_id` во профилот е UNIQUE. Улогите (admin, customer, seller) се чуваат во шифрарникот `ROLES` и се доделуваат преку меѓутабелата `USER_ROLES`.
    1212
    13 - '''Каталог и Варијанти (Catalog & Product):''' Моделот користи напредна хиерархија за производите:
     13- '''Каталог и Варијанти (Catalog & Product):''' Моделот користи хиерархија за производите:
    1414    - Табелата `CATEGORIES` користи „self-reference“ (`parent_category_id`) за креирање на неограничени нивоа на категории и подкатегории.
    15     - `PRODUCTS` го чува општиот концепт на производот (бренд, опис), додека `PRODUCT_VARIANTS` е клучната табела каде се дефинираат специфичните варијации (боја, меморија) со сопствен SKU и цена.
    16     - За дополнителна флексибилност, користиме '''EAV (Entity-Attribute-Value)''' пристап преку табелите `PRODUCT_ATTRIBUTES` и `PRODUCT_ATTRIBUTE_VALUES`, што овозможува додавање на нови карактеристики за производите без промена на шемата на базата.
     15    - `PRODUCTS` го чува општиот концепт на производот (бренд, опис), додека `PRODUCT_VARIANTS` е клучната табела каде се дефинираат специфичните варијации со сопствен SKU и цена.
     16    - За дополнителна флексибилност, користиме EAV (Entity-Attribute-Value) пристап преку табелите `PRODUCT_ATTRIBUTES` и `PRODUCT_ATTRIBUTE_VALUES`, што овозможува додавање на нови карактеристики за производите без промена на шемата на базата.
    1717
    1818- '''Инвентар и Серијализација (Inventory & Fulfillment):''' Ова е јадрото на системот каде се прави дистинкција помеѓу логичка и физичка залиха:
    1919    - `INVENTORY_ITEM` ја чува агрегираната количина по магацин и варијанта.
    20     - `PRODUCT_INSTANCE` е ентитетот кој го следи секој поединечен физички артикл преку `serial_number`. Ова е клучно за бизнис логиката на BlinkBuy, бидејќи овозможува точно следење на гаранциите (`WARRANTY`) по парче.
    21     - Табелата `ORDER_ITEM_ALLOCATIONS` служи како '''bridge''' помеѓу продадената ставка (`ORDER_ITEMS`) и конкретниот физички примерок (`PRODUCT_INSTANCE`). Ова овозможува поддршка на `quantity` > 1 во нарачката, додека во позадина се алоцираат соодветен број на различни физички инстанци.
     20    - `PRODUCT_INSTANCE` е ентитетот кој го следи секој поединечен физички артикл преку `serial_number`. Ова е важно за бизнис логиката на BlinkBuy, бидејќи овозможува точно следење на гаранциите (`WARRANTY`) по парче.
     21    - Табелата `ORDER_ITEM_ALLOCATIONS` служи како мост помеѓу продадената ставка (`ORDER_ITEMS`) и конкретниот физички примерок (`PRODUCT_INSTANCE`). Ова овозможува поддршка на `quantity` > 1 во нарачката, додека во позадина се алоцираат соодветен број на различни физички инстанци.
    2222
    2323- '''Продажба и Логистика (Sales & Shipping):'''
    2424    - `SHOPPING_CART` работи исклучиво на ниво на варијанта (`variant_id`) за да се оптимизираат перформансите и да се избегне предвремено резервирање на сериски броеви во фаза на купување.
    25     - `PAYMENTS` табелата дозволува повеќе записи за една нарачка, поддржувајќи логика на повторни обиди при неуспешно плаќање (retries).
     25    - `PAYMENTS` табелата дозволува повеќе записи за една нарачка, поддржувајќи логика на повторни обиди при неуспешно плаќање.
    2626    - `SHIPMENTS` и `SHIPMENT_ITEMS` овозможуваат една нарачка да биде поделена во повеќе пратки (split shipments) доколку производите се наоѓаат во различни магацини (`WAREHOUSES`) на продавачот.
    2727