Re: SQL programming fundamentals

Yes, I do now see the flaw in my metaphor. In my defense, I prefaced the thought with the "kneejerk" disclaimer, he says sheepishly. :)

OTOH, I think I'm liking my accidental omission of "database" in "designing software". I love the idea of acclimating even non-SQL/non-DB programmers to think in terms of relations.

A few years ago, I attended a brief seminar where Steven Feuerstein advocated "playing" the daily Set game at http://setgame.com I encourage my devs (and the rest of the IT department) to also visit daily with the idea that identifying those Set relations can translate to identifying relations in our business data and programs. It's a great simple brain game where more complex ones like Suduko (I still can't identify swordfish and other complex patterns w/o help) tend to turn them off.

But it's not tuple relational theory...

Rich

>>Rich wrote:
>>"relational theory knowledge is akin to needing to understand the internal
> combustion engine in order to drive"
>
> I disagree.
>
> This is like stating that the endusers of database applications need to know
> relational theory.
> They do *not*, of course.
>
> I see, you correct yourself later on:
>>"I think I *am* in favor of that requirement if the SQL professional is
> designing (* database) software"
> (*) insert by me.

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