I mentioned it already somewhere. It would be nice to see OpenCart using InnoDB storage engine with foreign keys and maybe even with transactions. Especially if it's an e-commerce application where data consistency is very important.
Row-level locking is probably also better for opencart.
After much research, I chose InnoDB as the storage engine for the underlying mysql database for the social networking site being developed at the company for which I work. After the database design was complete, I posted to one of the firm's blogs explaining why I chose InnoDB. Here's an excerpt:
1.) It is a transaction-safe (ACID compliant) storage engine that has commit, rollback, and crash recovery capabilities.
2.) InnoDB has row level locking and also provides an Oracle-style consistent non-locking read in SELECT statements.
3.) These features increase multi-user concurrency and performance.
4.) There is no need for lock escalation in InnoDB because row-level locks fit in very little space.
5.) InnoDB also supports FOREIGN KEY constraints so that referential integrity can be maintained.
6.) You can freely mix InnoDB tables with tables from other MySQL storage engines, even within the same statement.
7.) InnoDB has been designed for maximum performance when processing large data volumes. Its CPU efficiency is probably not matched by any other disk-based relational database engine. So, we have room to grow.
I'm thinking about altering all the tables of my opencart installation to convert them to InnoDB. Especially after seeing how many queries are going to be needed for the Google Checkout XML Web Service implementation (fully automated customer creation, order creation, processing, etc). Row-level locking will be a must have.
After much research, I chose InnoDB as the storage engine for the underlying mysql database for the social networking site being developed at the company for which I work. After the database design was complete, I posted to one of the firm's blogs explaining why I chose InnoDB. Here's an excerpt:
1.) It is a transaction-safe (ACID compliant) storage engine that has commit, rollback, and crash recovery capabilities.
2.) InnoDB has row level locking and also provides an Oracle-style consistent non-locking read in SELECT statements.
3.) These features increase multi-user concurrency and performance.
4.) There is no need for lock escalation in InnoDB because row-level locks fit in very little space.
5.) InnoDB also supports FOREIGN KEY constraints so that referential integrity can be maintained.
6.) You can freely mix InnoDB tables with tables from other MySQL storage engines, even within the same statement.
7.) InnoDB has been designed for maximum performance when processing large data volumes. Its CPU efficiency is probably not matched by any other disk-based relational database engine. So, we have room to grow.
I'm thinking about altering all the tables of my opencart installation to convert them to InnoDB. Especially after seeing how many queries are going to be needed for the Google Checkout XML Web Service implementation (fully automated customer creation, order creation, processing, etc). Row-level locking will be a must have.
crypsoft
Altering OpenCart tables to InnoDB is not so difficult, but make OpenCart to use it properly with some extra features like foreign keys or transactions requires a bit more work. :) So it's up to core developers.
As far as I know Magento developers go this way. They are using InnoDB with foreign keys (I'm not sure if they are using transactions or not).
As far as I know Magento developers go this way. They are using InnoDB with foreign keys (I'm not sure if they are using transactions or not).
Who is online
Users browsing this forum: No registered users and 1 guest
