Post by matteoraggi » Fri Jun 27, 2014 6:49 am

Is it better Msql or Msqli? Why?

http://www.restaurantsupplies.eu Restaurant Supplies
Opencart 1.5.6.4 VQMOD 2.4.1
Languages: Italian, French, German, Hungarian, English, Russian, Polish and Spanish


Active Member

Posts

Joined
Fri Apr 10, 2009 8:16 pm

Post by beipink » Fri Jun 27, 2014 12:46 pm

Msqli is newer and has more features -> http://php.net/manual/en/mysqli.overview.php
that said, PDO would be a better option

Active Member

Posts

Joined
Tue Mar 20, 2012 7:43 pm

Post by straightlight » Fri Jun 27, 2014 9:30 pm

that said, PDO would be a better option
+ 1 on that.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by IP_CAM » Sat Jun 28, 2014 1:54 am

Faster is usually 'better', independent from what one uses. At least, if it works.
This could be good reason to check into the matter more from the point of existing
'enhancements', possibly not available for different DB-Types. I explain:

I am not sure yet, but after I found the Link below and heated up very heavy, so, i immediately
converted my MySQL DB Storage Engine from MyISAM to InnoDB, it sure just looks like I moved
from an old VW 34 hp Beatle up to a 340 hp Audi Quattro, after creating first tests on a larger Product scale.

(...without any saving before, I was just TO hot to see results. But don't do such ever,
if you have any REAL Data on your DB...! If one deletes the 'first shot' of Products, for any reason,
all products, existing before using the 'one' found OC 'Mass-Product-Generator', are gone..)

Not here, after the DB-Upgrade/Mod, everything worked as before:
http://forum.opencart.com/viewtopic.php ... 84#p602699
http://www.ipc.li/os/opencart-turbo-master.zip

Since I added some other indexing/caching-routines before as well, I am not sure, wheter
the DB-Change on itself, or then the 'combined' action with other cache/indexing-Mod's,
is finally responsible for the dramatic speed increase, even allowing to 'leave' Product Counting alive!

I autouploaded 5'000 Products in english language as well as 5'000 Products in German (the tool cannot do both in one step), creating exactly 10'000 DB Product Lines (eventually many more in other DB sections as well, I did not check). In category View, it now builds a (from lowest priced up) not default SORTED ~750 Product-Display Cat-Page internally usually below 3 seconds. By nature of the web-transport-Delay, using (Swiss) DSL, it takes 2-5 times longer to get the full 13'832 line page displayed on the Browser Screen. So, it comes closed to what one could expect from an 'grown up' software.

http://www.ipc.li/shop/index.php?route= ... &limit=999

just to mentioned it here. It, therefore, can be done! And I am sure, it's even possible to tune the Engine near 400 hp, if indexing will be used, wherever possible, as well as caching, but here, limit's exist, i.E. within a Header-Section, in a multi-language Shop. There, it may prevent Language-Changes in the MAIN Category-Links Header Line as well as correct Product Re-Counting/Linking, eventually even displays links to sections (and their Products), existing (possibly, and therefore displayed) in one language only (like after using the generator). Exept one would write a piece of code, clearing ALL Cache-Files BY DEFAULT, if any (clicked on) language change occurres. Something like this..., one always has to consider the worst possible case...

PS. I left the Product-Counting ON, on purpose, I want it to stay in my HEADER MENU-Cat-Links, Visitors MUST have a chance to see, if and where something exists. Still, don't look at the Numbers, displayed in the Menu-Section, the Auto-uploader used does not get along well with a multi-language Shop. Therefore, it displays (probably) just the amount of Products, collected from the english Products, but it possibly displays (some) Products as well, not belonging to the english language Selection. Since, in the RUSH, I used the same language sheet for both entries, so, I cannot say, wich belongs to wich..., I just see them in the DB, numbered either with a '0' or then a '1', defining, in wich language to be 'active'...

I just know that it does the same with Product Pages as well, I experienced some unreachable Link-entries, they showed up as not valid, when called in this language, or then, it broke some Product Pages in Peaces, because of trying to include (clicked on) options (my fault!), not existing, or miss-interpreting 'my' Source, therefore leaving 'open' sections and broken following content on the Page-Display...

The tool has problems, since it's made for a DEFAULT OC, in my shop, certain 'listings', like featured, latest, etc., display not longer in bother languages, any added stuff, like VqMods or hardcoded things, can make the tool to screw up a little - here and there. But this is no Problem, it's a testing Devise, just preset for most needed content, and with some DEFAULT Option settings built in, nothing else, after uploading and deleting a few thousand items, one will get used to it! It was a great Help in order to create such an amount of Sample Products to test the shop in real. Thank you , iSense, for this very great Tool !

Sorry, but it needs to be explained in detail, OC goes around the world, and not everybody is english PRO...

...neither am I!
Good Luck!

Ernie

My Github OC Site: https://github.com/IP-CAM
5'600 + FREE OC Extensions, on the World's largest private Github OC Repository Archive Site.


User avatar
Legendary Member

Posts

Joined
Tue Mar 04, 2014 1:37 am
Location - Switzerland
Who is online

Users browsing this forum: No registered users and 26 guests