# info about the structrure of the models

According to the former impementation (atcom) the project will need to handle 200+ tables.
The former project includes 209 tables with 5 or more rows (and 325 tables totaly)



## Partitioning the database schema

Models shall organized in various *thematic entity-groups* in order to handle
the numerous relationd between tables.

* market ~10
  - [Ok] - products = cms_eStore_Products
    - [Ok] - cms_Relationship_SimpleProducts_ProductCategories
  - [Ok] - product_categries = cms_eStore_ProductCategories
  - [Ok] - cms_eStore_PriceLists
    - [Ok] - cms_eStore_Prices,
  - [Ok] - products_to_images (assets)
    - [Ok] - assets (*cms)
  - [Ok] -brands  = cms_eStore_Brands

* sales ~ 15
  - orders  = cms_eStore_Orders
  - orderItems = cms_eStore_OrderItems
  - payments 
  - refunds
  - tracking
  - orderEvents = cms_eStore_OrderEventLogs
  - cms_eStore_OrderStatusDescriptions, 

* care
  - [data] - customers  = cms_YodaAddon_Customers
  - [data] - addresses  = cms_YodaAddon_Addresses
  - [data] - userlists  = cms_YodaAddon_UserLists

* system ~ 5
  - security
  - operators
  - sessions  * cms_UserSessions
  - tokens
  
* cms ~20
  - [?Ok] - about  = cms_Pages
  - stores = cms_YodaAddon_Stores
    - cms_Relationship_Stores_Services
    - cms_Relationship_Stores_Images
    - cms_Relationship_Stores_Services
  - news
  - contests
  - [Ok] - assets
  - snippets, translations, whatever...


Then there shall be connecting-models betweem various entities, like:

* Marketing: combines [market + cms]

* Buing: combines [market + sales + care]



## uncategorized:

* cms_YodaAddon_Companies




NOTE:

Also need to partition the "working-on/preccessing data"

- CMS : content creation, design, etc

- Orders : pick, select, track, manare returns, etc

- Customers: navigate on store, fill basket, order, pay

- Prices: ERP

I suggest each group of proccessing is make by different application.
These applications may *speak* to eachother via API