Right now my product related data is being fetched from wp_posts table whereas i want it to be fetched from wpstg0_posts table.
Both the tables are in the same database, i cannot merge the data as it would collide the ID's in both.
Basically I want the products and all the related data to be fetched from prefix wpstg0_ instead of wp_
You Can't Do That™.
Well, you probably could, but you'd break a lot of code in WordPress core, and in the theme and plugin ecosystems. It would take a long time to develop your changes, and you'd be fixing bugs forever. Plus, you would have to backmerge each successive update from WordPress, WooCommerce, and whatever theme and plugins you use.
WordPress and WooCommerce are organized around the uniqueness of post ID values. That is, many features of the meta and taxonomy subsystems use post IDs.
WooCommerce exploits those subsystems to organize products.
You can stand up a different WordPress instance in the same database and give it a different table prefix name.
Are you trying to solve a performance problem? Try putting better indexes on the tables. #RickJames and I have a (free non-monetized) plugin for that. And try implementing a persistent object cache (with redis or memcached).
Related
I am new to MySQL databases and I'm trying to create a web stock and production database, using PHP.
In this inventory software, I am trying to create a table in which products are created and also their components inserted. But if a product has a different number of components, I wanted to know if there is any way to add more components columns from the management page of the website.
Another thing is that these components are taken from another table, and as long as a new product order is created, the quantity of those used components should be subtracted from the components table. (but this is a major issue, solving the first issue should be enough for now).
Yes, you can add, or remove, columns from a database table at any time.
However, I would not do this. You have to try and design a database that can handle products with a varying number of component. Normally this would be done this way:
Create a table for your products.
Create a table for your components.
Create a linking table product_components, to indicate what components a product consists off.
See: Using linking tables for many to many relationships in MySQL
You need to know about relationships in mysql. There are basically 3 types(some may say 4 though) of relationships available in a relational database like mysql.
Here according to your description you can use
1 to many
many to many
relationship in your database. This may help you-
https://afteracademy.com/blog/what-are-the-different-types-of-relationships-in-dbms
I am developing a plugin in WordPress that is about to store configurable entities. They are jobs to be done by Cron. There are plenty of them and each one has name, frequency and some additional data.
There are discussions how to store post-related data in plugins, whether to use postmeta table or own tables. It is officially adviced to use postmeta whenever possible. But what if those entities are not posts? I have 3 possibilities:
Use separate table(s) to store them
Use options table
Make those entities posts with custom post type
I used to keep this kind of information in options table, but how would you do that?
Basically, when you are trying to decide if you need a custom table or not, answer a simple question: does my data need indexes and fast searching? If yes - go with custom tables. If not - e.g.:
this data is being read from database with the post itself - use postmeta
this data is used rarely and is called directly by keys - use options
Else, if you need to store a lot of structured data, perform selects, sorts, or even joins etc - custom db table is your option. Read the docs and do it using core functions and features, like db_delta() function etc. There's nothing wrong in using custom db tables. Just do it right, the "WordPress way".
I'm facing a migration problem on the job. Right now we have a single database which is used by our website and by a backoffice tool.
As part of trying to improve our code in the website, we've desgined a new schema for several tables in the database.
As an example let's take the products table. It's fairly standard with fields like description, name, product code, price, creation date etc. We now have a new table, let's call it better_products. The problem is, we can change the website code all we want, but we can't touch the backoffice tool's code which relies heavily on the old products table.
We're going to end up in a situation in production where the backoffice tool is writing to the old products table, and the website is reading from the new better_products table. The question is, how do we keep both of them in sync? I've been googling around for some time now, and by far the most common solution is to use triggers, and map the incoming data to the new table. I've written the AFTER INSERT trigger for the products, but when I went to write the UPDATE trigger it turned out there's no way to iterate over the fields that changed inside the trigger and map them over. This means writing out the fields by hand a la 'IF NEW.fieldName <> OLD.fieldName THEN' which is ugly and requires listing the fields out by hand.
Is there a better way? a semi-better way? anything except writing this out field by field?
Is there a better practice than using triggers?
Please don't suggest changing the backoffice tool as this is not a realistic option right now. It's planned, but not soon enough for us to be able to wait for it.
Create a view in the mysql database called better_products that is a select statement on the old product but with aliases for the column names that have changed.
Eventually, you can update the code in the backoffice app, to use this view. Once both systems are using the new view, that view can be replaced by an actual table called better_products that has all the data from the old table copied over.
I installed 2 WordPress installations in my site and they share the same database, only, wordpress1 has table prefix of wp1_ and wordpress2 with wp2_ . How can I query the posts from wordpress1(wp1_) to show in the sidebar widget of wordpress2? I can only show posts from wp1_ to wordpress1 (its own table).
It isn't too hard to pull off -- make a copy of the $wpdb object and tinker with it, and wrap calls to the native widget code in that. That is, assuming that the database access credentials are the same. But I wouldn't recommend going this route at all; it is difficult to maintain, and you really should practice proper separation of the concerns. It just takes one slip-up and database A will happily write all over database B.
Have you considered using an RSS widget instead? The http calls could be done over loopback and so shouldn't add much overhead, and the separate databases will remain... separate.
I kind of get how the indexing in Magento works, but I haven't seen any good documentation on this. I would kind of like to know the following.
How it works
What is its purpose
Why is it important
What are the details everyone should know about it
Anything else that can help someone fully understand what indexing is and how it is used in Magento
I think having this information will be of great use for others in my boat that don't fully get the indexing process.
UPDATE:
After the comment on my question and Ankur's answer, I am thinking I am missing something in my knowledge of just normal Database Indexing. So is this just Magento's version of handling indexing and is it better for me to get my answer in terms of Database indexing in general, such as this link here How does database indexing work?
Magento's indexing is only similar to database-level indexing in spirit. As Anton states, it is a process of denormalization to allow faster operation of a site. Let me try to explain some of the thoughts behind the Magento database structure and why it makes indexing necessary to operate at speed.
In a more "typical" MySQL database, a table for storing catalog products would be structured something like this:
PRODUCT:
product_id INT
sku VARCHAR
name VARCHAR
size VARCHAR
longdesc VARCHAR
shortdesc VARCHAR
... etc ...
This is fast for retrieval, but it leaves a fundamental problem for a piece of eCommerce software: what do you do when you want to add more attributes? What if you sell toys, and rather than a size column, you need age_range? Well, you could add another column, but it should be clear that in a large store (think Walmart, for instance), this would result in rows that are 90% empty and attempting to maintenance new attributes is nigh impossible.
To combat this problem, Magento splits tables into smaller units. I don't want to recreate the entire EAV system in this answer, so please accept this simplified model:
PRODUCT:
product_id INT
sku VARCHAR
PRODUCT_ATTRIBUTE_VALUES
product_id INT
attribute_id INT
value MISC
PRODUCT_ATTRIBUTES
attribute_id
name
Now it's possible to add attributes at will by entering new values into product_attributes and then putting adjoining records into product_attribute_values. This is basically what Magento does (with a little more respect for datatypes than I've displayed here). In fact, now there's no reason for two products to have identical fields at all, so we can create entire product types with different sets of attributes!
However, this flexibility comes at a cost. If I want to find the color of a shirt in my system (a trivial example), I need to find:
The product_id of the item (in the product table)
The attribute_id for color (in the attribute table)
Finally, the actual value (in the attribute_values table)
Magento used to work like this, but it was dead slow. So, to allow better performance, they made a compromise: once the shop owner has defined the attributes they want, go ahead and generate the big table from the beginning. When something changes, nuke it from space and generate it over again. That way, data is stored primarily in our nice flexible format, but queried from a single table.
These resulting lookup tables are the Magento "indexes". When you re-index, you are blowing up the old table and generating it again.
Hope that clarifies things a bit!
Thanks,
Joe
Magento indexing is not similar to normal database indexing and is more like database denormalization (http://en.wikipedia.org/wiki/Denormalization) process. In most cases it takes the EAV structure and makes it available for flat table structure which is by no doubt faster to access and search through.
If your normal EAV query would be 200 left joins to get all the products in catalog and data over their attributes and layered navigation values then after "indexing" this data is available through denormalized data structure for faster querying/access
Magento indexing is somehow similar to normal database indexing, but the differece is that you need to do it manually in some case.
when you do indexing, for example the catalog indexing then it make entry of your catalog product in the separate table for the different type of sorting, A small example is store, suppose you have a product and different detail for the different store, then first it will fetch the record from the complex joins in the separate table(when you will perform indexing)
Other best example is layered navigation indexing: if you will run the layered navigation indexing then it will check in the product database for the all shop by filter attribute then on every attribute how may product are available it will also store that value.
Mainly such type of indexing are required if you are doing some direct database changes or though your own custom code
Please let me know if you have other query on indexing