 | |
Question on Structuring Product Attributes
comp.databases.theory comp.databases.theory
 |
| | Thread Tools | Display Modes |
#41
 
| |||
| |||
|
Re: Question on Structuring Product Attributes -
10-22-2011
, 04:21 AM
|
I'm not Derek. |
was (and apparently still am) waiting for a reply from Derek, so when
I saw a reply I immediately jumped to the wrong conclusion. My
apologies.
It's interesting to see that Derek has not yet responded to my
question, even though he did already post a message elsewhere in this
thread a few hours after I posted...
--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
#42
| |||||||||||
| |||||||||||
|
|
On Oct 17, 10:05?pm, Eric <e... (AT) deptj (DOT) eu> wrote: It's sort-of fun to watch two people who don't know enough trying to have an argument. It is even more fun to watch someone on the sidelines, who is not party to the argument, picking up clauses and examining them in isolation. |
want to comment on, why should I not pick it out? There is no isolation,
everybody has read, or can read, the rest of the thread.
Quote:
|
What on earth is "and have them in a visible column, non-pointer, form" supposed to mean? Let me spell it out for you: - I was not posting a new thread (I would have used proper terms). - As I detailed to Jonathan, I was not writing a fully qualified thesis (if you are expecting that, you will find it lacking) - I was posting a response to Celko's thread. That defines the context. - Celko was playing "slippery fish", to avoid dealing with specific problems that I identified (check the whole thread) - In an attempt to prevent the slipperiness, I used Celko's terms. - As it progressed, I used further terms make distinctions, using his used terms as the base (I would not have used his terms, or my-terms- that-are-based-on-his-terms in a stand-alone article) |
what I wanted to know was what you meant by it and what is the
alternative (since why mention it if there isn't one?).
Quote:
|
All you can ever see of an index (apart from its effect on query performance) is the list of columns indexed and some vendor-dependent stuff usually about physical storage. Excellent, you seem to understand that correctly. So your question is either rhetorical or plain absurd. |
Quote:
|
If you have an honest argument with me, just state it; if there is something you wish to clarify about one of my statements, ask a question. |
whatsoever.
Quote:
|
But this picking and gnawing on the carcasses left, after others have feasted, is for the birds. |
Quote:
|
Just to pick on one more thing: - each PRIMARY KEY constraint builds an index - each UNIQUE constraint builds an index Not "builds", but "usually needs" : Correcting my English is petty. If you fancy yourself an editor, send me your CV, I will send you all my posts to edit, before I post. |
Declaring a Primary Key does not necessarily cause an index to be built,
though in most, if not all, current SQL-based systems, it requires that
one exist. However there is no theoretical reason why this should be so,
it is merely a readily available method that has been widely adopted.
And yes, I have deliberately mentioned a theoretical possibility as part
of my argument, you have no right to tell me that I can't.
Quote:
|
- nowhere is there a requirement that primary and unique keys be ? implemented with an index Try reading the entire statement in context. You might draw a different conclusion. |
Quote:
|
If that is still confusing, try this: I did not say "there is a requirement..." so there is no point arguing against what I did not say. I am quite happy to address issues regarding what I have said (the thread is ready evidence). But I do not engage with isolated scraps. It might give the readers the idea that such isolated scraps have some credibility, or that bird-like behaviour is appropriate for functioning adults. |
I never claimed that you said so, it was merely a part of my argument.
If you want to insist that a discussion should be only on your terms
then you are obviously not sure you can win without this. And, of
course, you can't make rules of discussion here.
Quote:
|
- only one index is needed and there is nothing to prevent an SQL parser being smart enough to realise this Marvellous. Identify which SQL does that (post evidence). |
possible. Again, you can't make rules of discussion here.
Quote:
|
Until then your suggestion is possibility in the future, not a reality, which is what Celko posted (he did not say "sometime in the future, some SQL could ...", he posted "Here is how to do this [now] ..."), which I am arguing. I can simply state, no SQL does that [now]. The implication is "now", on Earth, not "ten years from now", not "if and when the vendors wake up and read Celko's post", not on the fourth moon of Jupiter. - if the parser is not smart enough there may well be a way of ? second-guessing it and still ending up with only one index. Feel free to post the method. |
index, then create the keys. No new indexes will be built.
I know this works in Oracle, because I do it frequently, and I am pretty
sure it works in other products.
Quote:
|
Otherwise your suggestion is a yet another fantasy of could-bes and guesses. Just like Celko. Any examination reveals that his method is based on facilities that are not available now, as stated "do this", that the method might be useful at some point in the future, if and when some SQL vendor supplies the the underlying facility. My method is based on the here and now, in any SQL (I have specifically excluded the non-SQLs), on Earth. And finally... ... under the covers is not relevant ... True, but you don't always seem to understand where the covers are. Thanks for your opinion. I will make sure I give it the consideration it deserves, keeping in mind your demonstrated level of capability, in understanding technical matters, and your could-be, should-be, attitude to addressing present day reality. Should you wish to address any of the salient points in my post, a piece of meat, rather than a scrap, I might give your avian opinion more consideration. |
insult. No doubt you will think you have "won". Enjoy your "victory".
Eric
--
ms fnd in a lbry
#43
| |||
| |||
|
|
On 2011-10-19, Derek Asirvadem <derek.asirvadem (AT) gmail (DOT) com> wrote: On Oct 17, 10:05?pm, Eric <e... (AT) deptj (DOT) eu> wrote: It's sort-of fun to watch two people who don't know enough trying to have an argument. It is even more fun to watch someone on the sidelines, who is not party to the argument, picking up clauses and examining them in isolation. A private argument, on Usenet? Whatever next? And if a clause is all I want to comment on, why should I not pick it out? There is no isolation, everybody has read, or can read, the rest of the thread. What on earth is "and have them in a visible column, non-pointer, form" supposed to mean? Let me spell it out for you: - I was not posting a new thread (I would have used proper terms). - As I detailed to Jonathan, I was not writing a fully qualified thesis (if you are expecting that, you will find it lacking) - I was posting a response to Celko's thread. That defines the context. - Celko was playing "slippery fish", to avoid dealing with specific problems that I identified (check the whole thread) - In an attempt to prevent the slipperiness, I used Celko's terms. - As it progressed, I used further terms make distinctions, using his used terms as the base (I would not have used his terms, or my-terms- that-are-based-on-his-terms in a stand-alone article) All you have spelled out is the context in which you wrote that, whereas what I wanted to know was what you meant by it and what is the alternative (since why mention it if there isn't one?). All you can ever see of an index (apart from its effect on query performance) is the list of columns indexed and some vendor-dependent stuff usually about physical storage. Excellent, you seem to understand that correctly. So your question is either rhetorical or plain absurd. No, see above. If you have an honest argument with me, just state it; if there is something you wish to clarify about one of my statements, ask a question. Which is exactly what I did, but you provided no clarification whatsoever. But this picking and gnawing on the carcasses left, after others have feasted, is for the birds. Now that's just rude. Just to pick on one more thing: - each PRIMARY KEY constraint builds an index - each UNIQUE constraint builds an index Not "builds", but "usually needs" : Correcting my English is petty. If you fancy yourself an editor, send me your CV, I will send you all my posts to edit, before I post. I am _not_ correcting your English, I am questioning your meaning. Declaring a Primary Key does not necessarily cause an index to be built, though in most, if not all, current SQL-based systems, it requires that one exist. However there is no theoretical reason why this should be so, it is merely a readily available method that has been widely adopted. And yes, I have deliberately mentioned a theoretical possibility as part of my argument, you have no right to tell me that I can't. - nowhere is there a requirement that primary and unique keys be ? implemented with an index Try reading the entire statement in context. You might draw a different conclusion. Obviously not! If that is still confusing, try this: I did not say "there is a requirement..." so there is no point arguing against what I did not say. I am quite happy to address issues regarding what I have said (the thread is ready evidence). But I do not engage with isolated scraps. It might give the readers the idea that such isolated scraps have some credibility, or that bird-like behaviour is appropriate for functioning adults. More rudeness. I never claimed that you said so, it was merely a part of my argument. If you want to insist that a discussion should be only on your terms then you are obviously not sure you can win without this. And, of course, you can't make rules of discussion here. - only one index is needed and there is nothing to prevent an SQL parser being smart enough to realise this Marvellous. Identify which SQL does that (post evidence). I don't know for certain that one exists. So what? I know that it is possible. Again, you can't make rules of discussion here. Until then your suggestion is possibility in the future, not a reality, which is what Celko posted (he did not say "sometime in the future, some SQL could ...", he posted "Here is how to do this [now] ..."), which I am arguing. I can simply state, no SQL does that [now]. The implication is "now", on Earth, not "ten years from now", not "if and when the vendors wake up and read Celko's post", not on the fourth moon of Jupiter. - if the parser is not smart enough there may well be a way of ? second-guessing it and still ending up with only one index. Feel free to post the method. Create the table without declaring the keys, then create the appropriate index, then create the keys. No new indexes will be built. I know this works in Oracle, because I do it frequently, and I am pretty sure it works in other products. Otherwise your suggestion is a yet another fantasy of could-bes and guesses. Just like Celko. Any examination reveals that his method is based on facilities that are not available now, as stated "do this", that the method might be useful at some point in the future, if and when some SQL vendor supplies the the underlying facility. My method is based on the here and now, in any SQL (I have specifically excluded the non-SQLs), on Earth. And finally... ... under the covers is not relevant ... True, but you don't always seem to understand where the covers are. Thanks for your opinion. I will make sure I give it the consideration it deserves, keeping in mind your demonstrated level of capability, in understanding technical matters, and your could-be, should-be, attitude to addressing present day reality. Should you wish to address any of the salient points in my post, a piece of meat, rather than a scrap, I might give your avian opinion more consideration. You have failed to understand what I was saying. You have descended to insult. No doubt you will think you have "won". Enjoy your "victory". Eric |
#44
| |||
| |||
|
|
would never put application developers in a position to work with anything but base tables (INSTEAD-OF triggers??? blech!) |
the guys who need VIEWs, not application users. If you let developers
use VIEWs, then they all do complicated things the same way. If they
all write their own code, you get slightly diffrence versions. My
personal favorite was the equivalent of " age > 18" versus "age >= 18"
in all the permutatisn of a a five table join.
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.