Quote:
Originally Posted by PeterT
...Consider custom columns as another form of variable...
If it's just you don't like seeing them in custom metadata editing, maybe a polite request to Kovid to add a new attribute to a custom column; hide from display might suffice.
|
I must to think about. May be, you are right.
But anything to ask from Kovid, after I wrote my honest opinions...
EDIT, LATER
Oh, no!
I thought about, and remembered/understood-again: the elementery principle of managing database is - DB record's data is DATA, constant; temporary variables, as they are only a temporary modified SECONDARY values from REALLY, primary datas, trough calculations, using functions, are principially other things. Forbidden to mix them. It's an elementary erronous idea.
Inversely: now I must think, how to get rid of this annoying, already existing in my DB "custom columns". They are written to books' files! To opf, to epub. If I want to send a book to my daughter, for example, I want to send the author's text + the REALLY data: year, language, publisher, and so on. But NOT thousands of temporary values, affecting only my DB shower/manager application. Temp values, calculated with functions, forbidden to send forward. I am sure, for this like "solution", mixing really data with temporary values, in IT school anybody get the rating 1 from 5 stars.
It very well seems in PHP/MySQL works. Most of calculations absolutly has no effect in DB, only in HTML pages, written trough PHP. Some times, in case of more complicated searches (or other tasks) we alter DB, too, but only with temporary (for calculating a PHP>HTML page) tables, and the inner MySQL motor deletes them immediately after creating the page. (Of course, I speak about a showing/filtering/serching data manipulations, not about adding a new record, or modifying a record's paramaters.)
I must (honestly!) say thank you, Peter: I could remember this elementary principle, thanks to your tip.