• some guy (unregistered)

    All your storedProcs are belong to us!

  • TopicSlayer (unregistered) in reply to Russ
    Russ:
    Matthew:
    ChrisH:
    select *

    Straight out of the "Build a web app in 5 minutes" booklet.

    Oh who cares? If your tables are normalized in the first place, select * shouldn't be a big deal. If you need 8 out of 10 columns, it is just a waste of time typing each one out in the select query.

    Oh, I don't know, maybe you have some text columns in there? That would cause some issues.

    Also I don't think CF deals with with select * when you add and modify the columns and the connection pooling is on. Something about caching the schema in the driver..

    Ahhh, software cache, a spledid mechanism to build fast software that behaves badly.

    A sledgehammer solution, to replace actual performance profiling and software tweaking, used just "in case" the software "may not" be fast enough without it.

  • CF_Junkie (unregistered)

    Anyone who is bashing CF either A) used it when it was in version 4.5 or earlier (it's in version 8 now folks - kinda like comparing WinXP to Win 3.1) B) heard from some .Net developer that it's "not scaleable" or C) gets a hard-on from writing excessively long and bloated code. The CFML language has really gained some momentum in the last few years due to it's rapid development capability and easy-to-use integration features (i.e. you don't have to buy & install a DLL every other day), among other things. It's about time that some REAL developers hopped back into the CF arena and started correcting some of these CF WTFs from years past...

  • TopicSlayer (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    Matthew:
    ChrisH:
    select *

    Straight out of the "Build a web app in 5 minutes" booklet.

    Oh who cares? If your tables are normalized in the first place, select * shouldn't be a big deal. If you need 8 out of 10 columns, it is just a waste of time typing each one out in the select query.

    I used to wonder if people like you posted idiotic comments on here to be funny or whether they truly are idiots. Considering the amount of WTFuckery I've seen, I'm now inclined to think you are genuinely an idiot. "SELECT *" is stupid. What happens when someone modifies the schema and inserts a column between the existing ones? Something like "ALTER TABLE foo ADD COLUMN bar INTEGER AFTER COLUMN baz"?

    Ummm...I'm not sure about CF but I would assume it soft binds all the selected columns. So later on you do something like: "row.getCol("COLUMN_NAME")" which resolves to the data you want and it doesn't matter where in the select list the column is.

    But select * is still bad practice unless you know you want everything all the time regardless of schema changes. I would guess these cases are rare.

  • Grant (unregistered) in reply to Russ

    I used DataTool, but the people who made it stopped making it, and now it appears to be gone.

    You can, however, use SQL Enterprise Manager (or whatever it is called now) to get the DDL, and only a few tweaks will make it work fine, then use DTS and the ODBC driver for PostgreSQL to move the data.

  • Russ (unregistered) in reply to Grant
    Grant:
    I used DataTool, but the people who made it stopped making it, and now it appears to be gone.

    You can, however, use SQL Enterprise Manager (or whatever it is called now) to get the DDL, and only a few tweaks will make it work fine, then use DTS and the ODBC driver for PostgreSQL to move the data.

    What about stored procedures? I'm assuming those won't work in PostgreSQL as is. Also seems like PostgreSQL is case sensitive, and you can't turn that off... sounds like I'd have to have a lot of query rewriting to do...

  • Some American in His Bubble (unregistered) in reply to Mel
    Mel:
    Martin:
    Cold Fusion? It's the biggest WTF itself!

    It's probably used only in America, I've never seen it in Europe in production.

    Coz the world consists entirely of America and Europe...

    What?? There's more beyond America and Europe? Woah!

    Is it a good place, or is it scary?

    Scary, I bet.

  • GF (unregistered) in reply to KenVV
    KenVV:
    MasterPIanSoftware:
    pstorer:
    KenVV:
    MasterPIanSoftware:
    Martin:
    Cold Fusion? It's the biggest WTF itself!

    It's probably used only in America, I've never seen it in Europe in production.

    Exactly. They should've used .NET with DALs... oh wait then they couldn't use stored procedures at all because they're not portable. Oh wait, .NET is not portable, CF is.

    But wtf do I know, I'm a high school dropout.

    .NET is portable too... You can run it on Windows 2003 and Windows 2008. That's of course if you don't use the core edition. You can also run it on Vista. .NET is super cross platform. I mean you can run it in MONO!!!

    You guys are both retarded. They should've used RoR. RoR magically writes the queries for you, so you don't have anything to worry about.

    I'm not your guy, friend!

    He's not your friend, buddy!

    He's not your buddy, guy!

  • Matthew (unregistered) in reply to SomeCoder
    SomeCoder:
    Actually, I mostly agree with you. PHP isn't suitable as a templating language. I don't think calling it that is exactly correct though. I think it's fine to use as a back-end but using it for display logic (which is how it's used a lot of the time) can end up being pretty bad.

    But it was designed for display logic! That's the absurdity of PHP.

    PHP has a lot of weaknesses but I'd rather use something lightweight and fast than all of the bloated, slow frameworks that are floating around out there.

    Sure, if you just need to display some bits of dynamic content on an otherwise static web site, PHP is just fine. That's what it was designed for. But when you need something more complex with models, views, and controller, PHP blows. It is only a small step up from CGI scripts.

    Sorry for the PHP flame war. I'm just a little bitter as a former PHP hack. Once I learned more advanced languages like Python and Ruby, I never wanted to touch another line of PHP again... certainly not "backend" PHP.

  • (cs) in reply to Skaven
    Skaven:
    I think TRWTF is that a woman coder is the basis of this story.

    P.S. Hey Lindsay L do you live in the Chicago area? ;)

    No.

    And if I did, do you really think the way to pick up women is to say that being a female coder is TRWTF?

  • (cs) in reply to Licky Lindsay
    Licky Lindsay:
    Skaven:
    I think TRWTF is that a woman coder is the basis of this story.

    P.S. Hey Lindsay L do you live in the Chicago area? ;)

    No.

    And if I did, do you really think the way to pick up women is to say that being a female coder is TRWTF?

    Since everything else has failed, that is the real WTF.

    So, 7 good?

  • Gordon (unregistered) in reply to KenW
    KenW:
    Matthew:
    Oh who cares? If your tables are normalized in the first place, select * shouldn't be a big deal. If you need 8 out of 10 columns, it is just a waste of time typing each one out in the select query.

    And what happens when you have SELECT * all over your codebase, and over the next year your needs grow and your 10 column table is now 100 columns (a dozen of which are text or large varchar), but you're still only needing the 8?

    Then you've probably got bigger problems than "SELECT *". Changes of that magnitude often indicate that the application has expanded so much that it's now something completely different from what it was originally intended to be. This usually means that your original architecture is not sufficient to deal with all the added complexity, and that you should do a lot of refactoring to put in a better design.

    Unless you've got a pretty good idea up front that something like this is going to happen, and design accordingly, then it may not be worth it to "future proof" details like this.

  • Russ (unregistered) in reply to Matthew
    Matthew:
    SomeCoder:
    Actually, I mostly agree with you. PHP isn't suitable as a templating language. I don't think calling it that is exactly correct though. I think it's fine to use as a back-end but using it for display logic (which is how it's used a lot of the time) can end up being pretty bad.

    But it was designed for display logic! That's the absurdity of PHP.

    PHP has a lot of weaknesses but I'd rather use something lightweight and fast than all of the bloated, slow frameworks that are floating around out there.

    Sure, if you just need to display some bits of dynamic content on an otherwise static web site, PHP is just fine. That's what it was designed for. But when you need something more complex with models, views, and controller, PHP blows. It is only a small step up from CGI scripts.

    Sorry for the PHP flame war. I'm just a little bitter as a former PHP hack. Once I learned more advanced languages like Python and Ruby, I never wanted to touch another line of PHP again... certainly not "backend" PHP.

    Personally, I hate PHP, but doesn't it at least support FuseBox? So you can't really say that it doesn't support any framework..

  • Matthew (unregistered) in reply to KenW
    KenW:
    Matthew:
    Oh who cares? If your tables are normalized in the first place, select * shouldn't be a big deal. If you need 8 out of 10 columns, it is just a waste of time typing each one out in the select query.

    And what happens when you have SELECT * all over your codebase, and over the next year your needs grow and your 10 column table is now 100 columns (a dozen of which are text or large varchar), but you're still only needing the 8?

    A couple things:

    1. If a table has growing from 10 to 100, I probably need closer to 80 of those fields now. Or else why would I be adding all those fields in the first place? Would you then have me explicitly write out 80 column names in a select statement?

    2. I've never seen a table grow by an order of magnitude like that.

    3. A 100 column table is most likely not normalized and you should consider refactoring your schema.

    Being lazy now because "it is just a waste of time typing each one out in the select query" almost always ends up costing you in the long haul, whether it's by choking bandwidth pulling the extra data across your network or by taking up a lot of your time going back and fixing what you should have done right in the first place. Being lazy like that means you're not doing a good job.

    If I just need 1 or 2 columns, I will be specific in teh select. If I need most of them, I will use *. I didn't say I would never bother to be selective, just that "SELECT *" is not necessarily a WTF in and of itself. Chill out.

  • (cs) in reply to FredSaw
    FredSaw:
    NaN:
    If your mess looks like this one, you should step yourself up to championing it, it needs done already!
    What generally happens is a few months go by with nobody saying anything, and then one day someone (often me) will get tired of having to deal with the annoyance and bring it up at a team meeting, where it's finally revealed that no one is doing anything about the initiative any more and it's dead in the water. At this point someone (often me) will suggest that since we're not using it any more, we get rid of it. All will be in agreement on this with the possible exception of the guy who is always driven to play devil's advocate, so we'll devote about 10 minutes to arguing him down and then we'll agree that we need to get rid of it. And that will be all for that meeting.

    A couple of weeks later the subject will come up again and we'll agree that in order to get rid of it we have to have a plan and someone has to take ownership. And we'll all slough it off on George, the guy who handles everything because A) he's so good at it and B) he never learned how to say "no". So George will spend the next two or three weeks getting rid of the remains of the initiative, and once again birds will sing and sun will shine and flowers will bloom, until another manager's pet comes up with another bad idea.

    See,, the problem here is that you're having meetings. Nothing good can come of that. Avoid the meetings, fix the crap, meet informally with the guys who do the work (in your case I'd suggest a jam session after work), and, well, if that doesn't solve the problem:

    Walk Away. Quickly.

  • (cs) in reply to Matthew
    Matthew:
    SomeCoder:
    Actually, I mostly agree with you. PHP isn't suitable as a templating language. I don't think calling it that is exactly correct though. I think it's fine to use as a back-end but using it for display logic (which is how it's used a lot of the time) can end up being pretty bad.

    But it was designed for display logic! That's the absurdity of PHP.

    PHP has a lot of weaknesses but I'd rather use something lightweight and fast than all of the bloated, slow frameworks that are floating around out there.

    Sure, if you just need to display some bits of dynamic content on an otherwise static web site, PHP is just fine. That's what it was designed for. But when you need something more complex with models, views, and controller, PHP blows. It is only a small step up from CGI scripts.

    Sorry for the PHP flame war. I'm just a little bitter as a former PHP hack. Once I learned more advanced languages like Python and Ruby, I never wanted to touch another line of PHP again... certainly not "backend" PHP.

    Well, I hate to repeat this, but it's still the best paper on MVC that I've seen:

    http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

  • Russ (unregistered) in reply to CF_Junkie
    CF_Junkie:
    Anyone who is bashing CF either A) used it when it was in version 4.5 or earlier (it's in version 8 now folks - kinda like comparing WinXP to Win 3.1) B) heard from some .Net developer that it's "not scaleable" or C) gets a hard-on from writing excessively long and bloated code. The CFML language has really gained some momentum in the last few years due to it's rapid development capability and easy-to-use integration features (i.e. you don't have to buy & install a DLL every other day), among other things. It's about time that some REAL developers hopped back into the CF arena and started correcting some of these CF WTFs from years past...

    .NET is the not scalable one. What happens when your app outgrows a single server? .NET has no session replication to speak of, and neither do any of the other technologies that are not J2EE based. So go ahead and use .NET/PHP/RoR for your tiny sites, and we'll use CF for the sites that matter.

  • (cs) in reply to Some American in His Bubble
    Some American in His Bubble:
    What?? There's more beyond America and Europe? Woah!

    Is it a good place, or is it scary?

    Scary, I bet.

    Here be dragons.

  • (cs) in reply to real_aardvark
    real_aardvark:
    See,, the problem here is that you're having meetings. Nothing good can come of that. Avoid the meetings, fix the crap, meet informally with the guys who do the work (in your case I'd suggest a jam session after work), and, well, if that doesn't solve the problem:

    Walk Away. Quickly.

    Yeah, man... "Meetings: the practical alternative to work"!

  • Matthew (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    I used to wonder if people like you posted idiotic comments on here to be funny or whether they truly are idiots. Considering the amount of WTFuckery I've seen, I'm now inclined to think you are genuinely an idiot. "SELECT *" is stupid. What happens when someone modifies the schema and inserts a column between the existing ones? Something like "ALTER TABLE foo ADD COLUMN bar INTEGER AFTER COLUMN baz"?

    What is stupid is writing code that expects database columns to be in some specific order. Ever hear of using a hash/dictionary to access the rows of the returned results? Not only does it mean you don't run into problems when someone changes the schema, but it is easier to see what is going on in the code. I hate it when people reference rows as an array, i.e. "$row[9]" Yeah, great, make me count the the columns so I can find out what field that is. Genius.

  • CF_Flunkie (unregistered) in reply to Russ
    Russ:
    ....loads of ignorance....
    Seriously, you have no idea what you are talking about. Please stop being retarded. Or at least do it in private. Maybe the idiots you work for buy your shit, but you are talking to people who actually know what they are doing here.

    You are the ONLY one who would advocate CF. This is proven by your continued invention of usernames: Russ0519 Russ CF_Junkie MasterPIanSoftware pstorer KenVV

    Seriously, you are pathetic. Go back to your little day job at vshift.com where you write shitty little websites for people who don't even know about you (eliotspitzer.com) Jesus, you can't even make an intelligent argument for that joke of a language. You have got to be the stupidest, and most immature troll we have ever seen here at TDWTF. You make SpectateSwamp look smart.

  • Matthew (unregistered) in reply to Russ
    Russ:
    Matthew:
    SomeCoder:
    Actually, I mostly agree with you. PHP isn't suitable as a templating language. I don't think calling it that is exactly correct though. I think it's fine to use as a back-end but using it for display logic (which is how it's used a lot of the time) can end up being pretty bad.

    But it was designed for display logic! That's the absurdity of PHP.

    PHP has a lot of weaknesses but I'd rather use something lightweight and fast than all of the bloated, slow frameworks that are floating around out there.

    Sure, if you just need to display some bits of dynamic content on an otherwise static web site, PHP is just fine. That's what it was designed for. But when you need something more complex with models, views, and controller, PHP blows. It is only a small step up from CGI scripts.

    Sorry for the PHP flame war. I'm just a little bitter as a former PHP hack. Once I learned more advanced languages like Python and Ruby, I never wanted to touch another line of PHP again... certainly not "backend" PHP.

    Personally, I hate PHP, but doesn't it at least support FuseBox? So you can't really say that it doesn't support any framework..

    I didn't say that PHP doesn't support any frameworks. I'm saying that using PHP to build a framework (and then inventing a new language for templating on top of it) is kind of dumb... or at least silly. There's just so many more interesting, well thought out, general purpose languages to use for web frameworks. Leave PHP for what it is good for: displaying dynamic data in otherwise static web sites.

  • Joe (unregistered) in reply to KenW
    KenW:
    Matthew:
    Oh who cares? If your tables are normalized in the first place, select * shouldn't be a big deal. If you need 8 out of 10 columns, it is just a waste of time typing each one out in the select query.

    And what happens when you have SELECT * all over your codebase, and over the next year your needs grow and your 10 column table is now 100 columns (a dozen of which are text or large varchar), but you're still only needing the 8?

    Being lazy now because "it is just a waste of time typing each one out in the select query" almost always ends up costing you in the long haul, whether it's by choking bandwidth pulling the extra data across your network or by taking up a lot of your time going back and fixing what you should have done right in the first place. Being lazy like that means you're not doing a good job.

    I agree. But what if the "select *" is necessary? The results could be coming back to a function that changes over time to work with the new fields. Granted, it's not a refute of your argument, but "select *" isn't the worst of our problems. Keep in mind that not ALL small projects grow over time. Most do, and then they become WTFs. But there are no absolutes with this stuff. Sometimes you make exceptions. That's life. The experienced developers/DBAs/whatever know when to bend the rules.

    Forums and comments are filled with enough pricks telling everyone they are wrong without any context as to why they did something the way they did. Don't add to it :)

  • Ry (unregistered) in reply to Russ
    Russ:
    .NET is the not scalable one. What happens when your app outgrows a single server? .NET has no session replication to speak of, and neither do any of the other technologies that are not J2EE based. So go ahead and use .NET/PHP/RoR for your tiny sites, and we'll use CF for the sites that matter.

    This pretty much shows me that you have no clue what you're talking about when it comes to .Net. I assure you we have no issues serving a .Net application in a load-balanced multiple server environment.

  • (cs) in reply to Some American in His Bubble
    Some American in His Bubble:
    Mel:
    Martin:
    Cold Fusion? It's the biggest WTF itself!

    It's probably used only in America, I've never seen it in Europe in production.

    Coz the world consists entirely of America and Europe...

    What?? There's more beyond America and Europe? Woah!

    Is it a good place, or is it scary?

    Scary, I bet.

    Scary, but fun too! ;)

  • Guy (unregistered) in reply to GF

    I'm Guy.

  • Russ (unregistered) in reply to Ry
    Ry:
    Russ:
    .NET is the not scalable one. What happens when your app outgrows a single server? .NET has no session replication to speak of, and neither do any of the other technologies that are not J2EE based. So go ahead and use .NET/PHP/RoR for your tiny sites, and we'll use CF for the sites that matter.

    This pretty much shows me that you have no clue what you're talking about when it comes to .Net. I assure you we have no issues serving a .Net application in a load-balanced multiple server environment.

    I'm sure you don't have issues, but what about your clients?
    Does .NET support any sort of session replication? Or is it just sticky sessions? What happens when one of the servers in the cluster fails? Does everyone lose their session info? That doesn't sound like no problems to me... unless you're running a fairly static site on .NET that is.

  • KenW (unregistered) in reply to Guy

    You're not my guy, buddy

  • KenW (unregistered) in reply to Guy

    You're not my guy, buddy

  • (cs) in reply to CF_Junkie
    CF_Junkie:
    Anyone who is bashing CF either A) used it when it was in version 4.5 or earlier (it's in version 8 now folks - kinda like comparing WinXP to Win 3.1) B) heard from some .Net developer that it's "not scaleable" or C) gets a hard-on from writing excessively long and bloated code. The CFML language has really gained some momentum in the last few years due to it's rapid development capability and easy-to-use integration features (i.e. you don't have to buy & install a DLL every other day), among other things. It's about time that some REAL developers hopped back into the CF arena and started correcting some of these CF WTFs from years past...

    No, the biggest problem with CF is the same as the biggest problem with VB; it's too easy for the idiots to figure out how to use, and then you end up with people like russ0519 (currently trashing up this very thread posting as MasterPIanSoftware, pstorer, and KenVV) who think they are programmers. Then these ignorant unqualified-to-be-script-kiddies start cluttering up sites like this (and other code related sites) with wrong information about things, saying stupid stuff like "There's nothing wrong with SELECT * - it saves me keystrokes over specifying the actual column names.", or "PHP is a templating language and it sux".

    The problem with all of this is:

    1. It makes it harder to find actually valuable information, because it's hidden behind all of the clutter.

    2. Beginners see the crap these morons post and think it's good info, because it seems like it works OK. They then spread these wrong ideas/techniques/methodologies to other beginners, and the crap spreads like it's running out of a broken sewage treatment tank.

    3. It makes these failed losers think they're actually programmers, and so they think they're qualified to post about technical topics that they don't even comprehend.

    4. It wastes all of the real developer's time dealing with the bile spewing from the mouths of the scripting kiddies.

    Don't believe me? Review only this single thread for the posts by the user names I listed above; point out any single one of them that has even a shred of useful information in it. Keep track of the time you spend searching for that information.

    Done? Now count the total number of threads on just this site alone, and multiply it by the time you tracked above. See how much wasted time there is? Now multiply that tracked time by even an estimated number of programming related web pages you read in a single day, or week, or month, or year.

    Kinda shocking what you come up with, isn't it?

  • (cs) in reply to pstorer
    pstorer:
    You guys are both retarded. They should've used RoR. RoR magically writes the queries for you, so you don't have anything to worry about.

    The real irony is that RoR uses SELECT * by default. Although from other comments this poster seems to be a troll impersonating bstorer, so maybe that's the joke.

  • Ry (unregistered) in reply to Russ
    Russ:
    I'm sure you don't have issues, but what about your clients? Does .NET support any sort of session replication? Or is it just sticky sessions? What happens when one of the servers in the cluster fails? Does everyone lose their session info? That doesn't sound like no problems to me... unless you're running a fairly static site on .NET that is.

    The new web server will reload their session state from the database, and they'll continue on as if nothing happened. Assuming our servers do go down, the clients never notice.

  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    What happens when someone modifies the schema and inserts a column between the existing ones? Something like "ALTER TABLE foo ADD COLUMN bar INTEGER AFTER COLUMN baz"?

    Exactly. Always, always, always specify your columns.

  • KenW (unregistered) in reply to Ry
    Ry:
    Russ:
    I'm sure you don't have issues, but what about your clients? Does .NET support any sort of session replication? Or is it just sticky sessions? What happens when one of the servers in the cluster fails? Does everyone lose their session info? That doesn't sound like no problems to me... unless you're running a fairly static site on .NET that is.

    The new web server will reload their session state from the database, and they'll continue on as if nothing happened. Assuming our servers do go down, the clients never notice.

    Isn't getting and saving session data for every request to the DB a bit of a performance issue?

  • Frixus (unregistered) in reply to Russ
    Russ:
    Grant:
    I used DataTool, but the people who made it stopped making it, and now it appears to be gone.

    You can, however, use SQL Enterprise Manager (or whatever it is called now) to get the DDL, and only a few tweaks will make it work fine, then use DTS and the ODBC driver for PostgreSQL to move the data.

    What about stored procedures? I'm assuming those won't work in PostgreSQL as is. Also seems like PostgreSQL is case sensitive, and you can't turn that off... sounds like I'd have to have a lot of query rewriting to do...

    Stored procedures: dump as SQL, then search/replace all to convert them into a static class. Done.

    Case sensitivity: convert all queries to lowercase (or whichever case you prefer). Done.

    If either doesn't work you've got a lot more to worry about than just porting some database to another DBMS.

  • Ry (unregistered) in reply to KenW
    KenW:
    Isn't getting and saving session data for every request to the DB a bit of a performance issue?

    Its less performant than in-process session state, or using an out-of-process session state server (which .Net provides). In practice, it isn't really much of a performance issue, unless someone starts shoving huge amounts of data into the session, which means they're writing bad code.

    I'm not sure about the specifics of how Microsoft has implemented their database session state provider, but I'm assuming it uses some intelligence in what it writes, in which case its not like you're writing all the data all the time. Likely it just writes change sets, and only really loads when you jump across servers.

    If neither the session state server provider or database provider are acceptable, then a developer can use a 3rd party one or write their own. But we've found Microsoft's provided one to be more than acceptable, at least for our application.

    The main point is this: Saying that ColdFusion and J2EE are the only technologies that can handle a load balanced environment gracefully is idiotic.

  • (cs)
    <cfif CommentEnabled> call sp_getcomment(190594) <cfelse> <cfquery name="get_comment" ds="#datasource#> select comment from comments where id=190594 </cfquery> </cfif>
  • (cs) in reply to Matthew
    Matthew:
    1) If a table has growing from 10 to 100, I probably need closer to 80 of those fields now. Or else why would I be adding all those fields in the first place? Would you then have me explicitly write out 80 column names in a select statement?

    You might need 80, you might need 12. Considering the amount of stuff you could have in the table, grabbing all 100 -- even if you did need 80 -- is horribly wasteful for several kinds of resources.

    If I was doing your code review, I'd not only have you list all the columns out, if you had more than a couple (or the columns in the select statement had odd names), I'd have you do them each on their own line, with a trailing comment explaining what the column is and what you think it'll contain. It shows that you know what you want, where you want to get it from, and that you know how to deal with it once you have it.

    Saying "I'll grab everything and then just dig through the result set to get what I need" is a great way to hide bugs, is inefficient, and makes the code harder to maintain.

    Matthew:
    2) I've never seen a table grow by an order of magnitude like that.

    I've seen them get close. The number of datapoints in your experience is very likely not large enough to draw any sort of valid conclusion in this regard.

    Matthew:
    3) A 100 column table is most likely not normalized and you should consider refactoring your schema.

    Again, anecdotal evidence proves nothing. It may very well be normalized -- the number of columns in a table is completely orthogonal to the any normalization of that table.

    Matthew:
    If I just need 1 or 2 columns, I will be specific in teh select. If I need most of them, I will use *. I didn't say I would never bother to be selective, just that "SELECT *" is not necessarily a WTF in and of itself. Chill out.

    Nobody needs to chill out, because nobody's mad. Using 'select * ...' actually IS a WTF -- unless you know for a dead fact that your table is largely immutable (say, it's a 'states' table that has a two letter abbreviation and a long name; though I could think of ways that table might also grow). You can get bit pretty darn hard by expecting '*' to contain exactly one set of things in one certain order.

    Like I said earlier, it's wasteful and shows the wrong kind of laziness in a programmer.

  • Merl (unregistered) in reply to dtech
    dtech:
    <cfif CommentEnabled> call sp_getcomment(190594) <cfelse> <cfquery name="get_comment" ds="#datasource#> select comment from comments where id=190594 </cfquery> </cfif></div></BLOCKQUOTE> <p>Hey, that's not too good. You missed a quotation mark:</p> <cfif CommentEnabled> call sp_getcomment(190594) <cfelse> <cfquery name="get_comment" ds="#datasource#"> select comment from comments where id=190594 </cfquery> </cfif>
  • (cs)

    Nested WTFs are always the best.

    using ColdFusion {

    //I feel can say that from a position of knowledge, as I maintain an awful, legacy CF site myself, and I know how bad it is firsthand

    abandoning a big change thereby making future bugs certain {

    basing a massive change on a global variable {

    which massive change is itself based on a myth {

    // Using sprocs for performance of select statements is a myth. I know this, as I am also a SQL Server DBA

    } } } }

    Nice one!

  • PublicLurker (unregistered) in reply to korsuas
    korsuas:
    see this already posted in a comment in February. http://thedailywtf.com/Comments/SQL-Sentences.aspx?pg=2

    I see dead reposts.

    Well, they were going to remove the dead posts, but everything was working OK, and the project sort of ran out of steam. :-)

  • (cs) in reply to Joe
    Joe:
    KenW:
    Matthew:
    Oh who cares? If your tables are normalized in the first place, select * shouldn't be a big deal. If you need 8 out of 10 columns, it is just a waste of time typing each one out in the select query.

    And what happens when you have SELECT * all over your codebase, and over the next year your needs grow and your 10 column table is now 100 columns (a dozen of which are text or large varchar), but you're still only needing the 8?

    Being lazy now because "it is just a waste of time typing each one out in the select query" almost always ends up costing you in the long haul, whether it's by choking bandwidth pulling the extra data across your network or by taking up a lot of your time going back and fixing what you should have done right in the first place. Being lazy like that means you're not doing a good job.

    I agree. But what if the "select *" is necessary? The results could be coming back to a function that changes over time to work with the new fields. Granted, it's not a refute of your argument, but "select *" isn't the worst of our problems. Keep in mind that not ALL small projects grow over time. Most do, and then they become WTFs. But there are no absolutes with this stuff. Sometimes you make exceptions. That's life. The experienced developers/DBAs/whatever know when to bend the rules.

    Forums and comments are filled with enough pricks telling everyone they are wrong without any context as to why they did something the way they did. Don't add to it :)

    Yeah, it is surprising how many apparently have a sql comment from somebody stating "select *" is bad without knowing when and why it is bad, so now suddenly all "select *" is automatically bad to the degree where people think it is an ultimate and atomic truth.

  • Axl (unregistered) in reply to KenW
    KenW:
    Ry:
    Russ:
    I'm sure you don't have issues, but what about your clients? Does .NET support any sort of session replication? Or is it just sticky sessions? What happens when one of the servers in the cluster fails? Does everyone lose their session info? That doesn't sound like no problems to me... unless you're running a fairly static site on .NET that is.

    The new web server will reload their session state from the database, and they'll continue on as if nothing happened. Assuming our servers do go down, the clients never notice.

    Isn't getting and saving session data for every request to the DB a bit of a performance issue?

    One can use StateServer mode instead of SQLServer mode.

    Alternatively there are third-party solutions like ScaleOut StateServer.

  • Justin (unregistered)

    The Real WTF is all these people arguing over SELECT * when they should be using an ORM that does it for them.

  • m0ffx (unregistered)

    "...newer team members didn't even know why most of the procedures were defined twice in the first place...<cfif storedProcs>"

    There is TRWTF. If 'team members' can't figure out what cfif storedProcs might mean, or then guess 'ah, mayb the stored procedure hasn't been written yet', then the company should reconsider how it goes about hiring code mo-i mean, 'team members'.

    (I am assuming the variable name hasn't been 'anonymised' for some reason)

  • Iceman (unregistered) in reply to Justin
    Justin:
    The Real WTF is all these people arguing over SELECT * when they should be using an ORM that does it for them.

    Indeed. I didn't want too feed the troll too much, otherwise I would have posted something like: "only an idiot writes out his columns manually, everyone else uses some kind of generator."

  • Fedaykin (unregistered) in reply to Iceman
    Iceman:
    Justin:
    The Real WTF is all these people arguing over SELECT * when they should be using an ORM that does it for them.

    Indeed. I didn't want too feed the troll too much, otherwise I would have posted something like: "only an idiot writes out his columns manually, everyone else uses some kind of generator."

    I agree for the most part, but ORM's are not particularly good when you are dealing with complicated queries. In this case, you should probably be using a object-sql mapper (like iBATIS) so that queries can be optimized (preferably by a DBA). The point being that even when you use an ORM, you will likely still have hand written SQL somewhere if you have a non trivial reporting application with large data sets.

  • Justin (unregistered) in reply to Fedaykin
    Fedaykin:
    Iceman:
    Justin:
    The Real WTF is all these people arguing over SELECT * when they should be using an ORM that does it for them.

    Indeed. I didn't want too feed the troll too much, otherwise I would have posted something like: "only an idiot writes out his columns manually, everyone else uses some kind of generator."

    I agree for the most part, but ORM's are not particularly good when you are dealing with complicated queries. In this case, you should probably be using a object-sql mapper (like iBATIS) so that queries can be optimized (preferably by a DBA). The point being that even when you use an ORM, you will likely still have hand written SQL somewhere if you have a non trivial reporting application with large data sets.

    A decent ORM is going to have many options for query tuning for when you need it.

  • (cs) in reply to wee
    wee:
    Matthew:
    1) If a table has growing from 10 to 100, I probably need closer to 80 of those fields now. Or else why would I be adding all those fields in the first place? Would you then have me explicitly write out 80 column names in a select statement?

    You might need 80, you might need 12. Considering the amount of stuff you could have in the table, grabbing all 100 -- even if you did need 80 -- is horribly wasteful for several kinds of resources.

    If I was doing your code review, I'd not only have you list all the columns out, if you had more than a couple (or the columns in the select statement had odd names), I'd have you do them each on their own line, with a trailing comment explaining what the column is and what you think it'll contain. It shows that you know what you want, where you want to get it from, and that you know how to deal with it once you have it.

    Saying "I'll grab everything and then just dig through the result set to get what I need" is a great way to hide bugs, is inefficient, and makes the code harder to maintain.

    Matthew:
    2) I've never seen a table grow by an order of magnitude like that.

    I've seen them get close. The number of datapoints in your experience is very likely not large enough to draw any sort of valid conclusion in this regard.

    Matthew:
    3) A 100 column table is most likely not normalized and you should consider refactoring your schema.

    Again, anecdotal evidence proves nothing. It may very well be normalized -- the number of columns in a table is completely orthogonal to the any normalization of that table.

    Matthew:
    If I just need 1 or 2 columns, I will be specific in teh select. If I need most of them, I will use *. I didn't say I would never bother to be selective, just that "SELECT *" is not necessarily a WTF in and of itself. Chill out.

    Nobody needs to chill out, because nobody's mad. Using 'select * ...' actually IS a WTF -- unless you know for a dead fact that your table is largely immutable (say, it's a 'states' table that has a two letter abbreviation and a long name; though I could think of ways that table might also grow). You can get bit pretty darn hard by expecting '*' to contain exactly one set of things in one certain order.

    Like I said earlier, it's wasteful and shows the wrong kind of laziness in a programmer.

    Even if it is normalized it should still be broken down into logical groupings and placed in seperate tables for the sake of developers sanity. If you don't have seperate logical groupings in a 100 column table (or even if you have a 100 column table) then you have bigger problems to worry about than select *.

    And I second the ORM call. Performance isn't a problem until it becomes a problem, why would a bother writing out all those queries (with column names) even if their only called once a month? Any decent ORM will get out of the way and let you interact with the database directly if and when you need to.

    The real wtf in the original post was the gross overuse of stored procedures. Stored procedures weren't created for simple crud operations and queries, they're a last resort for complex scenarios that absolutely require the performance benefits.

  • Barf 4eva (unregistered) in reply to Matthew
    Matthew:
    ChrisH:
    select *

    Straight out of the "Build a web app in 5 minutes" booklet.

    Oh who cares? If your tables are normalized in the first place, select * shouldn't be a big deal. If you need 8 out of 10 columns, it is just a waste of time typing each one out in the select query.

    It's bad form. :|

    Not only that, if table structure for some odd reason changes, you might be introducing bugs later on, depending on how you coded your back-end. And how often will you have to write such select statements anyways? The act of pulling more columns than necessary can also have implications for the execution plan that need to be factored in. For loading a single row, perhaps not such a big deal. I wouldn't do it though. Spelling out your queries tends to work more in your favor and if it's only 8 columns anyways, are the keystrokes really going to kill ya? :D

Leave a comment on “The Stored Procedure Solution”

Log In or post as a guest

Replying to comment #:

« Return to Article