• D (unregistered)

    set @tablestr='Frist'

  • LOLCODER (unregistered) 
    INSERT INTO TEMPLATE VALUES 
  (1, "
    "),
  (2, "  
    "),
  (3,      NULL),
  (4, "  
    "),
  (5, "  
    "),
  (6,      NULL),
  (7, "  
    "),
  (8, "
    "),
);
UPDATE TEMPLATE SET HTML='LOLCODER' WHERE TAGID=3;
UPDATE TEMPLATE SET HTML='MY TEMPLATING SYSTEM IS TOTALLY GENERIC!' WHERE TAGID=6;

SELECT CONCAT(*) FROM TEMPLATE;


UPDATE TEMPLATE SET HTML='FWAN' WHERE TAGID=3;
UPDATE TEMPLATE SET HTML='ÜBERCOOL SOLUTION' WHERE TAGID=6;

SELECT CONCAT(*) FROM TEMPLATE;

    I do see a pattern here.

  • Anonymous (unregistered)

    What? SQL is an awesome language for web pages! WTF this site is implying?

    also, SQL Server allows querys to output XML wich could be further processed by xsd, full MVC development model here.

  • (cs)

    I am kind of amazed/disgusted that we still rely on stored procs for anything other than large data aggregations that might need to do a bit of conditionals (e.g. for reports) in this day and age. With modern tools and ORMs (incl. micro-ORMs for those who like their SQL) there should never be a reason for stored procs anymore in most web applications (again, outside of maybe some large reports where you might need to do some calculations/checking).

  • (cs)

    Wait, HTML is XML is data, and aren't DATAbases designed to manipulate DATA?

    This is an excellent example of using the right tool for the job!

    What's wrong with that?

  • (cs)

    Well, at least the coder used CSS classes and not direct styles.

  • Leo (unregistered)

    The real WTF is Oracle.

    That's kind of tangential to the article, but it's something I want to express anyway.

  • faoileag (unregistered) in reply to ubersoldat
    ubersoldat:
    Well, at least the coder used CSS classes and not direct styles.
    You mean like width="180px" for the table cells? ;-)
  • kpcrash (unregistered)

    TRWTF is that the Oracle side of my office is still actively developing applications this way because the app server supports it and because it's Oracle, it must scale to infinite levels higher than anything us mere C# developers could produce. Databases aside, SQL or Oracle or any, unless this code is from the early 90's... when mullets were still cool... :)

  • ZoomST (unregistered)

    I'm quite surprised that part of the HTML code wasn't stored in a specific table... or did I missed it?

  • faoileag (unregistered) in reply to snoofle
    snoofle:
    This is an excellent example of using the right tool for the job!
    There is room for improvement, though: personally, I'd store config parameters like "180px" in their own database table and then get the values via a SELECT.

    And of course strings like "Statut actuel de votre commande:" have to come out of their own table as well. With an integer as message key and iso language codes, this would look like this:

    set @tablestr = @tablestr + '' + SELECT str FROM tblStrings WHERE id = 42 and lang=fr + ''

    Much better, don't you think?

  • (cs) in reply to faoileag

    What if the definition of HTML changes? You should put the tags in their own table.

    set @tablestr = @tablestr + '<' + (SELECT MAX(openTag) FROM tags WHERE tagId=12) + 'nowrap ="nowrap" width = "' + SELECT px FROM tblWidths WHERE id = 180 + '" >' + SELECT str FROM tblStrings WHERE id = 42 and lang=fr + '<'+(SELECT MAX(closeTag) FROM tags WHERE tagId=12)+'>'

    Now you're coding for the enterprise!

  • (cs)

    Cursors? This is clearly written by someone who doesn't know how to use tally tables...

  • Anon (unregistered) in reply to kpcrash
    kpcrash:
    TRWTF is that the Oracle side of my office is still actively developing applications this way because the app server supports it and because it's Oracle, it must scale to infinite levels higher than anything us mere C# developers could produce.

    Obviously. If you guys used Java, they wouldn't dare challenge your productivity, and life would be good.

    But yeah, been there before, and just the memory of it makes my blood boil. No kind of stupidity or retarded company policy should ever justify these atrocities. They'll pay dearly down the road with unmaintanable applications, downtimes, mysterious crashes and whatnot... they will, no matter how their ignorance make them blissfully unaware at the time.

    Peace treaty note: I know, C# is a good language (the only one in DotNet)

    Captcha: appellatio ...yeah, I know, blame on me, sorry!

  • T0n1 (unregistered)

    This seems to be an instance of the fairly common "it savvy boss" pattern: Mine tried to force me to port a core business (now 100KLOC) C# ASP.NET intranet web app I’ve written to T-SQL(!), as “Software done the right way is implemented in stored procedures!” Not even mentioning CLR stored procedures was allowed – the only argument that worked (and saved me from hell), was “I simply can’t.” His reply: “I see! You’re merely and simply a web programmer.”

    He hired me as an C# developer, later I learnt that he hates OO (“I KNOW Smalltalk. OO is BAD!”, even later I learned why he hates OO: When problems arise and I’m telling him why, in an OO world I am speaking in terms of real world business entities and .aspx views of these he defined himself that way. This makes him angry. About those parts of the system he forced me to implement with triggers and stored procedures, I am speaking in terms of “triggers and stored procedures that somehow interact badly” – and this makes him happy and smile. “I LOVE stored procedures” is his objection when I’m begging to be allowed to refactor out some of them.

    And yes, I’m finally looking for a new job.

  • (cs) in reply to faoileag
    faoileag:
    snoofle:
    This is an excellent example of using the right tool for the job!
    There is room for improvement, though: personally, I'd store config parameters like "180px" in their own database table and then get the values via a SELECT.

    And of course strings like "Statut actuel de votre commande:" have to come out of their own table as well. With an integer as message key and iso language codes, this would look like this:

    set @tablestr = @tablestr + '' + SELECT str FROM tblStrings WHERE id = 42 and lang=fr + ''

    Much better, don't you think?

    Absolutely! Of course, we'll need to account for the case where the syntax of SQL might change as well - more translation/lookup tables...

  • (cs) in reply to Anon
    Anon:
    Peace treaty note: I know, C# is a good language (the only one in DotNet)

    Oh, that's just factually incorrect. F# is the best language in .NET.

  • Pock Suppet (unregistered) in reply to kpcrash
    kpcrash:
    TRWTF is that the Oracle side of my office is still actively developing applications this way because the app server supports it and because it's Oracle, it must scale to infinite levels higher than anything us mere C# developers could produce.
    This. Our execs seem to have developed an inverse NIH syndrome, where anybody who programs for some other company must be smarter than anyone who programs for us. I'm starting to think they might be right - it might be smarter to work for someone else.

    Captcha: acsi - If you knew your ACSI character set better, you could tell me the octagon number for tab. (An IT guy who worked for one of our clients and naturally was smarter than all of us combined, kept referring to the column of "octagon" numbers on the ASCII character set chart.)

  • DonaldK (unregistered) in reply to Pock Suppet

    Your spelling of ASCII and misnaming of octal aside, it's actually easier to remember the octal numbers than the ASCII equivalents. The character set is nicely grouped for easy reference in octal... the dude is a bit of a dinosaur, but there's no real WTF in using octal for character references...

    Pock Suppet:
    kpcrash:
    TRWTF is that the Oracle side of my office is still actively developing applications this way because the app server supports it and because it's Oracle, it must scale to infinite levels higher than anything us mere C# developers could produce.
    This. Our execs seem to have developed an inverse NIH syndrome, where anybody who programs for some other company must be smarter than anyone who programs for us. I'm starting to think they might be right - it might be smarter to work for someone else.

    Captcha: acsi - If you knew your ACSI character set better, you could tell me the octagon number for tab. (An IT guy who worked for one of our clients and naturally was smarter than all of us combined, kept referring to the column of "octagon" numbers on the ASCII character set chart.)

    Captcha: augue. And that's the start of a new auguement.

  • (cs)

    Actually, I think Apex is a great tool for throwing together data entry forms quickly and easily. At my last job, I took over an 80 page Apex application from my predecessor who left before the application was released. The problem was not Apex; the problem was that my predecessor didn't use its higher-level tools, and instead wrote everything from scratch in JavaScript.

  • (cs)

    Also, I've often gotten flack for being anti-stored procedure, but this is mostly because I see it something unnecessary. SQL is not a real programming language (especially not T-SQL; PL/SQL is at least a bit better) and you can't solve problems as easily in SQL as you can with real programming. Yet far too often I meet data diddlers that only know SQL and try to shoehorn everything into SQL and the database. Whether it's conditional logic, a loop (i.e. cursor) or entire workflows, these people don't know anything other than writing stored procedures, triggers, and SQL batch jobs to handle what should be done using real code.

    Don't get me wrong, stored procs have their place, as I stated earlier mostly big reports that need to aggregate a lot of different things, but 9 times out of 10 whenever I see a truckload of sprocs, it's because most of the team don't know anything other than SQL.

  • (cs) in reply to DonaldK
    DonaldK:
    it's actually easier to remember the octal numbers than the ASCII equivalents. The character set is nicely grouped for easy reference in octal...
    Isn't it slightly easier in hex? E.g. the digits are 0x30 to 0x39 rather than wrapping from 060 to 0x71.
  • Popeye (unregistered)

    What a moronic mix of technologies. So you can generate a piece of shit web page written with ancient html that looks like the web design was done by a manager. Great idea Oracle and the idiots using this. Good luck upgrading to HTML 5.

  • (cs)

    I think we've both worked at the same place at some point. A line manager from days gone by used to love stuff like this. His excuse for putting business and presentation logic in stored procedures was "if we deploy at a clients, I don't have to recompile and redeploy the application, I can just edit the procedure in their productive system and we're good to go"

    Fuck process, fuck QA, fuck integrity, fuck the client and fuck whoever gets the call to fix this, because it won't be documented.

  • (cs) in reply to kpcrash
    kpcrash:
    TRWTF is that the Oracle side of my office is still actively developing applications this way because the app server supports it and because it's Oracle, it must scale to infinite levels higher than anything us mere C# developers could produce. Databases aside, SQL or Oracle or any, unless this code is from the early 90's... when mullets were still cool... :)
    I had a mullet in the early 90's, therefore we can deduce that mullets were not cool.
  • Didakos (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    I am kind of amazed/disgusted that we still rely on stored procs for anything other than large data aggregations that might need to do a bit of conditionals (e.g. for reports) in this day and age. With modern tools and ORMs (incl. micro-ORMs for those who like their SQL) there should never be a reason for stored procs anymore in most web applications (again, outside of maybe some large reports where you might need to do some calculations/checking).

    Considering that calculations and business logic don't belong into a SP, then you're basically saying that they have no use whatsoever. Personally, I dislike much more the SQL generated by most ORM, which are often abused nowadays. ORM are not "the answer", they are just one solution like another, and not necessarily the best one.

    In case you wonder, I don't "only know SQL", it's just one of the many tools I use every day. Also, I met many more Developers who have no clue about SQL (and, therefore, consider their language of choice like a golden hammer, going the RBAR way) than Developers who only know SQL.

  • RealWTF (unregistered)

    The RealWTF here, as usual, is Microsoft ...

    I was going to say the programmer in todays WTF should have used SqlXML and then an XSLT to generate the HTML, when it struck me like a million bolts of lightning. Microsoft should have developed SqlHTML long ago ... I mean, all the data thats stored in any database, will ultimately be displayed on a web page, right ? After all, the Internets and all that we hear about is big, and the language of Internets is HTML.

    Microsoft, please add this urgently required feature to your database server ...

  • Didakos (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Also, I've often gotten flack for being anti-stored procedure, but this is mostly because I see it something unnecessary.

    Same thing I think about ORM, quite often.

    ObiWayneKenobi:
    SQL is not a real programming language (especially not T-SQL; PL/SQL is at least a bit better) and you can't solve problems as easily in SQL as you can with real programming.

    Sorry, but this is wrong. SQL is a functional programming language, designed to handle relational data. If used properly, it's much more powerful than an imperative language, in its own domain.

    ObiWayneKenobi:
    Yet far too often I meet data diddlers that only know SQL and try to shoehorn everything into SQL and the database. Whether it's conditional logic, a loop (i.e. cursor) or entire workflows, these people don't know anything other than writing stored procedures, triggers, and SQL batch jobs to handle what should be done using real code.

    SQL is real code, you just seem to have difficulties accepting it. As for cursors, they are not needed. If one thinks that the only way to process some information is using cursors, then he should read "SQL for Dummies" before touching a database again.

    In my experience, to maintain sanity, the rule of thumb is to keep all data integrity logic inside the database, and all business logic outside of it. No "IF", no cursors, no triggers (unless absolutely necessary, since they alter the execution logic on the fly and they are a nightmare to debug).

    ObiWayneKenobi:
    Don't get me wrong, stored procs have their place, as I stated earlier mostly big reports that need to aggregate a lot of different things, but 9 times out of 10 whenever I see a truckload of sprocs, it's because most of the team don't know anything other than SQL.

    Then you have worked with poor teams, so far. I worked in many environments, and wrote personally hundreds of Stored Procedures and, yet, SQL is far from being the only thing I know.

    On something we agree: Stored Procedures can be used properly, or improperly. In my opinion, the only issue is that you haven't seen them used properly too often.

  • John (unregistered)

    Honestly the link at the end was the best, I literally (to my co workers surprise) laughed unfortunately loudly.

  • Anonymous Paranoiac (unregistered) in reply to DonaldK
    DonaldK:
    Your spelling of ASCII and misnaming of octal aside, it's actually easier to remember the octal numbers than the ASCII equivalents. The character set is nicely grouped for easy reference in octal... the dude is a bit of a dinosaur, but there's no real WTF in using octal for character references...
    Pock Suppet:
    kpcrash:
    TRWTF is that the Oracle side of my office is still actively developing applications this way because the app server supports it and because it's Oracle, it must scale to infinite levels higher than anything us mere C# developers could produce.
    This. Our execs seem to have developed an inverse NIH syndrome, where anybody who programs for some other company must be smarter than anyone who programs for us. I'm starting to think they might be right - it might be smarter to work for someone else.

    Captcha: acsi - If you knew your ACSI character set better, you could tell me the octagon number for tab. (An IT guy who worked for one of our clients and naturally was smarter than all of us combined, kept referring to the column of "octagon" numbers on the ASCII character set chart.)

    Captcha: augue. And that's the start of a new auguement.

    You don't really pick up on things like "sarcasm" and "scare quotes" very well, do you?

  • (cs)

    Wise man say "Do not make fun of tool, unless you come to know the tool."

  • Nigel Tufnel (unregistered) in reply to Remy Porter
    Remy Porter:
    Anon:
    Peace treaty note: I know, C# is a good language (the only one in DotNet)

    Oh, that's just factually incorrect. F# is the best language in .NET.

    Yes, but D minor is the saddest of all programming languages.

  • O. Contraire (unregistered) in reply to Popeye

    Time for another can of spinach, Popeye. T-SQL is Microsoft's procedural database language.

    Captcha: valetudo. (Valentino's sickly cousin, I guess.)

  • Thomas B (unregistered)

    What ? A small product ? Are you insane ? It's from the front-end when you buy our products ! In a multi-million-euros company ! F43R !!!

  • Jay (unregistered)

    Only in France!

  • Sean (unregistered)

    Did you steal this from my old job? Oh wait, we weren't allowed to use stored procs anyway.

  • (cs)

    I don't mind using SQL for things like SUM(), since that's the database's strength. I also think that you should have all your data integrity checks (FKs, checks, triggers if necessary) as well as check them server-side in the app and client-side if necessary.

    However, my whole career has pretty much just seen a reliance on stored procs for every bit of data access, and often not JUST data access (the aforementioned putting business logic or even entire workflows in SQL. I've even seen some sprocs that use the built-in way to do DOS commands to move files). I would infinitely prefer an ORM (most modern ones generate optimized SQL; I know NHibernate does) or a Micro-ORM (so you can still write your own SQL and just use the mapper part) over having to dig through a massive stored proc.

  • Zapp Brannigan (unregistered) in reply to Leo
    Leo:
    The real WTF is Oracle.

    That's kind of tangential to the article, but it's something I want to express anyway.

    I agree with you 100%. However I think the stored procedure in the article uses SQL Server syntax.

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Also, I've often gotten flack for being anti-stored procedure, but this is mostly because I see it something unnecessary. SQL is not a real programming language (especially not T-SQL; PL/SQL is at least a bit better) and you can't solve problems as easily in SQL as you can with real programming. Yet far too often I meet data diddlers that only know SQL and try to shoehorn everything into SQL and the database. Whether it's conditional logic, a loop (i.e. cursor) or entire workflows, these people don't know anything other than writing stored procedures, triggers, and SQL batch jobs to handle what should be done using real code.

    Don't get me wrong, stored procs have their place, as I stated earlier mostly big reports that need to aggregate a lot of different things, but 9 times out of 10 whenever I see a truckload of sprocs, it's because most of the team don't know anything other than SQL.

    In SQL, you write code to get a computer to do something. If that's not a real programming language, then I'd like to know what you definition of one is.

  • (cs) in reply to Remy Porter
    Remy Porter:
    What if the definition of HTML changes? You should put the tags in their own table.

    set @tablestr = @tablestr + '<' + (SELECT MAX(openTag) FROM tags WHERE tagId=12) + 'nowrap ="nowrap" width = "' + SELECT px FROM tblWidths WHERE id = 180 + '" >' + SELECT str FROM tblStrings WHERE id = 42 and lang=fr + '<'+(SELECT MAX(closeTag) FROM tags WHERE tagId=12)+'>'

    Now you're coding for the enterprise!

    Looks more like you're coding for the Ferengi. Or maybe the Romulans.

  • (cs) in reply to snoofle
    snoofle:
    faoileag:
    snoofle:
    This is an excellent example of using the right tool for the job!
    There is room for improvement, though: personally, I'd store config parameters like "180px" in their own database table and then get the values via a SELECT.

    And of course strings like "Statut actuel de votre commande:" have to come out of their own table as well. With an integer as message key and iso language codes, this would look like this:

    set @tablestr = @tablestr + '' + SELECT str FROM tblStrings WHERE id = 42 and lang=fr + ''

    Much better, don't you think?

    Absolutely! Of course, we'll need to account for the case where the syntax of SQL might change as well - more translation/lookup tables...
    That's why names like @MyVar are so most excellent - they're perfectly flexible to any situation.

  • (cs) in reply to Remy Porter
    Remy Porter:
    Anon:
    Peace treaty note: I know, C# is a good language (the only one in DotNet)

    Oh, that's just factually incorrect. F# is the best language in .NET.

    MSIL is obviously the best one. The rest are just imitators.

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Also, I've often gotten flack for being anti-stored procedure, but this is mostly because I see it something unnecessary. SQL is not a real programming language (especially not T-SQL; PL/SQL is at least a bit better) and you can't solve problems as easily in SQL as you can with real programming. Yet far too often I meet data diddlers that only know SQL and try to shoehorn everything into SQL and the database. Whether it's conditional logic, a loop (i.e. cursor) or entire workflows, these people don't know anything other than writing stored procedures, triggers, and SQL batch jobs to handle what should be done using real code.

    Don't get me wrong, stored procs have their place, as I stated earlier mostly big reports that need to aggregate a lot of different things, but 9 times out of 10 whenever I see a truckload of sprocs, it's because most of the team don't know anything other than SQL.

    This. In my experience, stored procedures and triggers should only be used to enforce business rules, so that if someone tries to manually enter data instead of using the application, or blindly refactor the application without knowing what they're doing, they don't break anything. But the application itself should not be written entirely in stored procedures.

    But I can see how it happens. You know what they say, when your only tool is a hammer all problems look like thumbs.

    Addendum (2013-04-23 12:29):

    ObiWayneKenobi:
    Also, I've often gotten flack for being anti-stored procedure, but this is mostly because I see it something unnecessary. SQL is not a real programming language (especially not T-SQL; PL/SQL is at least a bit better) and you can't solve problems as easily in SQL as you can with real programming. Yet far too often I meet data diddlers that only know SQL and try to shoehorn everything into SQL and the database. Whether it's conditional logic, a loop (i.e. cursor) or entire workflows, these people don't know anything other than writing stored procedures, triggers, and SQL batch jobs to handle what should be done using real code.

    Don't get me wrong, stored procs have their place, as I stated earlier mostly big reports that need to aggregate a lot of different things, but 9 times out of 10 whenever I see a truckload of sprocs, it's because most of the team don't know anything other than SQL.

    This. In my experience, stored procedures and triggers should only be used to enforce data rules, so that if someone tries to manually enter data instead of using the application, or blindly refactor the application without knowing what they're doing, they don't break anything. But the application itself should not be written entirely in stored procedures.

    But I can see how it happens. You know what they say, when your only tool is a hammer all problems look like thumbs.

  • BillClintonIsTheMan (unregistered) in reply to Remy Porter
    Remy Porter:
    Anon:
    Peace treaty note: I know, C# is a good language (the only one in DotNet)

    Oh, that's just factually incorrect. F# is the best language in .NET.

    TRWTF is that no-one complains about Visual Studio being slow/laggy/generally retarded with c# - VB.NET does not suffer this particular problem.

  • (cs) in reply to pjt33
    pjt33:
    DonaldK:
    it's actually easier to remember the octal numbers than the ASCII equivalents. The character set is nicely grouped for easy reference in octal...
    Isn't it slightly easier in hex? E.g. the digits are 0x30 to 0x39 rather than wrapping from 060 to 071.

    FTFY 0x71 != 071 (0x71 is 'q', 071 is '9')

  • (cs) in reply to pjt33
    pjt33:
    DonaldK:
    it's actually easier to remember the octal numbers than the ASCII equivalents. The character set is nicely grouped for easy reference in octal...
    Isn't it slightly easier in hex? E.g. the digits are 0x30 to 0x39 rather than wrapping from 060 to 0x71.

    The easiest form by far is JFGI.

  • (cs)

    This is silly and stupid!

  • C0d3r (unregistered) in reply to BillClintonIsTheMan
    BillClintonIsTheMan:
    TRWTF is that no-one complains about Visual Studio being slow/laggy/generally retarded with c# - VB.NET does not suffer this particular problem.

    Which problem? Being laggy? Maybe, because retarded VB.NET obviously is.

  • Dave (unregistered)

    TRWTF is that they didn't use MongoDB, because obviously SQL Server isn't web scale.

  • (cs)

    This depressingly reminds me of my last job.

Leave a comment on “The Apex of T-SQL”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article