I remember a technical director said such a thing. He assigned the development task of PHP to a programmer. Unexpectedly, the programmer said, "I am from Java, and you asked me to write PHP. Aren't you belittling me? " . This incident impressed me deeply and touched me greatly. Although this does not represent the views of most programmers, there should be quite a few people who think so. Others say that if it is a large government project now, PHP will definitely not be considered.
So why is PHPer considered as a grassroots? Is it not difficult because it is simple and everyone can learn it? I used to think so. PHP is easy to use, and it is very convenient to handle files, data, remote connection and network programming. There is also an official saying that learning PHP is cheap and easy to use. This idea is also very common, and even most PHPer himself thinks so.
Having said that, I think everyone will think about why I wrote these words. Because the promotion of PHP for more than a year has made me know a lot about companies that use PHP. In these processes, I gradually realized the root cause. What I am talking about here is the root cause. Although it is my personal opinion, I think this is the truth.
So why is PHPer regarded as the grassroots? The root cause is that most of what PHP does (through code) is the presentation layer, and everyone familiar with PHP knows it. Of course, there will be PHP that will talk about the functions of a framework written in MVC structure. But these are still presentation layers. So programmers who only deal with the presentation layer are grassroots. In fact, it is true, because it is really difficult for PHP to construct large-scale applications in this case.
That's why, no, why is PHPer always in charge of the presentation layer? The answer is that the underlying data processing (Web application is data storage and search) is generally not touched by us. Well, someone here may have thought of it. Isn't that a database Yes, it is the database. The main culprit in leaving PHPer at the grassroots level is the database. Why?
PHPer relies too much on MySQL.
Because in the current popular web architecture, the front end is the load balancing system, the middle is the web server, and the back end is the database server. Therefore, most PHPer work at the Web server level. Because the database organizes the data for us well. Therefore, there are not many algorithms in PHP, and everyone subconsciously feels unnecessary, not to mention it will affect performance.
In this case, PHPer becomes a database user, and he is always operating the database. Instead of doing a program. One of the simplest PHP scripts is to connect to the database, take out the data, and then output it to the browser with commands. The whole process does not exceed 10 lines of code. It feels 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, and MySQL is fast enough, so it is very simple to make a PHP application. This is equivalent to giving you a gun, and you don't think it is necessary to learn martial arts. Of course, I'm not saying that guns are inferior to weapons. Instead, with the appearance of guns, children can kill people easily and conveniently.
Let's talk about why it is a database. Let me give you an example here. I have been to a famous website in Beijing. At that time, we had a senior PHP programmer talking about system architecture there. I remember when the programmer asked you a question about the algorithm in the data structure, no one in the audience (including me) could answer it. Then the programmer begins to tell you some very basic data structures. This reminds me of the data structure class I took in college. These basic data sorting, searching and transmission problems are very common in other high-level languages (such as C). But not in PHP. PHPchina.com's forum also has a section called PHP's data structure and algorithm. There are also few posts in this section.
Speaking of which, do you understand? Most PHPer only deals with the presentation layer, but with the convenient use of MySQL, PHPer can complete most development tasks without touching any data structures and algorithms, so only one of them has more than that, and no PHP programmer can answer the question of that data structure. If it is a language such as C, the situation may be very different. It is the root of PHP that makes PHP look very grassroots.
Looking back carefully, there are two issues that are most discussed online at present. One is the use of PHP classes (encapsulation of processing procedures), and the other is the development framework. But after careful analysis, we find that these so-called complex concepts in PHP have no data processing. Why? There is a database. It can be done with Adodb or PDO of PHP5. Is it really done? No, these are just connected to the database, and there is no data processing. So PHPer seems to have nothing to say on the table.
Let's talk about a specific coding problem, stepless classification. I think everyone is familiar with this concept. I've seen two ways to deal with it. The first is the authentic PHPer processing method, which is also popular at present. Is to use the database to process it. And there are few fields, just add a field of the parent class and judge. And this method is very practical. The efficiency is also high. But this is not the category of data processing, but the search of database.
The second one was written by a C programmer in PHP. He took all the classified information out of the database, arranged and distributed it with data structure algorithm, and then output it.
Here we don't compare the efficiency of these two methods, I think everyone has their own ideas. But I want to explain a problem, that is, the essential difference between the two practices. PHPer is used for database processing, which is very clever and efficient. This way is database query. The second method is more characteristic. He believes that the database is the place to store data, and the specific logical processing depends on its own logic.
So the conclusion is that the user of the second method feels stronger because the logic of the data is organized by him. And I think PHPer's approach is nothing more than querying the database. So he thinks that PHPer is a grassroots, and only knows how to operate the database and arrange pages (that's what smarty does).
Return the database to its original job.
Having said that, I think everyone has recalled a lot of their own experiences in developing with PHP. Do you find that everyone is really operating the database?
Then let's discuss this problem. Is the database not good? Why do I always use the database to process data? What I want to say is that there is something wrong with the database, and there is a big problem. Of course, I'm not saying that the database can't be used, nor am I belittling the performance of the database. On the contrary, we don't fully realize the function of database.
My idea stems from the fact that once the technical director of a website asked me why their website was so slow and what to do. At that time, the engineer at Zend headquarters in MSN happened to be online, so I asked him what to do if PHP responded slowly. He told me directly that it was a database problem. The database must not be optimized. So, I didn't give the technical director a definite answer, because we can't involve their database design. So I gave some suggestions on database optimization. This kind of thing happened many times, and I began to wonder why engineers at Zend headquarters always told me it was a database problem. Can't we solve this problem from the PHP level? The answer is no, because PHP is running very fast at present, and a user's click can also be seen through Zend's performance analysis. The running time of PHP is less than 10%. What is PHP doing? It is waiting. Wait for the query result of the database. This aspect has been greatly improved in the current PHP products, that is, caching and static web pages.
Caching may be unfamiliar to everyone, but static pages are now very clear to users of PHP products. Fast speed, easy to be searched and so on, the benefits are self-evident. Joking, now the homepage of the website only needs a hard disk big enough to realize a static page. J As for caching, it is more complicated and a headache for most PHPer. Some people even use C to realize it. Because the validity period of data in the cache is difficult to verify, find, extract, update and so on. Of course, some people will use databases to deal with caching problems.
Therefore, when the number of visits increases sharply, many problems that will occur in PHP-based websites are caused by the database. The problem of database synchronization is nothing. The key is that the response speed of the database will decrease exponentially. I asked the vice president of MySQL this question at the LAMP conference of 10/0 on October 23rd. He didn't give me a perfect answer at that time (which I expected), because there will always be bottlenecks in the database, unless it is a fairy database, haha!
Here's a digression. When I was chatting with a technical executive of Yahoo at the LAMP conference, I asked him what Yahoo thought when choosing MySQL or Oracle. His answer surprised me very much He said that we will use MySQL most of the time because its performance has met our requirements. But when we will choose Oracle, that is, when we need to store the data of charging users. I asked why Oracle is more stable than MySQL. He said there was no special consideration for it. The key is that if we use Oracle, we can find the person in charge if there is a problem, and Oracle will be responsible for handling the accident, but if we use MySQL, who can we go to?
Therefore, our views on the database should be corrected, that is to say, the database is not omnipotent. Develop your own database if you have the strength. I heard that Google is like that.
So what do we think of the database? My personal understanding is that the database is only a means to reduce the development cost. Because after using the database, we don't need to consider the storage of data, especially sorting and searching. But what problems will this bring? When the business expands, the database becomes the bottleneck. At this time, the problem is very difficult. Because this is the underlying data processing. Pull one hair and move the whole body.
So I think the correct view is that the database is a data backup machine. How to understand it? We just need to ensure the validity of data storage. This is the core function of the database, but because of the convenient sorting and other functions of the database, everyone gives too much processing to the database to operate. When a user clicks on PHP, a lot of tasks are handed over to the database, and then the results are arranged for the user. This is unfair to the database. This is why people began to complain about the performance of the database.
In view of this point of view, let's give another example. I once visited a large Internet company (basically everyone who has been to the Internet in China knows). They rarely use PHP, but I learned how their other businesses use databases. They proudly told me that they had a second database outside the database (I named it the second database here). Why is it called the second database? This is a cache system. So how do development engineers get data from this cache system? The technical director proudly said that their cache system has SQL query statements. I was surprised at the time, but then I thought I really needed this. Because it is very complicated to get data from the cache when your cache system reaches a certain level, you only need to write an SQL query statement for the cache system to analyze, process and return the data. And they told me that in their place, even if PHP is used, it is to let PHP go to that cache system to read data.
So, if you can handle this problem well, store the data in the database, and then the database only plays the role of backup. Then you use your own middle tier to process the analysis data, and as a result, more than 90% users do not access the database. Some people will say, isn't this just a connection pool? Yes, because the bottleneck of the database can't be solved, we can only add an intermediate layer between the Web server and the database as a buffer.
Maybe people will say, well, we already know this. What I want to say is that it triggered two ideas:
First of all, some languages already have connection pooling technology, and those programmers can easily use connection pooling to build large-scale applications. So if they think that PHPer can only use databases, can we say that they can only use connection pools? What is the difference between connection pool and database in this concept?
Second, when PHPer started to build its own cache system, did it break through the level that PHPer only used databases? Because he participated in the processing of data logic. So is he still a grassroots?
Finally, PHPer who knows how to think independently is not a grassroots, and everything is handed over to the database.