Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I just started learning PHP today and I have some conceptual questions regarding how I should use the language and accomplish specific tasks.
My question: Let's say I'm using PHP to build a CMS for a blog. On the home page I would like to have three articles show up that I have marked as "FEATURED" on the back-end in a field named is_featured.
Here is the solution I have come up with and I would like to know if this is possible with PHP, if it's practical, or if there is a better, more efficient way:
I would use a foreach loop to cycle through all $articles as $article and then check to see if that article has the value of FEATURED for the field is_featured.
In practice the articles would (probably, hopefully) be stored in a database in a table articles. You'd query the database for all articles ... WHERE featured = 1 LIMIT 3 ORDER BY publishing_date DESC, then loop through the database result set and output all found articles.
That would work, yes. However, this has the overhead of filling a potentially huge array with all the articles from your DB and then iterating through it to pick the featured ones.
For this kind of task, it's better to have the DB filter the results before sending them to PHP.
In general, try to do all your filtering of data in the database, as database are specially optimized for such queries. Loading them into PHP and then filtering the records is slower and less efficient.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Okay, so currently I'm creating a website from scratch for my small online shop and am stuck on where to even begin when it comes to my Products page. Currently, I have 1 page that displays all 50 of my products. I plan on expanding my products and do not want someone to be scrolling down the whole page. I would like to add multiple pages that you can click through and I believe I can accomplish this through Pagination. Now, this is the part where I get confused : say I only want 25 products to be displayed per page and I add a new item to the first page - how do items get 'bumped' to the page 2, 3 etc.? I would imagine there is some function to accomplish this, but the only way I can think of is doing this the brute force way of manually moving a product out of one page and onto another. Any suggestions??
Currently, my website is coded in all HTML / CSS and I currently just learned how to use PHP to mass edit certain areas of the website -- I am in the learning stages! Any suggestions would help. Thanks!
You need the help of a database to paginate your products in sets.
Basically, the database will have a "Products" table, each row in the table will represent a single product. You will use PHP to ask the database to retrieve the first/next N rows and then write out the appropriate HTML around each returned row to create a list of products.
There are lots of tutorials on the web to help you learn while you practice. Good luck!
There is no way to do that on static HTML web-site.
You need server-side script (e.g. PHP script) for splitting your product list by pages. By the way, you should store your data in DB and it should be done on the DB-side to not overhead your PHP side.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm working on a front-end for a catalog database. So far it is going pretty good, but by the end of this I'll have probably a million rows of items in my database. I know this is more option based, but I wanted feedback on the best of way of doing this.
I was wondering if I should pull all records at once for a list and then use a filter type setup so it shows only items starting with A, or top rating items, then can click b and it would show all items starting with a b as option 1. Option 2 would be fetching the new data from the database upon request. So by default items starting with A will show then when the link/button for items b is click it will connect to the database and fetch those items.
Thoughts and options please!
PS I'm working with bootstrap/php/mysql/jquery/javascript.
Well, don't pull all million records every request.
See LIMIT and OFFSET http://dev.mysql.com/doc/refman/5.0/en/select.html
You should probably use an ORM or library that helps you with pagination
Make sure you understand SQL parameterization (for security)
I find that lists like catalogs are best served from search servers (like Solr) over databases, esp if you want search facets. MySQL does have text search though.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
You find a lot of info on this online. But not what the exact work around of the use of Algorithm is in MySQL. The real basics, if you will..
What a query is, is obvious, of course. What Algorithm does, remains unclear.
Main reason for this question is: to improve profiling & matching records to known users. (In this case: to match docs in a database to users that need them)
Some examples of the usage of it are highly appreciated!
Algorithm is a keyword used with create view in MySQL. The documentation does a pretty good job of explaining it.
The short answer is that MySQL supports two methods of handling views: either "merging" the view definition in the calling code or creating a temporary table. The first is called MERGE and the second TEMPTABLE. In general, MERGE is faster, but most views are TEMPTABLE because of the restrictions on `MERGE.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a system where users can 'like' content. There will likely be many hundreds of these likes going on at once. I'd like it to be AJAX driven so you get an immediate response.
At the moment I have a mysql table of likes which contains the post_id and user_id and I have a 'cached' counter on the posts table with the total number of likes - simple so far.
Would I benefit in any way, from storing any of this information in mongodb to take the load off of mysql?
At the moment, I click like, and two mysql queries run - and INSERT into likes and an UPDATE on posts. If I'm in a large-scale environment in heavy read/write situation what would be the best way to go?
Thanks in advance :)
MySQL isn't a good option for something like this, as a large number of writes will cause scaling issues. I believe MongoDB's real advantage is schemaless JSON document oriented storage, and while it should perform better than MySQL (if set up correctly), I think you should look at using Redis to store counters like this (The single INC command to increase a number value is the cream on top of the cake). It can handle writes much more efficiently than any other database, as per my experience.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm starting a new project and I'm about to take perhaps the most important design decision.
I'll be working with PHP to create dynamic queries on the fly. (I want to provide the users with someting similar to the dynamic tables in MS Excel).
I have like 25 tables with about 4-6 columns each, that I'll be joining depending on user selection (most operations will be calculating AVG, SUM, COUNT, etc depending on some filters of values that are probably 5 to 6 table joins away).
I'm thinking making all these JOINS and SELECTS on the fly as well as the GROUPS BY but it looks like it's going to be quite complicated, so I started thinking about using views to reduce the complexity of the code that dynamicaly builds the query.
I also thought avoiding GROUPS BY in the query and calculate aggregate funcitions using loops and an array in the code.
I would like to know which of these approaches would you recommend or if you have any sugestion or tip will be greatly appreciated.
The only answer that is valid is to create your own framework for that. I've done that quite a few times. What you want looks more or less like a complexe report generator that generates reports on the fly but you want to create a complexe query generator with visual aids for the client.
The first thing i'd do is use a model that represents each table and offers mechanisms to describe the table fields so you can show the user the fields. Then create a linking mechanism in your models that says: if i link this table and this table, what is the JOIN that i should use.
Let your user select the models to your, columns to use and then use your models to create the query for you. It actually works well but takes quite some time to do.
Good luck