0

I am looking for hard to follow, large, pure readable and unsupportable SQL scripts with business logic. I need something overblown to illustrate Code vs SQL business logic. May be you have one?

Update: I am looking examples of terrible SQL. I am not looking for comparisons for these styles of business logic. May be you start task on inherited terrible SQL logic and you can share it. It could be absurd, funny or something like that. Actually, logic is not required queries are ok too.

Mike Chaliy
  • 25,801
  • 18
  • 67
  • 105
  • So you want examples of badly written SQL scripts to justify that business logic in SQL is bad? That's like asking for examples of bad French to prove that English is a better language! – Tony Andrews Feb 16 '09 at 17:50
  • I agree with Tony. If you are trying to do a fair presentation of both options, perhaps show *good* examples of both...you can write cr@p in any language... – E.J. Brennan Feb 16 '09 at 17:53
  • why don't you ask for a GOOD example, and if you won't see one - you can conclude that it probably doesn't exist – roman m Feb 16 '09 at 17:56
  • No-no, guys, I already have examples of bad written code, now I am looking for SQL. My aim is not to start yet another holy war, just to illustrate. – Mike Chaliy Feb 16 '09 at 17:58

4 Answers4

2

Anything with a trigger. They hide code off in unexpected places and create side effects that can be difficult to debug. Of course, triggers have their place, but you definitely need to use them with caution.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
  • I've never liked triggers either...glad I am not the only one. – E.J. Brennan Feb 16 '09 at 17:52
  • I do know pros and cons, but instead of writing my own example of terrible code, I am looking for exisiting. – Mike Chaliy Feb 16 '09 at 17:55
  • 1
    Once I inherited a project where the programmer used triggers to implement functionality that SQL Server provides for free with "ON DELETE CASCADE". *sigh* – Juliet Feb 16 '09 at 18:03
1

a fair comparison would show the same business logic in code vs sql

anything else is comparing apples to oranges - or worse, stacking the deck to support a foregone conclusion

Steven A. Lowe
  • 60,273
  • 18
  • 132
  • 202
0

Having bad SQL to prove your point will not work as it doesn't prove anything other than people can write bad SQL. There can be bad code that does the exact opposite to what you want to prove.

You might want to look into describing the abilities of the development team in place. If coding is their strong point rather than SQL then that is the route that should be taken.

Robin Day
  • 100,552
  • 23
  • 116
  • 167
0

I've posted a few nasty bits of SQL I've encountered in the real world:

Embedding UI Logic in stored procedures

A sorry excuse for a database search (near the bottom of that post)

Maybe a simpler example would be using a cursor to perform functions which could be more easily accomplished using basic SQL. For example compare simple query using a WHERE or GROUP BY clause to a stored procedure which implements the same functionality using cursor.

Community
  • 1
  • 1
Juliet
  • 80,494
  • 45
  • 196
  • 228
  • as far as i know, the only reason to use cursor is to mimic the FOR loop in sql, how do you do that with a "simple query using a WHERE or GROUP BY clause" ??? – roman m Feb 16 '09 at 18:30
  • by using a conditional statement on a column in the current row – blank Feb 16 '09 at 18:35
  • @Beds: how would i do the following: select 100 rows from a table, for each row - insert some of the columns into a different table, get SCOPE_IDENTITY(), and insert that along with some other columns from the initial select into a third table? – roman m Feb 16 '09 at 18:54
  • @rm: comments aren't a good place to discuss your question. Start a new question or consult the oracle: http://tinyurl.com/djftvy – Juliet Feb 16 '09 at 19:38
  • @Princess: i was just trying to figure out how to mimic a FOR-loop in sql w/o the cursor – roman m Feb 16 '09 at 20:13