I'm using the WP-Property plugin for an estate agents site. They want to use RightMove to display their properties as well, so I'm looking for a way to export the post type 'property' with all its related meta data.
Most of the data for a property is in the posts table, but things like the number of bedrooms, price etc are in the post meta table.
I'm not much of a back end coder, so I think I need an SQL query that will join the two tables together?
I have to convert it to a BLM file for RightMove, but I'm taking it one stage at a time, so getting the data I need out is what I need to do.
Is anyone able to point me in the right direction?
Thanks
Yes you need to write a join where the post_id of postmeta table is equal to the id of posts table
Related
I have an assignment where I need make a table for users which houses basic information like fname,lname,email...etc but I also need to store information about the users location address,zip,city,state...etc. A user can have multiple location information.
I've been just doing a csv but people are telling its pretty bad to do that so I'm trying to do things the right way.
I was learning about many to many and it seems to do the trick. But the problem is I need to load this data to a table for viewing.
I just don't see anyway that this would work without having to do a query inside the first query.
ie:
while($row=mysqli_fetch_assoc($query)){
$id = $row['id'];
///Get user locations based on id here.
}
From what I understand if we're storing user ID lets say to a table to make the relation to the locations table and a user can have multiple locations would join be useless here?
I need to pull up records 25 at a time so it's not only supposed to pull one. I'm using datatables with the collapse/show so the data needs to be in a separate container
The Approach of storing location separately in other table with user_id column will be good and as the user will be unique let's say he is unique regarding his email, his locations can be fetched.
Other approach, You can store locations(multiple) in form of object and fetch them then you can get individual location by decoding the json
I know, there already is similar questions, but I can't find a good answer at my problem.
I'm developing a social network, I have all my users in a table, but each users must be able to save multiple post from the website.
My Question is:
How can I store all the saved post for each user without creating a new table for each users. I know this is bad to do this, so I'm looking for an alternative
If I understand you correctly, you just need a middle table (for example names user_post) that have 2 columns : user_id and post_id
this is a simple implementation of a many-to-many relationship
You only need a table to store all posts call it posts table with structure like this:
|post_id|user_id|title|content|etc..|
So you can do something to save posts and identify them by user_id.
It's called one-to-many relationship, you can search more about database relationships.
This matter is driving me crazy as after wasting days going through my DB I've still been unable to find out an answer to the following question:
Where is the flag "is_visible" stored on the mysql DB for the attributes of Woocommerce products?
I checked all the tables 1000 times but I can't understand where and how the flag option "attribute visible on the product page" is stored on the Wordpress DB.
Thanks!
Enrico
the data is sotered in the postmeta table. However it is not quite straight forward to handle it. If you pick a product and do a search for the product ID as post_id you will see a record with the meta_key _product_attributes. In the meta value you will find a serialised array of the attributes including is_visible.
Just be careful because if you simply edit it in phpmyadmin you can mess stuff up badly. If you don't know what a serialised array is google it.
In case someone is searching for this in the year 2022 or later: In the meantime woocommerce isn't storing this value in the post_meta table. Instead there is a taxonomy called "product_visibility" with different states (exclude-from-catalog, exclude-from-search). In the "term_relationships" table is stored which of these values is associated with a product.
I am making a database that is for employee scheduling. I am, for the first time ever, making a relational mySQL database so that I can efficiently manage all of the data. I have been using the mySQL Workbench program to help me visualize how this is going to go. Here is what I have so far:
What I have pictured in my head is that, based on the drawing, I would set the schedule in the schedule table which uses references from the other tables as shown. Then when I need to display this schedule, I would pull everything from the schedule table. Whenever I've worked with a database in the past, it hasn't been of the normalized type, so I would just enter the data into one table and then pull the data out from that one table. Now that I'm tackling a much larger project I am sure that having all of the tables split (normalized) like this is the way to go, but I'm having trouble seeing how everything comes together in the end. I have a feeling it doesn't work the way I have it pictured, #grossvogel pointed out what I believe to be something critical to making this all work and that is to use the join function to pull the data.
The reason I started with a relational database was so that if I made a change to (for example) the shift table and instead of record 1 being "AM" I wanted it to be "Morning", it would then automatically change the relevant sections through the cascade option.
The reason I'm posting this here is because I am hoping someone can help fill in the blanks and to point me in the right direction so I don't spend a lot of hours only to find out I made a wrong turn at the beginning.
Maybe the piece you're missing is the idea of using a query with joins to pull in data from multiple tables. For instance (just incorporating a couple of your tables):
SELECT Dept_Name, Emp_Name, Stat_Name ...
FROM schedule
INNER JOIN departments on schedule.Dept_ID = departments.Dept_ID
INNER JOIN employees on schedule.Emp_ID = employees.Emp_ID
INNER JOIN status on schedule.Stat_ID = status.Stat_ID
...
where ....
Note also that a schedule table that contains all of the information needed to be displayed on the final page is not in the spirit of relational data modeling. You want each table to model some entity in your application, so it might be more appropriate to rename schedule to something like shifts if each row represents a shift. (I usually use singular names for tables, but there are multiple perspectives there.)
This is, frankly, a very difficult question to answer because you could get a million different answers, each with their own merits. I'd suggest you take a look at these (there are probably better links out there too, these just seemed like good points to note) :
http://www.devshed.com/c/a/MySQL/Designing-a-MySQL-Database-Tips-and-Techniques/
http://en.wikipedia.org/wiki/Boyce%E2%80%93Codd_normal_form
http://www.sitepoint.com/forums/showthread.php?66342-SQL-and-RDBMS-Database-Design-DO-s-and-DON-Ts
I'd also suggest you try explaining what it is you want to achieve in more detail rather than just post the table structure and let us try to figure out what you meant by what you've done.
Often by trying to explain something verbally you may come to the realisations you need without anyone else's input at all!
One thing I will mention is that you don't have to denormalise a table to report certain values together, you should be considering views for that kind of thing...
I'm not a professional, but I'm messing around with wordpress trying to customize it the way I want it to work...
I've a necessity to add additional data to single-posts, specifically a restaurant menu, each post will have unique menu displayed in sidebar.
Single post is a single row in wp_posts table.
I'm adding additional info using wp metabox functionality, which has its own table called wp_postmeta.
This table is different from wp_posts because it can contain many rows of meta information for a single post.
My questions:
Is this implementation slow?
Will it cause problems if db grows?
Why would wp guyz implement this in this way?
Would not it be wiser to have single meta column and multiple rows per post?
I see that you have "price_list_heading", "price_list_category","price_list_heading1", "price_list_category1","price_list_heading2", "price_list_category2","price_list_heading3" and "price_list_category3" I don't know why, but I think you shouldn't do that, you need to create a relational table with index (I don't know if Wordpress let you do that)
it'd will look like: this will depend of the cardinality of your APP
Let's say that 1 post meta can have multiple categories and multiple categories can be with one postmeta (cardinality N:M)
Now If one post can have multiple categories and one category can have only one post
Where wp_postmeta_copy1 is a FK from ws_postmeta table (id)
Please take a look to this documentation :
http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
http://www.inf.unibz.it/~franconi/teaching/2000/ct481/er-modelling/
http://searchsqlserver.techtarget.com/definition/entity-relationship-model