|
Anand Desai wrote: I just could not stop laughing after listing of his answer of my question.. "why the hell you want to write two more conditions while u will get unique booking after checking with primary key itself????"
Check his answer.. "For extra perfection sir!!!!"
Neither of you have heard of optimistic concurrency, dont worry, you will get there
|
|
|
|
|
I used to see quite a lot of that in ABAP/4 report programs.
|
|
|
|
|
While it didn't involve a primary key, I learned something similar about databases many years ago (mid-90s).
Using Oracle 6, I had a query that I wanted to speed up.
I went to one of the DBAs and asked for help.
The where clause involved two fields (I'll call then X and Y).
The DBA said that there was no index for X and Y, but there was an index for X, Y, and Z.
If I added Z to the where clause the query would use the index and therefore be faster.
So I added a test for Z that would always be true, like "AND Z NOT NULL" when I know Z is never null.
And by golly it worked!
|
|
|
|
|
Certainly not relevant to SQL Server - SQL Server can always use the leftmost columns of an index, if that's all that's required.
It does depend on the ordering of columns in the CREATE INDEX or PRIMARY KEY declaration, though; if the ordering is X, Y, Z it can generate a seek on X and Y when you're looking for X and Y, but if it's X, Z, Y it can only generate a seek on X, because the identical Y values are not clumped together (they're separated by different values of Z). Adding AND Z NOT NULL doesn't help much here because Z likely isn't selective, unless the Zs in the table are mostly NULL.
I'm pretty sure modern Oracle can use prefixes as well.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
The priest told you to 'honor the god of index'. ... Thats why the called their product "Oracle"
Asking a specialist is always one of the best ideas.
Greetings from Germany
|
|
|
|
|
It's my personal opinion that posting the mistakes of ones juniors is mean spirited - if you're a supervisor, your job is to teach and encourage, not to ridicule.
Christian Graus
Please read this if you don't understand the answer I've given you
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Right, so one should always write it up as if the culprit is "the senior design guru".
|
|
|
|
|
|
I would tend to agree with this
|
|
|
|
|
Oh, it doesn't matter. With such efforts toward 'extra perfection', a brilliant career in management is waiting for the guy.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
That was the intention of his remarks.
Greetings from Germany
|
|
|
|
|
Well said - my rule for juniors is always to praise in public and critique in private (note - critique and not criticize).
|
|
|
|
|
Pete O'Hanlon wrote: my rule for juniors is always to praise in public and critique in private (note - critique and not criticize).
Sounds to me like your a down to earth guy.
There is nothing worse than some prick who constantly humiliates their employee's in public (no matter what field their working in).
|
|
|
|
|
MarkBrock wrote:
There is nothing worse than some prick who constantly humiliates their employee's in public (no matter what field their working in).
It's only good business sense. I'd rather I had a happy member of staff who's had a chance to improve than somebody who I've p!ssed off and who's just going to be resentful. I don't want to be a Pointy Haired Boss.
|
|
|
|
|
But this costs execution time. And not to ferget what consequneces statement "may be". First selecting "nCategoryID" and create a nice temporary table and than run "nProductID" and now last but not least select the ID.
I would compare the complete againt the short mode and look. In greater databases strang things can happens...
Greetings from Germany
|
|
|
|
|
I keep note of this next time your junior developer is up for a performance review
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
"Lasciate ogni speranza o voi ch'entrate"
Dante Alighieri
<br />
private double m_EdgeDim;<br />
<br />
public double EdgeDim<br />
{<br />
set { m_EdgeDim = value; }<br />
}<br />
Don't you really want to see what you have put?
****************************
Strong congruence
for strong people;
with a compatible behaviour.
For a semantical way of life.
|
|
|
|
|
I don't get your point: a write-only property appears perfectly reasonable to me.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Marcello Faga wrote: Don't you really want to see what you have put?
No, and you shouldn't. It is called Encapsulation.
|
|
|
|
|
Good, i thought it was bad coding
****************************
Strong congruence
for strong people;
with a compatible behaviour.
For a semantical way of life.
|
|
|
|
|
Personally I would prefer a SetXXX(value) function instead of a write only property.
|
|
|
|
|
|
|
I understand the point of a write-only property, but I don't like the idea of really using it.
It's only going to confuse you or anyone else working with the code.
After all, the only one who really isn't supposed to know the value of the property is the user, so as long as it's not displayed to the user, it should be fine.
Using a write-only property will only make debugging and refactoring harder.
In my opinion, this is a bad practice.
|
|
|
|
|
I am writing the code for my first (proper) CP article and I did have one write only property.
I have a webcam class that I want to control to a T (via a VisionController class). On the webcam wizard the user selects the device and the wizard puts it in the class. I don't want ANY other portion of code interacting with it: so once the class is in I can get to it.
It forces me to create proper interfaces, and now that I have completed them I put the get {} in there .
|
|
|
|