- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
All your storedProcs are belong to us!
Admin
A sledgehammer solution, to replace actual performance profiling and software tweaking, used just "in case" the software "may not" be fast enough without it.
Admin
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...
Admin
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.
Admin
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.
Admin
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...
Admin
What?? There's more beyond America and Europe? Woah!
Is it a good place, or is it scary?
Scary, I bet.
Admin
Admin
But it was designed for display logic! That's the absurdity of PHP.
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.
Admin
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?
Admin
Since everything else has failed, that is the real WTF.
So, 7 good?
Admin
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.
Admin
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..
Admin
A couple things:
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?
I've never seen a table grow by an order of magnitude like that.
A 100 column table is most likely not normalized and you should consider refactoring your schema.
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.
Admin
Walk Away. Quickly.
Admin
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
Admin
.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.
Admin
Admin
Admin
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.
Admin
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.
Admin
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.
Admin
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 :)
Admin
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.
Admin
Scary, but fun too! ;)
Admin
I'm Guy.
Admin
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.
Admin
You're not my guy, buddy
Admin
You're not my guy, buddy
Admin
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:
It makes it harder to find actually valuable information, because it's hidden behind all of the clutter.
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.
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.
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?
Admin
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.
Admin
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.
Admin
Exactly. Always, always, always specify your columns.
Admin
Isn't getting and saving session data for every request to the DB a bit of a performance issue?
Admin
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.
Admin
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.
Admin
Admin
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.
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.
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.
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.
Admin
Admin
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!
Admin
Well, they were going to remove the dead posts, but everything was working OK, and the project sort of ran out of steam. :-)
Admin
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.
Admin
One can use StateServer mode instead of SQLServer mode.
Alternatively there are third-party solutions like ScaleOut StateServer.
Admin
The Real WTF is all these people arguing over SELECT * when they should be using an ORM that does it for them.
Admin
"...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)
Admin
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."
Admin
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.
Admin
A decent ORM is going to have many options for query tuning for when you need it.
Admin
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.
Admin
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