• (unregistered)

    You know about Inversion of Control?
    This developer obviously did!

  • (unregistered) in reply to Drak
    Drak:

    By the way: Properties ARE quite slow sometimes in .Net, so if pure performance is what you need I suggest not using them. But for readability and for ease of use of libraries by other people they are what you want.

    How about we use properties *until* performance is actually measured, found to be unacceptable, and then those properties determined to be an actual factor in the unacceptable performance?

    I'm constantly amazed by how much emphasis people put on performance, usually, it seems, before the solution has actually been finished or they've done any testing. But they always have an anecdote or story that 'supports' them!

    Me, I want code that's foremost maintainable and does the job it's designed to do, and not written in a certain way "for performance reasons" (like "I'm not using properties, I heard they were slow" - that's not meant as a criticism btw, just an example of the sort of thing I hear). Optimise when performance is an issue, not when you think it might be.

    Of course, this assumes the thing in question was sensibly designed in the first place. :)

  • (unregistered) in reply to

    <font face="Verdana" size="2"><font color="#000080">>>> As I already said, semantics. If you took what I posted to mean that there's somehow a flaw in the nature of identity columns that causes breaks in sequential numbering, then you must view the world in an extremely literal manner.</font> <<<

    WTF???

    How else was he supposed to read it? It's what you said. There was no ambiguity, or possibility of misinterpretation. I don't know anything about SQL Server, but I know that non-sequential identity columns are possible, so it was perfectly conceivable you meant exactly what you said.

    -O
    </font>

  • (cs) in reply to Manni
    Manni:

    Seriously, why the hell does every WTF turn into a techie-supernerd war to prove who knows the most about assembly and processor optimizations? I concede that everyone reading this site is FAR smarter than me, there's no need to try prove it EVERY DAY. Can we get back to making fun of the hapless idiots that leave behind gems like this that will someday send a starry-eyed newbie into intense therapy?



    You are the wind beneath my wings. [:D]
  • (unregistered) in reply to
    :
    [image] Drak wrote:

    By the way: Properties ARE quite slow sometimes in .Net, so if pure performance is what you need I suggest not using them. But for readability and for ease of use of libraries by other people they are what you want.

    How about we use properties *until* performance is actually measured, found to be unacceptable, and then those properties determined to be an actual factor in the unacceptable performance?

    I'm constantly amazed by how much emphasis people put on performance, usually, it seems, before the solution has actually been finished or they've done any testing. But they always have an anecdote or story that 'supports' them!

    Me, I want code that's foremost maintainable and does the job it's designed to do, and not written in a certain way "for performance reasons" (like "I'm not using properties, I heard they were slow" - that's not meant as a criticism btw, just an example of the sort of thing I hear). Optimise when performance is an issue, not when you think it might be.

    Of course, this assumes the thing in question was sensibly designed in the first place. :)

  • (unregistered) in reply to

    (Cough)
    London Ambulance Service
    (Cough)

  • (unregistered) in reply to
    :
    [image] Drak wrote:
    [image] memorex wrote:

    <P><FONT color=#0000ff>&gt;IF</FONT> ((<SPAN style="COLOR: #00f">SELECT</SPAN> <SPAN style="COLOR: #f0f">COUNT</SPAN>(*) <SPAN style="COLOR: #00f">FROM</SPAN> Staff_DepartmentLink) &gt; 0)</P>
    <P>
    </P>
    <P>How can this be done in a faster way?</P>

    IF EXISTS(SELECT something, anything FROM Staff_DepartmentLink) BEGIN

    Wouldn't SELECT TOP 1 1 FROM Staff_DepartmentLink be more efficient than SELECT Count(*) and SELECT *

  • (cs) in reply to Manni
    Manni:

    Seriously, why the hell does every WTF turn into a techie-supernerd war to prove who knows the most about assembly and processor optimizations?

    I love the fact that those most involved in this flame war don't sign in as anything other than "Anonymous'.  Either grow a pair or shaddap.

  • (unregistered)

    If you use "SELECT TOP [N]", you must then have a way to figure out that there was something returned. This implies additional code, such as a "SELECT COUNT"(*) from a derived table (reverting right back to the original issue), or worse yet, using a temporary table to house the results of "SELECT TOP [N]", then doing the "SELECT COUNT(*)" on the temporary table. Lastly, you could return a useless recordset with your "SELECT TOP [N]" and check @@ROWCOUNT. This would qualify you for a "diamond award" for WTF's.

    If you're checking existence to create the condition for an [IF/ELSE] block, there is _nothing_ more efficient than EXISTS(). EXISTS() will stop on the first row that satisifies the condition. Incidentally, depending upon your WHERE clause, using an explicit column name may actually harm the performance, as you may cause the optimizer to choose a poor plan because whatever index is most suitable for handling your WHERE criteria may not contain the referenced column. For some reason unknown, the data engine will actually add I/O to the query to fetch the referenced column. In this case, using "*" actually results in better performance, because only the index will need to be examined to satisfy the request, and the data page would not need to be touched.

    Regards,

    Mr. Angry DBA

  • (unregistered) in reply to

    We had a guy do this nonsensical crap in an app we were developing. Apparently it was "confusing" for him to generate HTML at the file level so he he generated it all in the SQL.

     

    We fire him.

  • (unregistered)

    this is actually a good way to replace the .InnerHTML of a DIV block using some DHTML..
    used mostly for dynamically querying a webservice after the page has rendered ..
    a typical scenario is populating a dropdown based on the selection of another dropdown when it doesn;t make sense to cache everything in the page load or when your data is too volatile ..

    http://www.codeguru.com/Csharp/Csharp/cs_webservices/tutorials/article.php/c7781/
    http://www.15seconds.com/issue/040708.htm

    quit your whining and get with the program, you noob ...

  • (unregistered) in reply to
    :

    You asserted that SQL Server would, and I quote (again):

    "[generate] values for the identity column however it sees fit, regardless of the ORDER BY in the select statement you used to insert the data"

    This is a mischaracterization of the facts, and I'm sad to see you squirm just because I have shined a light of knowledge on your ineptitude. My wish is merely to stamp out bad information so that some other n00b doesn't adopt it as "fact" the way that you have done, and begin spouting it on boards to look strong.

    YES, the order of the Departments may be spurious, but this is because of the manner in which the storage engine CHOOSES TO INSERT THEM. This has nothing whatever to do with "generating values for the identity column however it sees fit". Nothing could describe the problem more poorly, as several other souls have pointed out to you, yet you insist on saying that you never said what I am quoting here.

    This argument is getting well past pointless. You are choosing to devote a lot of time and effort on a difference in semantics. I know what I meant, and you know what I meant. If you really need stuff to be that rigorously worded to avoid having a nervous breakdown, you would be much better off reading academic journals and not this, a humor website. I'm done with this argument and won't be replying to this thread again. Sorry to everyone else for encouraging this jerk.

     

  • (cs) in reply to
    :
    [image] Drak wrote:

    By the way: Properties ARE quite slow sometimes in .Net, so if pure performance is what you need I suggest not using them. But for readability and for ease of use of libraries by other people they are what you want.

    How about we use properties *until* performance is actually measured, found to be unacceptable, and then those properties determined to be an actual factor in the unacceptable performance?

    This is what I meant to say :P

    (Obligatory supporting story)

    Did some quick one-shot tool some time ago. Used properties. Took too long. Used plain variables, took about 70% of the time. In that case it really helped.

    Drak

  • (unregistered) in reply to
    :
    this is actually a good way to replace the .InnerHTML of a DIV block using some DHTML..

    Surely you jest.  The best way to generate the HTML you need is using the same templating system as you did to generate the page, else you're opening yourself up for some major headaches.

    used mostly for dynamically querying a webservice after the page has rendered ..

    Good example of making things up as you go along. :)
  • (unregistered)

    Looks to me like this guy just invented Microsoft reporting server before Microsoft did ...

    http://msdn.microsoft.com/msdnmag/issues/05/02/CustomRenderers/default.aspx


  • (unregistered) in reply to

    "templating system" ?
    "making things up as you go along" ?

    yeah .. you sure seem like you "know" what you're talking about as opposed to someone who talks out of their ass ...

Leave a comment on “Logical Tiers? That Makes No Sense! ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article