• WanFactory (unregistered)

    The real WTF are the comments here, I have no objection to the comments. In fact, I say they are great because instead of just saying what is happening, they explain why they are that way. So, if the original reasons / assumptions behind the decision change, we can make intelligent and informed decisions as to whether to change the the design decision.

  • sympathic_dev (unregistered)

    coming from the perspective of someone who is very biased towards SPs, i think people should consider that maybe this poor dev is stuck in an environment with a control-freak DBA who does anything he can to delay or reject any changes to his precious Sql box. Perhaps that is the "overhead" this guy is referring to. Once youve had the displeasure of dealing with a DBA who consistently delays releases because of their non-existent management skills combined with an oversized ego, you may empathize with people who want to avoid any db-related changes.

  • Sam (unregistered)

    "Stored procedures are the ONLY way to go to ensure that all data is manipulated/retrieved in the same manor across many applications. If you went into screen A and queried a price for foo and it gave you $25, then went into screen B and got a price of $87 for foo, I'm sure that your company wouldn't be too happy with you. The last thing you want to do is have a price calculated differently in five different screens."

    Why would you do that? Your business objects should be the ones doing that work. Who said not using sprocs means not using a domain model? It is actually a lot more common IME to see systems with no coherent domain model because half the business logic is in the sprocs.

    The database schema should never change if your business objects do not. If this occurs where you work, then I pity the guy who comes after you and tries to maintain an application that mocks the ideal of "High Cohesion, Low Coupling".

    I suppose you could call me just another Fowler accolyte, but I've been where you are, believed the same thing, and I was just as wrong then as you are now. There is a better way.

    Of course, there's always exceptions... but when fighting against people who love to modify the database schema without justification, or break your domain model by ripping business logic out of the app and into sprocs, then sometimes the best defense is ugly inline SQL. And if you build your statements in QueryAnalyzer, you still get the syntax checking, which is really the biggest downside to inline sql. (IMO; I've seen more inline sql fail due to simple syntax mistakes than anything else.)

  • Adelle Hartley (unregistered)

    @Jeff S
    >> I guess what you are looking for is one giant 100,000-step "wizard" to write all your code for you....

    Well, duh. Only the people using the wizard will be the end users or business owners, and the wizard will only ask the questions that are relevant.

    As for lightening my own workload - I'm working on that wizard now and it's mighty difficult.

  • Emphyrio (unregistered)

    I had to read the comment twice because it looks exactly like the comments I often write, rhetorical question and all. Personally, I write this type of comment so that when I have to look at the code in six months or two years, I can remember what I was thinking when I wrote it. The essay-type style is just how I think, and it's easier to be verbose than to condense it into a pithy one-liner.

    BTW, I have used inline SQL code instead of stored procs, because it's easier than going through the DBAs (no offense).

  • Peter da Silva (unregistered)

    "...that's why I won't use ADO 'cause that requires an external library, or VB 'cause that too needs a runtime DLL. Self-containment is hard."

    It is indeed. Dependencies that you don't control are a problem. One of the biggest problems I have on any platform... Windows, UNIX, or embedded systems all included... is dependencies I can't control. If I can figure out a way to remove a dependency from a program, then I consider that a win.

    Visual Basic? I don't get it. You have to put together a package that contains a bunch of DLLs that may or may not interact cleanly with the ones that other people have already stuck in... or you keep your DLLs separate and they don't get updated with the rest. And when you're finished, for a reward you get to write code in Visual Basic.

    It'll take someone better than Tom Sawyer to get me painting THAT picket fence.

    I'm reminded again of the Microsoft Excel team:

    -----

    Right. Well, that's what I thought, too. So when I was the program manager in charge of the first implementation of Visual Basic for Applications, I put together a careful coalition of four, count them, four different teams at Microsoft to get custom dialog boxes in Excel VBA. The idea was complicated and fraught with interdependencies. There was a team called AFX that was working on some kind of dialog editor. Then we would use this brand new code from the OLE group which let you embed one app inside another. And the Visual Basic team would provide the programming language behind it. After a week of negotiation I got the AFX, OLE, and VB teams to agree to this in principle.

    I stopped by Andrew Kwatinetz's office. He was my manager at the time and taught me everything I know. "The Excel development team will never accept it," he said. "You know their motto? 'Find the dependencies - and eliminate them.' They'll never go for something with so many dependencies."

    http://www.joelonsoftware.com/articles/fog0000000007.html

  • tag (unregistered)

    In a very BDFH fasion I developed my own mediary language for writing database access classes which are translated to the langauge I'm working in via a highly optimized code generator. The generated API has always been quite nice. I've always wanted to make my changes in one place as well: But I never like stuffing SQL in my (other language here). Or any other language in my (other language here) for that instance. If you're going to use templates for outputting your HTML...why the hell are you going to store your SQL scattered all over you goddamn code as string constants?

    Of course the generated code ends up being string constants, in quite obnoxious (but fast!) generated code, which is why every developer who inherits my projects in the future loves me profusely.

  • Ben (unregistered) in reply to koala

    Trying to make the code completely portable with respect to the database is silly; if you try to stop the database being an integral part of the application you will end up with the inner-platform effect. Why not abstract all your column names into a config file while you're at it? However, that is not necessarily what the coder is doing here.

    Conversely, taking as much logic out of the code as possible and putting it into stored procs just because you can is equally silly. If you have multiple applications written in different languages querying the same database, stored procs may be the way to go. Otherwise, performing data manipulation in objects using the language you're most familiar with might save you a lot of time.

Leave a comment on “A Preemptive Defense”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article