Why fleaphp uses the table Data gateway to provide a database instead of an active record

Many developers wonder why fleaphp is targeted for efficient development, but does not provide Active record mode. This article attempts to elaborate on this issue.
What is an Active record?

Active record mode, called Activity records, is defined in the Enterprise Application Architecture model (POEAA) as follows:

Active Record: An object that wraps a row in a database table or view, encapsulates database access, and adds domain logic to the data.

For example, a book data sheet, each record is a book of information. When active record is used, each book is an instance of an active Record object.
Active record is popular for Ruby on Rails

Active record is now so hot, even many people equate Active record with ORM, and that's why Ruby on Rails is all about.

In Ruby on Rails, an Active record provides the process of associating relationships between data (rather than objects) in addition to the most basic mapping of data records to one object. For example:

A book has one or more authors, so each book object is associated with multiple author objects. Conversely an author can write more than one book, so an author object is also associated with multiple book objects.

In RoR, when we get a book object, we automatically obtain the corresponding author object of the book object (essentially the author data corresponding to the book data). Further, with the author object associated with the book object, we can get an object instance of all the books written by the author. And these work, in the RoR only need a few lines of code, before we need to write a large piece of code to achieve the same effect.

In RoR, the implementation of Active record mode fully leverages the flexibility of the Ruby language, and a few lines of code can define an association. and through complex activerecord:base objects, the default handling of CRUD (create, read, update, delete) operations is provided. So when using RoR, most common database operations require only a small amount of code to complete, greatly improving the development efficiency.

However, active record mode is not perfect, and active record has many drawbacks.

* Active record mode requires the data table structure and object attribute one by one correspondence (at least most of the corresponding), otherwise it will be difficult to use active mode;
* Active record mode does not really fit in to fully object-oriented applications. Because the Active record mode essentially requires an object to correspond to a data table. But in a fully object-oriented application, the methods of data and manipulating data are likely to be distributed across different objects, but they do not correspond to a single data table, and Active record does not handle object-oriented objects such as inheritance and aggregation.
* With the gradual addition of business logic to an active record, an increasing number of SQL statements are mixed into an active Record object, which is clearly a disadvantage in more complex projects.

If you add processing to the data relationship (note, not object relationship) in Active record mode, pay attention to performance issues as well:
If an Active Record object has multiple associations. Then when I take out an object, it is possible to take out many other objects. But these objects may not be available at all in this operation. Second, when you update an object to a database, you also need to process the associated object, otherwise the modification to the associated object is lost.

Although you can use various techniques to avoid these situations, there is no doubt that developers need to be familiar with RoR's Active record. Otherwise, seemingly simple code, behind it is a nightmare of database operations.

Second, if we want to halve the unit price per book in the database, then in Active record mode, we must first read all the records and instantiate them as objects, then update the object properties and write back to the database. It is conceivable that this will have much worse efficiency.
Of course, no one would do that in actual development. The developer will write a separate method to complete the update of the batch data with an SQL statement. But it also shows that Active record mode is not suitable for batch data processing, while in the real world, the demand of batch processing data is everywhere.

But because of RoR's dramatic improvement in development efficiency, RoR is a good choice for projects that pursue development efficiency. and performance deficiencies can be improved by updating the hardware or with other technical means (for example, FastCGI is usually the first choice to run RoR applications). So in the real world, all of 37signals.com's RoR-based applications have achieved good performance (but the same hardware, the same functional applications that run PHP development, are better or worse?) There is no answer to this question.
Active Record and ORM

Many people equate an Active record with ORM, which is wrong.