• (cs) in reply to C0d3r
    C0d3r:
    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.

    Speak like Yoda you do.

  • stew (unregistered)

    "OMFG! They're embedding client-side HTML in their server-side SQL!"

    "Yes, they really shouldn't be using stored procedures."

    Makes sense to me.

  • (cs) in reply to stew
    stew:
    "OMFG! They're embedding client-side HTML in their server-side SQL!"

    "Yes, they really shouldn't be using stored procedures."

    Makes sense to me.

    The point of the TDWTF is to find TRWTF which is hidden in TDWTF, but isn't the main WTF itself.

  • IN-HOUSE-CHAMP (unregistered)

    This approach is what I would take for building a small in house app. The approach is scalable and most of the work will be done by the database server.

    The front-end stays light weight and your client and IIS stay happy.

    Remember database servers are more than just data-stores. It makes perfect sense to let the database do the bulk of the work.

  • Sly (unregistered)

    Up to this day, the Oracle products other than their famous database are one of the crappiest things I've worked with :

    • With each major version of their Application Servers they buy a new to brand it and discontinue the preceding (welcome migration issues !)
  • O. Contraire (unregistered)

    And the PL/SQL in APEX is pretty much all behind the curtain (and the package bodies shrouded, so however WTF-worthy it is, you aren't going to see it). You can do a hell of a lot in APEX without ever writing any of your own stored code.

    captcha: feugiat (tempus fugit, but Tampas feugiat).

  • IN-HOUSE-CHAMP (unregistered) in reply to O. Contraire

    Apex is an amazing tool. Having had a chance to work with Tom Kyte, I can attest to that.

    O. Contraire:
    And the PL/SQL in APEX is pretty much all behind the curtain (and the package bodies shrouded, so however WTF-worthy it is, you aren't going to see it). You can do a hell of a lot in APEX without ever writing any of your own stored code.

    captcha: feugiat (tempus fugit, but Tampas feugiat).

  • Will A (unregistered)

    Dealt with something similar, every html page was written in dynamic sql --it was my job to convert it to static, so it could run faster. Just really ugly horrific work.

  • NZgeek (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    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.
    I find that using NHibernate is a lot harder than just writing a stored procedure. The main problem here is documentation. There's a fair amount on HQL, but that's close enough to SQL that you may as well not use an ORM at all. There's less around on the ICriteria methods, and practically nothing on QueryOver. Do you want to add a restriction to the ON part of a JOIN using QueryOver? Good luck finding anything in the documentation about that. It took me about an hour to find the right method to call, and another half an hour to figure out that our NHibernate version didn't have that method because we are 2 point releases behind. It's possible to hook into the underlying ICriteria to do the work, but again there is almost no documentation on this.

    Don't get me wrong, ORMs have their time and place. But in some cases you're simply swapping one problem for another, and that's almost always going to cause more problems.

  • Random Developer (unregistered)

    Let's not take our eye off the ball here. TRWTF is people that use stored procedures improperly.

    Stored procedures are supposed to encapsulate a data manipulation process. Write them atomically and they're no hassle at all. If you use them as a presentation layer or abuse them like they're the primary logic layer of your application, however, and you're in for a world of hurt.

    Assume you're writing an application to parse files of several different formats and accept data from web services customized for multiple different clients. Each format and each client's data is just enough different that not every field in the common database is used in every case. You would want to be able to code a parser or web service method that validates the data and breaks it into logical pieces (if necessary), then calls a stored procedure and submits only the pieces of information it has. Then, that stored procedure would be responsible for inserting that data, verifying that any supporting data could be inserted or matched up to it, and that all of the relational I's are dotted and T's are crossed.

    The primary logic layer is what happens before the stored procedure is called. This is where items are divided into their logical units and readied for storage.

    The stored procedure is more of a data integrity-checking logic layer. It makes sure that the caller's data gets into the correct tables and fields, and that the proper relationships are maintained.

    Both of these involve "business logic" because the business logic is responsible for 1) identifying logical units of data and 2) keeping those units related to each other properly. Item #1 is best done outside of the DB, and item #2 is best done BY the DB.

    Use the right tool for the job and use it in a way that shows you have some skill. Otherwise, you're just another code monkey.

    Tangentially related is the topic of ORM tools. ORM's are a way of generating code for CRUD operations. They're basically a mechanical code monkey. Don't use ORM's for anything requiring actual work. If you have to write more than a series of assignment statements either preceded by a load or followed by a save, you shouldn't use an ORM. And don't hire code monkeys for CRUD work. Again, the right (and cheapest) tool for the job.

  • wisi (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).

    Or in places where oldtimer SQL admins rule or are paranoid. My company doesn't allow any conversation outside of stored procedures (not even views).

  • wisi (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.

    You mean faggot-sharp? It can't do anything C# can't, so even inventing it was a monumental waste of time, let alone using it.

  • Re: The Apex of T-SQL (unregistered) in reply to BillClintonIsTheMan

    Man, I've got a pretty poor computer, and VS works perfectly on mine, both for normal use and compiling, which goes extremely fast. Then again, Eclipse runs awfully on my computer, so maybe it's just configured oddly.

    CAPTCHA: acsi, which someone else got already

  • Re: The Apex of T-SQL (unregistered) in reply to Re: The Apex of T-SQL

    That was in reply to this: [quote user="BillClintonIsTheMan"][quote user="Remy Porter"]TRWTF is that no-one complains about Visual Studio being slow/laggy/generally retarded with c# - VB.NET does not suffer this particular problem. [/quote]

  • A Person (unregistered) in reply to Dave

    They should have used Ruby. Ruby is what all the cool kids use

  • (cs) in reply to snoofle
    snoofle:
    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?

    Absolutely nothing. You're right. Data is data and any language that handles data is fine for the job.

    ... so you won't mind writing your next XML extract in APL...

  • assemblr (unregistered) in reply to wisi
    wisi:
    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.
    You mean faggot-sharp? It can't do anything C# can't, so even inventing it was a monumental waste of time, let alone using it.
    C# can't do anything raw ASM can't, so even inventing it was a monumental waste of time, let alone using it.
  • Gunslinger (unregistered)

    TRWTF is cursors.

  • MightyM (unregistered) in reply to assemblr
    assemblr:
    wisi:
    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.
    You mean faggot-sharp? It can't do anything C# can't, so even inventing it was a monumental waste of time, let alone using it.
    C# can't do anything raw ASM can't, so even inventing it was a monumental waste of time, let alone using it.

    Bah, assembler. Real programmers use just 1's and 0's. (Or butterflies.)

  • (cs)

    Actually, PL/SQL is a very decent language to express business logic. Just saying.

  • IN-HOUSE-CHAMP (unregistered) in reply to ammoQ
    ammoQ:
    Actually, PL/SQL is a very decent language to express business logic. Just saying.

    It is the best out there!

  • Alan (unregistered) in reply to ammoQ
    ammoQ:
    Actually, PL/SQL is a very decent language to express business logic. Just saying.

    HAHAHAHAHAHAHAHAHAHAHAHAHAHA

    Thanks for that laugh... Kids, this is why Oracle databases are typically full of junk code.

  • Barf 4Eva (unregistered)

    Duhhhhh... This is "Database First" design, people.

  • syk0saje (unregistered)

    TEXBOX

  • Sjaak (unregistered)

    I love APEX, only few tools allow such rapid development out-of-the-box. It's about the only Orcle tool worth buying. But it's free :p

  • steve (unregistered) in reply to ObiWayneKenobi

    A T/PL/SQL developer would respectfully disagree. All/any applications can/should be built using T/PL/SQL where the logic is close to the data.

    Seriously.. I've dealt with many dinosaur T/PL/SQL developers and have heard so many responses like this with a serious/straight face it is not even funny.

  • testwithus (unregistered) in reply to Anonymous

    SWIFT Interview questions on

    http://testwithus.blogspot.in/p/swift.htm

    For selenium solution visit http://testwithus.blogspot.in/p/blog-page.html

    QTP Interview Questions. http://testwithus.blogspot.in/p/qtp-questions.html

    www.searchyourpolicy.com
  • IN-HOUSE-CHAMP (unregistered) in reply to Matt Westwood
    Matt Westwood:
    This depressingly reminds me of my last job.

    The one you lost, you mean?

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

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article