Why is classic PHPer considered grassroots? _PHP Tutorial-PHP Tutorial-php.cn

Is PHPer grassroots?
Since the birth of PHP, PHP has begun to serve the majority of programmers in web applications. At the same time, as a scripting language tailored for Web development, PHP has always adhered to the idea of simplicity and open source, which has also enabled PHP to develop rapidly and vigorously promoted the emergence and development of Web 2.0. However, for a long time, PHPer (PHP Programmers) have been considered to be programmers at the grassroots level, and are considered to be programmers with low technical content and low level. This is especially true in the country.

I remember a technical director said such a thing. He assigned a programmer the task of developing PHP. Unexpectedly, the programmer actually said: "I am a Java student. If you ask me to write PHP, aren't you belittling me?".This incident left a deep impression on me and touched me greatly. Although this is not the view of most programmers, there should be many people who think so. Others say that if it is a large government project now, PHP will definitely not be included in the consideration.

So why is PHPer considered a grassroots level? Is it because it is very simple and everyone can learn it, so it is not difficult? I used to think so too. Getting started with PHP is quick, and it is very convenient for processing files, data, remote connections, and network programming. Officials also say that the cost of learning PHP is very low, so it is easy for you to use it. This idea is also common, even most PHPers themselves think so.

Having said this, I think everyone will think of why I write these words. Because more than a year of PHP promotion work has allowed me to understand the general situation of many companies using PHP. In these processes, I slowly realized the root cause. What I say here is the fundamental reason is my personal opinion, but I think this is the fact.

So why PHPer is regarded as a grassroots level? The fundamental reason is that most of the things PHPer does (implemented through code) are presentation layer things. Anyone who is familiar with PHP knows this. Of course, there will also be PHP who will talk about the functions of a certain framework written in the MVC structure. But these are still presentation layers. Therefore, programmers who only deal with the presentation layer are regarded as grassroots. In fact, this is true, because in this case it is really difficult for PHP to construct large-scale applications.

That’s the reason, no. Why is PHPer always responsible for the presentation layer? The answer is that we generally don’t touch the underlying data processing (Web applications are data storage and search)! Okay, so when it comes to this, some people may have thought of it, isn’t it a database! Yes, it’s the database! The main culprit that keeps PHPer at the grassroots level is the database. Why?

Because in the current popular web architecture, the front end is a load balancing system, the middle is the web server, and the back is the database server. Therefore, most of PHPer works at the web server level. Because the database has organized the data for us very well. Therefore, there are not many algorithms in PHP, and people subconsciously feel that they are not needed, not to mention that it will affect performance.

In this case, PHPer becomes a database user, and he is always operating the database. Rather than doing a program. One of the simplest PHP scripts is to connect to the database, take out the data, and then use commands to output it to the browser. The entire process takes no more than 10 lines of code. It feels like it's too simple. There is no technical content. Why, because the data processing part has been completed by the database. Especially the use of MySQL! MySQL is free, so most programmers can use it freely. In addition, MySQL is fast enough, so it is very simple to make a PHP application. This is equivalent to giving you a gun and you feel there is no need to learn martial arts. Of course, I'm not saying that guns are not as good as weapons. Rather, with the advent of guns, children can kill people easily and conveniently.

Let’s talk in detail about why it is a database! Here I will give an example. I went to a very famous website in Beijing. At that time, we had a relatively senior PHP programmer talking about system architecture. I remember that when the programmer asked everyone an algorithm question in a data structure, no one in the audience could answer it (including me). Then the programmer started to tell everyone some very basic data structures. Let me immediately think back to the data structure class I learned in college. These basic data sorting, search, and transfer issues are very common in other high-level languages (such as C). But not in PHP! The PHPchina.com forum also has a section called PHP data structures and algorithms. There are also very few posts in this section.

If you think about it carefully, there are two issues that are most discussed on the Internet. One is the use of PHP classes (encapsulation of processing procedures), and the other is the development framework issue. But if we analyze it carefully, we find that there is no data processing in these so-called relatively complex concepts in PHP! Why, there is a database! You can do it with an Adodb or PHP5 PDO! Is it really done? No, these are just connecting to the database, there is no data processing! So PHPer seems to have nothing to bring to the table.

Let’s talk about a specific coding issue, stepless classification. I think everyone is familiar with this concept. I've seen it done two ways. The first one is the authentic PHPer processing method, which is also relatively popular currently. Just use the database to handle it. And there are very few fields. You only need to add a field of the parent class and judge it. And this method is very practical. Efficiency is also high! But this is not the scope of data processing, but database search!
The second one was written by a C programmer using PHP. He took out all the classification information from the database, then used a data structure algorithm to arrange and distribute it, and then output it.
We will not compare the efficiency of these two methods here. I think everyone has their own ideas. But I want to clarify an issue, which is the essential difference between these two approaches.PHPer habitually uses databases for processing, and it has a very clever processing method and is very efficient! This method is database query. The second method is more distinctive. He believes that the database is a place where data is stored, and specific logical processing depends on your own logic.
Therefore, the conclusion is that the user of the second method feels stronger because he organized the logic of the data! And I think PHPer's approach is nothing more than querying the database. So he thinks PHPer is grassroots and only knows how to operate databases and arrange pages (smarty kind).

