Stored Procedures

[nfbs]

They copied .NET ? rofl okay exactly where did they copy that from? MVC is a software engineering pattern they copied it from no one they just implemented their own framework on its principals.Goddam junior developers.

Junior programmers like me and James Gosling sometimes need to be corrected by senior devs like you.

 

[semaphore]

Why yes we do! Makes it easier to modify the data model and not make ANY changes to the DAL, BL or any other code. You can also customize the solution to a degree to suit the client's needs and leave your core solution intact.

Rofl. Clear sign of piss poor architecture. Thank god i dont work for companies with developers that advocate this type of design/development.

 

[FarligOpptreden]

"customize to suit a clients needs"? So another advocate of business logic in the DAL? Jesus!!!

You left out the "to a degree" in your half-arse quote. About 99% of our BL is wrapped up in services that can be called via CLR in SQL. We have some stock standard assemblies on our database to call the BL if and when we need scalability at a client without going through production code releases.

Go feed your troll friend semaphore, he's hungry.

 

[Hamster]

Lets first get the terminology right, LINQ is not exclusive to database querying. There is LINQ To Sql, Linq To Entities, etc. If one does not design the DBML correctly then indexes will not be used but that is not the developer writing the queries problem, its in fact the person who designed the table. The same can be applied in your situation (and it happened numerous times when i was there).

The fact is that in this day and age with all these compute clusters and with bigdata like _kabal_ said a lot of the heavy lifting can be loaded onto a clustered EC instance (2 Intel Xeon E5-2670 8-core processors, 244 GiB of RAM, 240 GB of SSD-based). With that type of power i don't need some puny database to do my "heavy work". And there are much more intelligent ways to write datawrappers/layers without the need for

C/R/U/D sprocs and other random ones.

I would've thought in a thread about stored procs "LINQ to SQL" was implied.

The developer should have some degree of responsibility especially if they know they are working with something like DB2 that just loves to lock rows and tables. Writing the same query in two different ways meant a difference in read time of 60 mins vs 5 mins. No amount of hardware will help when the actual software is a bottleneck.

That saying "with great power comes great responsibility" rings true. If you have the power to write SQL you should damn well take responsibility and consequences for writing a **** query that bottlenecks the system.

But that is for another thread. Point is, stored procs have their place.

 

[zippy]

Yes i agree with you 100%, but there are people on this form that believe that stored procedures are the correct way to write database layers. Slamming all business logic into hundreds of stored procedures is just piss poor pathetic design.

never said that. I said they have their uses. Of course slamming all business logic into stored procedures is stupid. What is equally stupid is saying they should never be used. Ever.

 

[sp4ceman]

i have problems with stored procs for a few reasons, but my number one reason is testability.

i worked briefly at the biggest dev house in my province. they love stored procs. love them.

problem is they can't really test stored procs. the tooling is **** and a pain and its nothing near code test tools. so they didn't test.

after 10 years each stored proc is about 800 lines of gibberish all calling other 800 line stored procs all doing *** knows what. so you make one change and literally have no clue wtf could happen.

code in the ide comes with tools enabling you to jump around a project following spaghetti code, the tooling in SQL doesn't allow it as well.

basically i treat the db as a storage unit and all logic in my codebase.

 

[DominionZA]

i have problems with stored procs for a few reasons, but my number one reason is testability.

i worked briefly at the biggest dev house in my province. they love stored procs. love them.

problem is they can't really test stored procs. the tooling is **** and a pain and its nothing near code test tools. so they didn't test.

after 10 years each stored proc is about 800 lines of gibberish all calling other 800 line stored procs all doing *** knows what. so you make one change and literally have no clue wtf could happen.

code in the ide comes with tools enabling you to jump around a project following spaghetti code, the tooling in SQL doesn't allow it as well.

basically i treat the db as a storage unit and all logic in my codebase.

I have moved in the same direction for the exact same reasons.

Sprocs still have their place.

In my current project, the staging database is clean clean clean. Tables, relationships and indexes is all.
The presentation database makes use of sprocs to sync between the two. I unfortunately don't have the luxury of integration services for this project ):

 

[_kabal_]

You left out the "to a degree" in your half-arse quote. About 99% of our BL is wrapped up in services that can be called via CLR in SQL. We have some stock standard assemblies on our database to call the BL if and when we need scalability at a client without going through production code releases.

Go feed your troll friend semaphore, he's hungry.

I left it out because it was irrelevant.
whether you drop a small nugget on the kitchen floor, or a diarrhea explosion on the kitchen floor, it doesnt change the fact that you just took a **** in the kitchen

 

[mercurial]

The only time I use stored procedures are for Crystal Reports.

 

[Compton_effect]

That's not the stored procedure's fault.
That's bad coding standards.

I've had the misfortune of writing reports for a SQL database that was based on a proprietary linux db.
Along the way from linux to SQL it had undergone at least 4 different dba's, each adding his own little flavor to the coding standards and some interesting contributions by a group of developers in Mumbai, who had all the theoretical knowledge you could get... I had views, functions, denormalised tables, stored procedures with a 1000+ lines, aliases, tables containing metadata for dll's simulating the legacy linux system.
The problem was not the architecture, it was the lack of it.
Only option short of a slash/burn approach was to add my own layer of complexity over it as quietly as possible, giving the client the results he wanted and walking away really fast.

i have problems with stored procs for a few reasons, but my number one reason is testability.

i worked briefly at the biggest dev house in my province. they love stored procs. love them.

problem is they can't really test stored procs. the tooling is **** and a pain and its nothing near code test tools. so they didn't test.

after 10 years each stored proc is about 800 lines of gibberish all calling other 800 line stored procs all doing *** knows what. so you make one change and literally have no clue wtf could happen.

code in the ide comes with tools enabling you to jump around a project following spaghetti code, the tooling in SQL doesn't allow it as well.

basically i treat the db as a storage unit and all logic in my codebase.

 

[ToxicBunny]

There is nothing wrong with Stored Procs.... but like everyone has said, they have their place and their uses.

I personally try and break things down into reusable blocks, and they become their own stored procs. This keeps stored procs manageable in terms of size and readability, and they're still entirely testable...

 

[Shred]

Horses for courses. I speak to people that say things like, "Always use SP's", "Always use LINQ", "Never use LINQ", "Never use triggers", etc, etc. I use them all; there are places for them all and you need to know them well enough to know when and when not to use a particular method.

 

[_kabal_]

The only interesting thing about stored procs is why 90% of them are created and consumed by "Microsoft" programmers

 

[BobsLawnService]

Since then (at least in the MS world), we have the likes of LINQ and Entity Framework.

The problem with these technologies is that the moment you try anything complex, the SQL that gets generated becomes a bloated, poorly performing mess. The worst example I've ever seen was a generated monstrosity containing four neted sub queries in a single query that was rewritten by a simple query with one sub query and three normal inner joins and was about 800% faster.

 

[_kabal_]

No, that is the problem with poor implementers of these technologies. Any ORM framework of note allows for adhoc, parameterized querying, that still makes use of the object mapping