No more stored procedures

[Mcsquare]

Where I work, stored procedures are not used, but for a different reason. Stored procedures cannot be checked into a source control system and maintained under version control. On very big projects with lots and lots of programmers and multiple versions of software that are backwardly compatible, version control is a must.

[mfhobbs]

And just use one sql call: recordset.open( "insert data into table; select @@SCOPE_IDENTITY" )

[GroundSloth]

Is your company being sold or merged with another? Regardless, I don't see how avoiding stored procedures makes the code more portable to other databases. You are still writing TSQL which is not the same as other SQL implementations. I have done a side by side implementation of packaged software against both Oracle and SQL Server. We specifically used stored procedures in order to keep a single set of ASP code as the SQL was much different between the 2 databases. That's a rather strange request...

[mfhobbs]

hmmm... maybe the semi-colon is not general across databases. Perhaps detect if SQL Server before using it otherwise you may have to use it. Also... is @@SCOPE_IDENTITY database general? If not, you may have to have 'dialects' for different databases... e.g. http://coldfusion.sys-con.com/read/43794.htm

[Nick Parker]

Miszou wrote:

asking me not to use any server-side functions, stored procedures, views or queries and to keep all database coding within the code itself - just in case we need to change databases or sell to a client that doesn't use the same database that we do.

If that is his concern, you could look at using NHibernate[^] or ActiveRecord[^] from Castle[^], this will allow you to be database agnostic.

- Nick Parker Microsoft MVP - Visual C#
My Blog | My Articles

[mfhobbs]

If your guide can talk seriously about coupling and manage to conclude that exposing your relational object model to your client applications is a positive (without distracting to strawman performance discussions), I will buy it.

[SHentzel]

Wouldn't you want your db specific code IN the db instead of in your code? -- then your code doesn't have to change, you just create the corresponding stored procedure in the new database. Seems like this is exactly the wrong suggestion?

[Trooks]

Most major version control systems such as SourceSafe, CVS and PVS allow for version control of the underlying script. In fact, SQL Server 2005 is tightly integrated on a project basis with SourceSafe out of the box. So I do not understand this as a reason, but hey to each his own.

[slastnoy]

Except for some special cases there is no sense in using application generated unprepared queries. I always use prepared statements such as stored procedures and user-defined functions. It is more important in case with commercial projects to use prepared compiled statements, if you want to speed up your program. It is easy to transfer a stored procedure to a target server. I cannot see any reason for abandoning database logic except for some cases such as need to switch to a different database server platform in the nearest future. In case you use a complex web project that has its own engine, the database server must handle almost all aspects of your site through stored procedures and functions, that is: user authorization, gathering information about page components in case they are dynamically loaded depending on which address you query (it may be the same file with a different page id or address) and the info about them is stored in a database, page title, menus, navigation bars and other commonly used parts of a web page.

[Grimolfr]

David Stone wrote:

That's the dumbest thing I've ever heard.

Not quite the dumbest, but it ranks pretty highly.

---

Grim

(aka Toby)

MCDBA, MCSD, MCP+SB

Need a Second Life?[^]

SELECT * FROM users WHERE clue IS NOT NULL GO

(0 row(s) affected)

[Blexrude]

Your bosses idea that possible changes of the back end databases is a reason to go with in line SQL is flawed. This is all the more reason to use stored procedures. What if you use a function in your query that does not exist on the other db platform? This is easy to get around if you use SPs but if all your SQL is compiled guess what.... Is your boss a developer?

Jim Blexrude Senior Software Developer/Consultant

[Grimolfr]

@@SCOPE_IDENTITY doesn't even work on SQL Server. It should be SCOPE_IDENTITY(). (It's a system function, not a global variable.)

---

Grim

(aka Toby)

MCDBA, MCSD, MCP+SB

Need a Second Life?[^]

SELECT * FROM users WHERE clue IS NOT NULL GO

(0 row(s) affected)

[Drewcrewof2]

Excuse to the others but indeed this IS the dumbest thing I ever heard. Please post your supervisors email for us and we will take care of this for you.... (giggle)

[mfhobbs]

If using SQL Server, you can encrypt the stored procedures so they cannot be edited.

[Joel Palmer 0]

I think what is missed in the whole discussion so far is to criticise the thinking that developers can program for unknown and unseen circumstances. This is like saying 'make something but I'll give you the requirements later'. If the company is going to re-tool at some point, make sure you architect your business logic into a middle tier so that its less effort to swap out your data layer. I worked at a company that moved from MS SQL over to Oracle. It was very easy to see that we put way to much logic in the stored procedures. Either way, if the company decides to swap out one technology for another there is going to be significant cost. There is no avoiding it.

Joel Palmer Application Developer

[djtcp]

Egad! Aside from the performance and stability issues, this throws the door wide open for Sql Injection attacks! Will your boss be training the developers in the various ways of preventing those? --- dj

[mfhobbs]

I agree, every project I worked on that used stored procedures had them in source control. (So far only by managing them as individual (*.sql) files rather than taking advantage of any integration features.)

[SWFLADeveloper]

Only using clientside SQL open you up to the possibility of SQL injection attacks!!!

[Collin Parker]

I believe @@SCOPE_IDENTITY is not database general. Does your boss know this? If you really want to be database independant, you'll have to use 'dialects' as mfhobbs suggested or use an OR mapping tool such as nhibernate.

[Mark J Miller]

Wow! Your question has started a huge debate on so many related topics. I haven't read the entire thread, so I'm sure some of what I say will just be a rehash, but here's my 2 cents: 1) To be truely DB agnostic you need a Data Access Layer written for each Db. Your sample is proof of that (@@IDENTITY and SCOPE_IDENTITY()). 2) Stored procedures DO reduce network traffic, but the network is where the load is seen, not the database. Given the exact same resultset, a batch of 10 lines multiplied over 100s of queries per second WILL create a greater network load than using stored procedures. However, as long as your dynamic queries use parameters you will not see any significant load on the db. This however brings us back to #1 - Sql Server Parameters use @paramName while other vendors just use '?' (I have to admit I haven't used other vendors, this is just based on sample code I've seen). Anyhow, using stored procedures vs. dynamic sql is simply a design choice. Which must be weighed against your program's requirements. But your 'dynamic' sql should ALWAYS use parameters. The difference between using parameters and not using them is a factor of as much as 200 in favor of parameters. 3) using @@IDENTITY in the same batch runs the risk of pulling the wrong identity value and increases dramatically when run in a separate batch. 4) Do your web apps have any use to third parties? That's the first question to be asked. Unless your company is intending to change their business model and start adding technical support and investing time and money into deploying and supporting web applications on external systems and pulling resources away from your core functions, I don't see the point in even addressing the issue. I would say in most cases, applications written for internal use and then retro-fitted for use by third parties are begging for problems. I'm not just referring to portability issues here, I'm talking about culture. Applications are written with specific groups of end users in mind, in this case your internal company culture. Which means the UI is designed with your company in mind and the way they use the application. If a different company starts using your application they have different goals in mind and will want to use the application in different ways than you do based on their business processes and how they want to integrate with their existing IT systems.