Feature Request | Allow custom metadata per table/column to be stored

Question

Someone please correct me if there's already a feature that allows this...
I'd like to see a feature where you can define a set of metadata that can be stored per table / column, and perhaps a trigger that updates that metadata.
As a use case, it is sometimes necessary to find out how many records exist in a table, and the typical way of doing this is by running a statement like select count(*) from example_table;. With a large table, this statement might take a long time though, and certainly has overhead associated with it. If this is something that's done on a regular basis, like maybe even once every minute, wouldn't it be much better to store this number as metadata for the table that can be updated on inserts and deletes and then can be queried? It might involve extra overhead on an insert or delete statement to add to or subtract from this number, but then for some applications the benefit of getting the count quickly might outweigh the extra overhead.
Another use case is finding a minimum or maximum out of a table. Say you store a date and you need to find the max value for some feature in your application; with a large table, and especially if its a date with accuracy to the millisecond where an index wouldn't help much because most values are unique, it can take quite a bit of time and overhead to find that max value. If you could define for that column that you'd like to store the max value in metadata, and could query it, it would be very quick to get the info. The added overhead in this scenario would be on insert, update or especially on delete, the value would have to be updated. But in some applications, if you don't expect alot of deletes or updates on this column, it might be worth the added overhead to be able to quickly find the max value for this column.
I know you could probably make a separate table to store such info, and write triggers to keep it up to date, but why not have a built in feature in Oracle that manages it all for you? When you create a table, you could define with the column definition something like 'METADATA MAX' and it will store the max value of that column in metadata for you, etc.
I know that the overhead of this feature wouldn't be good for most circumstances, but there certainly are those cases where it would be hugely beneficial and the overhead wouldn't matter so much.
Any thoughts?
Can this be submitted as a feature request? Am I asking in the right place?
(p.s. while you're at it, make a feature to mimic IDENTITY columns from SQL Server!)

Answer 1

I don't think what you mentioned is exactly what I was talking about. There's no min_value or max_value in the dba_tab_columns table; there's only high_value and low_value, and they are stored in binary. And I believe to be accurate in the use cases that I suggested, you would have to analyze the table after every insert/update/delete. So no, that's not the same feature I've asked for, although I appreciate the feedback.
Also, the num_rows in dba_tables relies on the table being analyzed too, so for a table that stores temporary date to be processed where you want to know the size of the queue every few seconds, it wouldn't make sense to analyze the whole table every few seconds when all you want is a count of the records, and it's also inefficient to use the COUNT function with every query when it would be much faster to store the count in some metadata form that is updated with every insert or delete (adding to a count and subtracting from a count with each insert/delete is WAY faster than analyzing the table and letting it literally recount the entire table every time).
So again, while I appreciate the feedback, I don't think what you mentioned addresses either of the use cases I gave. I'm talking about a different kind of user defined metadata that could be stored per table/column with rules to govern how it is updated. Not you standard metadata that requires an analyze and isn't real time. I also only gave a few use cases, but the feature I'm really looking for is the ability for users to define many different types of custom metadata even maybe based on their own logic.
Again, this feature could be implemented right now by creating a USERMETADATA table for every standard table you have, and then using triggers to populate the info you want at the table level and column level, but why do that when it could be built in?
Also, I don't really agree that having to create a trigger/sequence for every table instead of setting a column as IDENTITY is better. It's cumbersome. Why not build these commonly used features in? It can create a trigger/sequence behind the scenes for all I care, but why not at least let someone mark a column as IDENTITY (or use whatever other term you want) at the time of table creation and let it do everything for them. But that's off-topic; I meant it for more of a side comment, but should really have a separate post about it.