Data Dictionary or ORM?

I am working on a framework replacement for a fairly complex business application. Our application runs on the LAMP platform and the new framework will be an extension of CodeIgniter. ... In my research for framework design, I decided to look into ORM, I had never done an ORM before, and I wanted to know if it would be useful for our application. Then I came across a very interesting blog post titled "Why I Don't Use ORM". This blog seems to have confirmed many of my concerns about using ORMs, and it also provided a solution similar to what I was already planning.

In the "data dictionary" I plan to use this definition from "Database Programmer" :

The term "data dictionary" is used by many, myself included, to refer to a separate set of tables that describe application tables. The data dictionary contains information such as column names, types and sizes, but also descriptive information such as titles, titles, primary keys, foreign keys, and user interface hints on how to display a field.

This way, when choosing a "data dictionary" over the ORM, I can show the bias confirmation, whether or not my reasons for the ORM fatigue are:

• I've never used an ORM before, I don't know much about it.
• This framework needs to be built pretty quickly, my boss is short on time and I need to create a working application that will allow a smooth upgrade to a more modern framework.
• My boss already thinks that I am developing this framework (trust me, I am not that close to it) and is paranoid about the structure that prevents us from doing what we need to and making mistakes that we cannot solve in the required time ... So far, I've done poorly at convincing him that the changes are good, I'm not a very effective salesperson, and while other developers can help me, the boss still needs a lot of confidence.
• Our old structure is procedural, our code is PHP, and our developers are well versed in SQL. ORM is going to be a big change.
• We have dozens of tables in our database, many of which contain hundreds of thousands of records on a fairly old server. Earlier, we were burned by code that repeats database polls in a loop instead of making one request to pull all the data we need at once. Fixing this issue with hand-coding SQL is pretty straight forward. Ensuring that this always happens where it is needed with an ORM is a huge unknown to me and seems risky.

Regardless of what the data dictionary solution seems to me to be very promising as this blog post "Using the Data Dictionary" seems to provide many useful features and some of them that are requirements of the new structure. Here are my reasons for preferring the data dictionary solution:

• Implementing access control rules on the table rows themselves would be invaluable.
• It is also helpful to automatically generate database changes, documentation, and schema validation.
• One of the structural requirements is a general data history / audit function that can be applied to any subfunction in our application. A data dictionary or equivalent is required to provide this functionality. The history should contain detailed information about the structure and types of data in the database.
• There are a large number of data types in our systems that would be more properly eliminated if they are treated as formal types in an application. First, the HTML snippets (of which we have a lot in our data, they are required) have to be encoded as entities in some cases, decoded as HTML in others, parsed for links and images in some cases, and always checked for correctness. Then there are dates, dimensions, currency, and various other fields that can benefit from having a clear definition in the code of how that data should be processed.

The data dictionary idea I would like to implement would be a series of objects in separate PHP files, and there will be a lot of OOP, however it will be used in the same way as the data dictionary concept introduced in "The Database Programmer". This will define a single source of the complete database schema for the entire structure.

Now my question is, am I missing the meaning of the ORM or is this a case where the data dictionary is the right tool to do the job?