Archives of the TeradataForum

Message Posted: Tue, 06 Dec 2005 @ 15:46:15 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

<-- Anonymously Posted: Tuesday, December 06, 2005 10:43 -->

Thank you all for the feedback.

The responses show two camps on this issue:

Those who believe the way EXPLAIN works today is fine.

Those who believe the way it works today is not fine and that it imposes an additional burden on the staff, which is now forced to develop procedural workarounds to deliver the service.

DB2 allows a developer to create an EXPLAIN statement on a production database using a developer ID. That must mean the world leader in RDBM systems must have it all wrong and NCR must have it all right, or is it the other way?

I am not sure how being able to know the names of tables or columns represents a threat to the security of the system, but that's another issue. If someone wants to get in real bad they can figure out a way through hacking or by employing criminal means of force. If a shop decided to hardcode constants and values into views and that's a possible leak of secured data, then they deserve to get hacked for doing something that naive.

I know this thread will not change anything but at least we discovered that not everyone thinks the way EXPLAIN works today is All O.K.

In closing, I do have a suggestion for NCR: Since they love DBS Controls to manage the behavior of the engine so much, why not make EXPLAINs available to all users via a DBS flag. That way those who believe EXPLAINS should remain under rights can have it that way, and those of us that want to empower developers can do it too. NCR found it easy to implement EXCEPTIONS in the Alert Policies and TDQM, why not in the EXPLAIN engine? That way each shop can set up the environment as they please. How hard can it be to code that into the existing engine provided it is not spaghetti code?

Anonym

	<Prev	Next>		<<First	<Prev	Next>	Last>>