我正在評估不同的電子商務平臺。作爲這項工作的一部分，我正在評估我們目前的產品結構如何適合平臺。像IBM這樣的供應商很容易，因爲他們在網上公開了所有的材料。我對Hybris電子商務越來越感興趣。然而，他們沒有任何可用的材料。他們有我可以訪問的私人wiki，但即使他們的數據模型中沒有任何材料。在Hybris電子商務上創建產品數據模型
款Hybris'代表繼續堅持他們的產品是非常靈活，任何數據模型可以被創建。我相信他們，但仍然存在不應該跨越的邊界，例如GUI和報告顯示某些數據和OOB訂單管理確實依賴於某些數據。爲了充分利用OOB功能，我創建的數據模型必須遵循Hybris的模型。然而，Hybris不允許我看到他們的數據模型，所以我處於雞和蛋類的情況。
現在我的問題是：您是否有在Hybris上建模產品結構的經驗，您是如何處理這個問題的？所有幫助表示讚賞！1！
乾杯！
數據款Hybris模型或者說類型系統是非常靈活的。我一直在努力研究Hybris最近4年的歷史，從未遇到過只要建模就會失敗的情況。 類型系統是Hybris ORM，其中所有Java對象都以XML格式定義，並同時映射到數據庫表和列。所有的java數據類型都被支持，類型集合也被支持。類型系統與數據庫的選擇無關，即使在數據庫更改時，對於items.xml也幾乎沒有任何更改（或極少額外配置）。異常將是CLOB，這將需要在同一個items.xml中再次使用DB供應商特定或等效的DB列數據類型配置。
建模關聯是簡單以及在款Hybris關係方面
現在回來的產品，產品有兩個層次，其可能注重多層次結構。 2個基礎層次結構是Product &產品變體。
讓模型產品爲服裝，也有可能爲4種產品：
所有產品屬性將被保留BaseProduct和Variants將僅保留顏色，尺寸和成本等不同的屬性。
根據產品推斷變體的類型，Product-Variant層次結構路徑將會增長，並且最小化或不重複。
對於建模BaseProduct，唯一強制的屬性是產品代碼和其餘部分，但可選，非常方便。這有助於通過工作流程運行濃縮流程，並有助於實現非常靈活的基礎實施，並可滿足特定需求的附加範圍。
通過服務層服務和加速器即可支持GUI，值得稱道的是，即使增加了大量的自定義屬性，從ITEM驅動到MODEL然後DATA轉換也是如此。實現完全控制從模型到數據填充的數據和數據段。
報告是基於Jasper報告從報告駕駛艙驅動的。靈活的搜索查詢使用JOINS和UNION定義，甚至可以選擇爲報表屬性值填充執行小型Java代碼。
在我看來，建模，轉換，圖形用戶界面和報告都由Hybris完全覆蓋。
款Hybris出來，供各位選擇啓用每個擴展基本數據模型的盒子。此數據模型包含您對電子商務平臺，產品，類別，分類等可能期望的所有內容。
通常，不會期望從此數據模型中刪除任何內容，而只是將其擴展爲新類型和屬性特定於您的應用程序。任何你不想使用的盒子物品或屬性都可以不填充它們。
我的建議是下載和維基安裝最新版本的款Hybris和火起來（我推薦使用本地MySQL數據庫作爲默認的HSQLDB可以有點慢）。設置很簡單 - 您應該能夠在Hybris wiki上找到指南（查看開發者線索）。
一旦你做到了這一點，看看在不同的駕駛艙看到店面演示如何設置。 HMC（http://localhost:9001/hmc/hybris）應該給你一個關於數據模型的良好印象，因爲它的組織與下面的數據模型非常接近。
我建議大家儘量使用標準的各類款Hybris在可能因爲它可以讓你利用其提供的各種業務用戶界面的標準駕駛艙的。