Speaking of which, I think everyone has recalled a lot of their usual development experience with PHP. Have you discovered that everyone is indeed operating a database?

Then let’s discuss this issue. Is the database bad? Why do I have no problem using the database to process data? What I am saying is that there is something wrong with the database, and there is a big problem! Of course, I am not saying here that you cannot use the database, nor am I belittling the performance of the database. Rather, we do not fully realize the role played by the database.

My idea originated from this incident. Once, the technical director of a website asked me why their website was so slow and what should be done. At that time, the engineer at Zend headquarters in my MSN happened to be online, so I asked him what should I do if PHP responded slowly? He told me directly at that time that there was a database problem! It must be that the database is not optimized and designed well. Therefore, I did not give the technical director a definite answer because we could not get involved in their database design. So I gave some general database optimization suggestions. This happened repeatedly, and I began to wonder why the engineers at Zend headquarters told me every time that it was a database problem. Can't we solve this problem from the PHP level? The answer is no! Because PHP currently runs very fast, you can also see a user's click through Zend's performance analysis. PHP's running time is less than 10%, so what is PHP doing? It's waiting. Waiting for database query results. This aspect has been greatly improved in current PHP products, namely Caching and web page staticization. Caching may be unfamiliar to everyone, but now even users of PHP products are very aware of the static nature of the Internet. It’s fast, easy to be searched, etc. The benefits are self-evident. Jokingly speaking, to achieve static web pages on the homepage of a website, the hard drive only needs to be large enough. J As for Caching, it is more complicated, and it is also a headache for most PHPers. Some people even use C to implement it. Because the data validity period verification, search, extraction, update, etc. in Caching are more difficult to handle. Of course, some people will use databases to deal with Caching issues.

So, when the traffic surges, many problems that will occur in PHP-structured websites are caused by the database. The database synchronization problem is not a big deal. The key is that the response speed of the database will decrease exponentially. I asked the vice president of MySQL this question during the LAMP conference on October 23. He didn't give me a perfect answer at the time (which I expected), because there will always be bottlenecks in the database, unless it is a fairy database, haha!
Here is a digression. When I was chatting with a technical executive from Yahoo during the LAMP conference, I asked him what Yahoo considered when choosing MySQL or Oracle. His answer surprised me very much. He said that most of the time we will use MySQL because its performance has met our requirements. But when will we choose Oracle? That is when we need to store the data of paid users. I asked why, is Oracle more stable than MySQL? He said that he had not given any special consideration to this. The key is that if we use Oracle, we can find the person in charge when a problem occurs, and Oracle will be responsible for handling the incident. But if we use MySQL, who should we go to?

So, our view of the database should be corrected, that is to say, the database is not omnipotent. If you have the ability, develop your own database. I heard that Google is like that.

So what do we think about the database? My personal understanding is that the database is just a means to reduce development costs. Because after using the database, we do not need to consider data storage, especially sorting and searching. But what problems does this cause? Just when the business expands, the database becomes the bottleneck! The problem will be very difficult at this time! Because this is the underlying data processing. A single move affects the whole body.
So I think the correct point is that the database is a data backup machine! How to understand, we only need to ensure the validity of data storage. This is originally the core function of the database, but because of the convenient sorting and other functions of the database, everyone has to leave too much processing to the database. When a user clicks on PHP, a lot of tasks are handed over to the database, and then the results are sorted and given to the user. This is unfair to the database! That's why everyone started complaining about the performance of the database.

In response to this point of view, let’s give another example. Once I visited a large Internet company (basically anyone in China who has accessed the Internet knows it). They rarely use PHP, but I learned that they How other businesses use databases. They proudly introduced to me that they have a second database outside the database (I named it the second database here). Why is it called the second database? It turns out that it is a caching system. So how do development engineers get data from this cache system? The technical director proudly said that their caching system consists of SQL query statements! I was surprised at the time, but then I thought I really needed this. Because when your cache system reaches a certain level, it is very complicated to obtain data from the cache. Simply write a SQL query statement and let the cache system analyze, process and return the data. And they told me that in their place, even if PHP is used, PHP is asked to read the data from the cache system.

So, if you can handle this problem, store the data in the database, and then the database will only serve as a backup. Then you use your own middle layer to process and analyze the data. The effect is that more than 90% of users access the database without accessing it. Some people will say, isn't this something similar to a connection pool? Yes! Because the bottleneck of the database cannot be solved, we can only add an intermediate layer between the web server and the database for buffering.

Maybe you will say, Tsk, we already knew this! Well, what I want to say here are two thoughts it triggered:
First, some languages already have connection pool technology, and programmers can easily use connection pools to build large-scale applications. So if they think that PHPer will only use the database, can we say that they will only use the connection pool? What is the conceptual difference between connection pooling and database?

Second, when PHPer started to build its own caching system, did he break through the level that PHPer would only use the database? Because he is involved in the processing of data logic. So is he still a grassroots person?

Finally, are the new generation of PHPer grassroots?