RE: Case insensitive searches

The points I am trying to make regarding covering the behavior gapT that positional inserts do not work with tables containing virtual columns are:  

1. It can be done with at most one extra view per table containing virtual columns
2. It is feasible to clearly identify the view created for this purpose by consistent nomenclature
3. I still think the current behavior is a bug, but I don't want to engage in that debate so I coined the term behavior gapT

definition: behavior gapT - The difference between how something works and how it seems it should work without regard to whether the actual behavior has the word "bug" factored out by documentation that the current behavior this is the expected behavior or that it is only a documentation bug, so the behavior itself is not a bug.  

I think the different possibilities of the outcome of a plethora of views probably maps one-to-one with whether a given team could succeed with the Agile method.  

As a matter of cash flow, I encourage the rampant use of views to a depth the CBO cannot untangle. (Credit concept to Moans L. Nogood.)  

Also smile winking.  

mwf  

-----Original Message-----
From: Hans Forbrich [mailto:fuzzy.graybeard_at_gmail.com] Sent: Sunday, March 23, 2014 12:33 AM
To: Mark W. Farnham
Cc: ric.van.dyke_at_hotsos.com; oracle-l_at_freelists.org Subject: Re: Case insensitive searches  

On 22/03/2014 7:01 PM, Mark W. Farnham wrote:

> Hans used the standard v_ indicating

> view.

Personally, I think we have it backwards. The View should be the thing exposed to the developers and the application. That allows us to do what we need (column order, generated columns, etc.) at the DBA level, and the developer can do what they need with the business views.  

I see no problem with organizations becoming View Happy, as long as they are also willing to do the performance evaluation to use them correctly. ;-)  

/Hans

--
http://www.freelists.org/webpage/oracle-l