Learn a little more about how Opencart database was modeled
Hi everyone, thurday, day to make a “hands-on” in the blog, and talk about development on the road.
As i promised last week today I will continue to tell you about the structure of the Opencart e-commerce platform, more specifically about their data modeling.
first of all remember that we are talking about a database built in MySql
A lot of tables, and a little bit of mess
On this default installation i’m using 1.5.1 version, the output Opencart account with absurd 89 tables, which in my opinion is overkill, just being common means when compared to other platforms in the same class like Magento.
Looking deeper into the data modeling we can identify some groups of tables, especially the prefix used in the name of the same, the main ones are.
- attribute_…
Responsible for, the product attributes, things that have no relation to the grid or stock, but characteristics.
- banner_…
Thats make sense, is only about advertising
- category_…
Control the categorie tree, responsible by the store navigation
- customer_…
Group almost all customer data, because the address is saved in other table named Address 😐
- information_…
- option_…
Group stock data, likes sizes, colors, etc
- product_…
Product data only it in incredible 16 tables
- return_…
Responsible by RMA system
A lot of things?
Yet there are other smaller and less relevant gruops, but I think seeing that amount of groups and tables you already get an idea of the complexity, not always necessary, included on that database.
All this amount of tables is crafted almost a traditional manner by the models of the system which as I said last week are duplicated between the store and the administrative system because system not uses one framework to encapsulate the queries or data.
Well, i think thats enough for today, on next thursday i will continue to talk to you about Opencart, explaining this time, how VQmod works with the Opencart System.
Hug, see you!
