Re: Question on Structuring Product Attributes

On Oct 17, 4:16 am, -CELKO- <jcelko..._at_earthlink.net> wrote:
> Again, the CHECK() constraint in Standard SQL does allow ANY valid
> search conditon. No product I know has implemented it and the only
> product with a CREATE ASSERTION statement was RDB, a product form DEC
> that was bought by OrACLE.
>
> You asked for a Standard SQL and that was one solution.
>
> Actually, the regular expression should have been the SIMILAR TO
> predicate. Again, this is ANSI/ISO Standard and based on POSIX from
> the Federal Standards. Have you ever downloaded a copy of the
> Standards?
>
> The VIN is a special case because we can validate that the vehicle is
> an SUV from the VIN. Other identifiers might not have this property.
> If you want to see the power of regualr expressions, look up the
> pattern

Sounds and looks like the volumes of text you are famous for posting. Smells like bulldust. All red herrings and distractions, in order to avoid dealing directly with any of the issues I have raised.

> >> When existence checking, one should *never* use "SELECT *", as that
>
> drags the whole row into cache, and returns it to the thread, no
> matter what columns are used to qualify the query<<
>
> LOL! Why does anyone still beleive that myth? There was an early
> version of Oracle that did that. It was correct the next release. The
> options were "SELECT * ", "SELECT <constant>", "SELECT <column>", and
> "SELECT <expression>" and they are all treated as *. Here we get into
> that "effectively" thing in Standard-speak. Since only the table
> cardinaltiy matters,

Tables have "cardinality", do they ? Is that in your new book *Mangled Relations for Dummies*

> the optimizer throws out the SELECT list in every
> SQL product I have used or consulted on.

Well you should start checking the showplans or query plans and testing the code before you provide consulting. Until you post one of those, proving your assertion, it remains bulldust, and just another distraction.

> The SELECT * is not required, but it is the preferred style

Now it is "preferred", is it.

> because
> <column name> or <expression> can change, so the subquery will be
> invalid, <constant> tells you nothing about the nature of the query
> while SELECT * tells you that this is a table level construct, not
> dependent on the rows and columns.

You know, every time you post, you prove you have no idea about what you are posting. Every post destroys more of the little credibility you have left.

1. A query is a query. There is no such thing as a "table level construct" for what you have identified or for the SELECT you have given.
2. Some of the SQLs are smart enough to *ignore* the column list and others are not.
3. Read the freaking manual for your particular platform. Most of them will categorically state: ____In an EXISTS, always use (SELECT 1 FROM ... WHERE ...)
4. Stop trying to bamboozle the readers with bulldust.
5. You cannot even tell the difference between column issues and qualifiers in the WHERE clause. What you are stating simply does not apply.

> To stress this consider that
> EXISTS (SELECT * FROM .. WHERE..)
> is equivalent to
> (SELECT COUNT(*) FROM .. WHERE..) > 0
6. The better (not all) SQLs differentiate an EXISTS from a normal SELECT. For EXISTS, the better SQLs stop processing the suquery when the first row that satisfies the WHERE clause is found.

7. In every SQL, SELECT COUNT(*) has to scan the *entire table*

8. The is no "equivalence" between the two statements given.

You need to take some formal education in SQL before you post further nonsense. Let alone "consult".

> And that is how SQL products actually inplement it under the covers.
> The mechanism for counting rows can use the indexes and stop when it
> gets the first row back.

9. By definition, by standard requirement (God, you're either an idiot with a capital I or a shameless liar), SELECT COUNT(*) has to count all rows. There may be faster methods of obtaining a row_count, but we are discussing the SQL you have posted.

1. The SELECT COUNT(*) is in brackets. That has to be resolved before the comparison outside the brackets is resolved. You need to read books written by others on the subject, not only the fairy tales that you write about SQL.
2. Since you have demonstrated the exact level of you knowledge of SQL, by your own posts, and that has been pointed out to you, you are no longer in a position to *tell* anyone anything about how something works. You are a fraud.

--

Stop hiding behind this "under the covers" nonsense.  It is
transparent.  Unlike you, I (a) test my SQL and (b) obtain showplans
and resource consumption stats at a variety of levels, *before I
post*.  Everything "under the covers" is laid bare.

And stop taking he position of knowing how SQL is parsed, compiled and
executed. You have proved you can't even write SQL, there is no way
that you can possibly write a compiler or speculate about what one
would do.

Finally, I note you have not addressed either the substance of my
refutation of your proposal, or my alternative method.  Just an awful
lot of black powder smoke.  And both your feet are bleeding.

--------------------------------------
I take it that my posted method stands
--------------------------------------



> My wife is an ordained Soto Zen Priest and she teaches by


> beating students with a stick.


I can understand her taking out her frustration with you, on the
kids.  But that is not acceptable, it does not resolve the problem,
the circle continues ad infinitum.  She needs to beat the source of
the frustration with a big stick, not pass it down to the kids.

Regards
Derek