IS THIS ABSOLUTELY BONKERS.....
I have just started working on a new project and I'm shocked at what I have just seen. This project is a C# web app that sits on top of an Oracle database. Now all the stored procedures are not actually stored procedures.... They are just SQL scripts stored in text files in a directory on the server. When the application starts it looks in the directory and goes through each file and reading out the text and saving it in a dictionary. It also runs a Regex over the text removing special sequences like [PARAM] and replaces them with the correct symbol e.g. ':' in Oracles case or '#' for SQL SERVER. Then when the code wants to execute one of these statements it calls a method which finds the correct one in the dictionary and runs it.
Now this appears to have been done in case they ever wanted to swap underlying db technologies. They say they would just swap the sql files out of the directory for files in the appropriate syntax and it would work.
Now I would normally expect the stored procedures to be actually stored procedures and live on the db. A separate project (layer) that talks to the db. Then if the db technology changes just add another data layer project and swap the dlls out....
I see massive problems with the way its been done currently:
No execution plan on the db server being created.
Massive overhead reading hundreds of text files, building up a string for each, running regex over it.
No checking of SQL syntax.
Big memory foot print having all these stored procedures in memory
What do you lot think?
Is this really bad or am I just moaning because I have never seen anything like this before?
What else is wrong with this approach?
Any comments will be much appreciated as I'm trying to get across to colleagues that this is crazy....
Why don't they use the scripts at build time to create stored procedure scripts in the native syntax (PSQL, T-SQL), which can then be deployed to the database? I can't see that would too much more work, and you get all the benefits of compiled stored procedure code etc.
I have personal experience of run-time compilation of stored procedures (SQL Server) being a big performance overhead, and on a production system this was a real problem.
I can sort of see the reasoning behind this design:
Stored procedure code is too database specific, so we won't use
stored procedures, we will use SQL statements instead.
Even SQL statements can have database specific syntax in them, so
we'll have some hokey method for converting them on the fly at
run-time.
Even if you don't use stored procedures, I still think the conversion should be done at build time (e.g., to generate C# code), not run-time.
What do you lot think?
I think it's a classic case of over-engineering: who changes their DB provider? Is it really bringing anything to the table?
Is this really bad or am I just moaning because I have never seen
anything like this before?
A bit of both in my opinion: it's quite bad but if they've been running like this for some time it's got to be working.
What else is wrong with this approach?
As it is, re-calculating the execution plan every time is probably the biggest issue:
so much performance loss! I'm saying probably because performance is not always a requirement (over-optimization isn't any better ;)
What is really wrong is that they reinvented the wheel: LINQ does that natively.
And that means as LINQ gets improved over time, the company will steadily fall behind since they won't benefit from the enhancements.
If you have any leverage power, try to talk to them about LINQ.
Related
I'm a software developer not a TSQL or DBA expert, just background. One of my applications uses allot of SQL views for reporting purposes, at this stage (might change) the windows application execute the view and I display the data in a grid/table for reporting purposes. The views are becoming more and more complex and slower, that's one problem. I'm in the process of re-designing the application to use a web front-end for reporting. But my question is what is the best approach with reports in terms of SQL, should my reports be based on Stored Procedure or Views? Any other comments or advice on SQL reporting welcome, like I mentioned I'm a software developer and I try to stay clear of SQL work, but this has become an issue and I thought this is a good time to sharpen my SQL knowledge.
Thank you for reading.
Stored procedures (SPs) are a better choice than views, but views are much better than SQL queries embedded in reports. I know you didn't mention embedded SQL but I'm going to discuss it briefly to give a more rounded answer.
When you embed a SQL query in a report (or an application or anything outside of the database) you are assuming that all of the objects referenced are not going to change in any way. This is firstly a big assumption (and assumptions are bad) and secondly a crippling restriction on the database owner - they can't change anything because it might break something somewhere.
When you use an SP or a view to access a database you make the reasonable assumption that the name of the object you are calling (the SP or view) won't change and that any parameter set will remain constant or at least stay compatible. Both approaches hide away the logic of the query from the caller - the logic can be corrected and improved over time without affecting the caller. The entire database can be refactored or even redeisigned as long as the name of the exposed object (and any parameters) remain the same and the caller will never know.
The advantage of using an SP over a view is that you can do far more. For example it's a good idea to validate that parameter values are within expected ranges. If you have a particularly complex query you can break it down into smaller steps, using temp tables for example. Moving on to very heavy queries you could even do interim maintenance steps in an SP, updating stats for example.
I would recommend using SPs for all database access. You might not need to now, but it will give you much more scope to change things in the future if you need to.
I have a medium-sized app written in Ruby, which makes pretty heavy use of a RDBMS. As our code grows, I found the ugly SQL statements are spreading to all modules and methods in my app and embedded in many application logic. I am not sure if this is bad, however, my gut tells me this is quite ugly...
So generally in any languages, how do you manage your SQL statements? Or do you think it is harmful for maintainibility to let many SQL statements embedded in the application logic? Why or why not?
Thanks.
SQL is a language for accessing databases. Often, it gets confused as being the API into the data store for a larger application. In fact, you should design a real API between the data store and the app.
The means several things.
For accessing data stored in tables, you want to go through views in the database, rather than directly access the tables.
For data modification steps, you want to wrap insert/update/delete in stored procedures. This has secondary benefits, where you can handle constraints and triggers in the stored procedure and better log what is happening.
For security, you want to include database security as part of your security architecture. Giving all users full access may not be the best approach.
Unfortunately, it is easy to write a simple app that uses a database directly, whether in java or ruby or VBA or whatever. This grows into a bigger app, and then the maintenance problems arise.
I would suggest an incremental approach to fixing this. Go through the code and create views where you have nasty select statements. You'll probably find you need many fewer views than selects (the views can be re-used -- a good thing).
Find places where code is being modified, and change these to stored procedures. I always return status from the stored procedure for error checking and put log information into a table called someting like splog or _spcalls.
If you want to limit permissions for different users of your app, then you might be interested in this.
Leaving the raw SQL statements in the code is a problem. Just wait until you want to rename a column and you have to find all the places where this breaks the code.
Yes, this is not optimal - maintenance becomes a nightmare; it's hard to forecast and determine which code must change when underlying DB changes occur. This is why it is good practice to create a data access layer (DAL) to encapsulate CRUD operations from the application logic. There is often an business logic layer (BLL) between the application logic and DAL to enforce business rules/logic.
Google "data access layer" "business logic layer" and even "n-tier architecture" to learn more.
If you are concerned about the SQL statements littered around your application logic, maybe consider implementing them as Stored Procedures?
That way you will only be including the procedure name and any parameters that need to be passed to it in your code.
It has other benefits too, a common one being easier to re-use in multiple files.
There is much debate about speed and security of Stored Procedure and you will never get a definitive answer about that so I won't even open that can of worms.
Here is how you do this with Java: Create a class that encapsulates all access to the database. Add a method to the class for each query you need to run.
The answer for ruby will be similar to this.
It depends on the architecture of your application but a simple solution is to keep each sql in a file, qry.sql. For each Ruby module (or whatever is used in Ruby to aggregate related code) you can keep a folder SQL with these files. So, the collection of SQL folder/files form the data access layer of your application. The Ruby code provides the business layer. If your data model changes (field names, etc), you can do greps to identify the sql files that need changes. Anyway, definitely separate SQL from your logic code.
I'm pretty new to SQL world. Here are my questions:
What are the benefits of stored procedured over normal SQL statement in applications?
Does stored procedure help eliminates SQL injection?
In Microsoft SQL Server it is called stored procedure. How about in Oracle, MySQL, DB2, etc.?
Thanks for your explanation.
Stored procedures only directly prevent SQL injection if you call them in a paramerized way. If you still have a string in your app with the procedure name and concatenate parameters from user input to that string in your code you'll have still have trouble.
However, when used exclusively, stored procedures let you add some additional protection by making it possible for you to disable permissions to everything but the EXEC command. Aside from this, parameterized queries/prepared statements are normally cached by the server, and so are just like a stored procedure in nearly every respect.
In spite of this, stored procedures have two big advantages for larger enterprises:
They allow you to define an application interface for the database, so that the system can be shared between multiple applications without having to duplicate logic in those applications.
They move the sql code to the db, where you can easily have an experienced DBA tune, update, and otherwise maintain it, rather than application developers who often don't know exactly what they're doing with database code.
Of course, these advantages aren't without cost:
It's harder to track changes in source control
The database code is far separated from the code that uses it
Developer tools for managing many stored procedures are less than ideal (if you've ever open the stored procedures folder in management studio to find 200 procedures for a database, you know what I'm talking about here).
Some of the benefits that I consider when using stored procedures
Stored procedures encapsulate query code at the server, rather than inside your application. This allows you to make changes to queries without having to recompile your application.
Stored procedures can be used for more well defined application security. You can Deny all rights on the base tables, grant execute only on the procs. This gives you a much smaller security footprint to manage.
Stored procedures are compiled code. With the latest versions of MSSQL the server does a better job of storing execution plans - so this isn't as big of an issue as it used to be, but still something to consider
Stored procedures eliminate SQL injection risk ONLY when used correctly. Make sure to use the parameters the right way inside the stored proc - stored procs that are just executing concatenated dynamic SQL inside them aren't doing anyone any good.
For the most part yes, SQL injection is far less likely with a stored procedure. Though there are times when you want to pass a stored procedure some data that requires you to use dynamic SQL inside the stored procedure and then you're right back where you started. In this sense I don't see any advantage to them over using parameterized queries in programming languages that support them.
Personally I hate stored procedures. Having code in two disjointed places is a pain in the ass and it makes deploys that much more complicated. I don't advocate littering your code with SQL statements either however as this leads to it's own set of headaches.
I recommend a DAL layer implemented one of two ways.
My favorite, use an object
relational management system (ORM).
I've been working with nHibernate
and I absolutely love it. The
learning curve in steep but
definitely worth the payoff in my
opinion.
Some kind of mechanism for keeping
all your SQL code in one place.
Either some sort of query library
you select from or a really
structured set of classes that
design the SQL for you. I don't
recommend this way since it's
basically like building your own ORM
and odds are you don't have the time
to do it correctly.
Forget stored procedures. Use an ORM.
One way in which stored procedures (ones which do not use dynamic SQL) can make the whole application more secure is that you can now set the permissions at the stored procedure level and not at the table level. If you do all of your data access this way (and forbid dynamic sql!) this means users can not under any circumstances do amnything to the database that is not in a stored proc. Developers always want to say that their application code can protect against outside threats, but they seem to forget that inside threats are often far more serious and by allowing permissions at the table level, they are at the mercy of any user who can find a way to directly query the database outside the application (another reason why in large shops only two or three people at most have production rights to anything in the datbase, it limits who can steal information).
Any financial system that uses anything except stored procs for instance is completely open to internal fraud which is a violation of internal controls that should prevent fraud and would not pass a good audit.
Stored procedures allow you to store you sql code in a location outside of the application. this gives you the ability to:
Change the SQL Code without recompiling/redistrubuting the application
Have multiple applications use the same stored procedure to access the same data.
Restrict users from having access to read/write to tables directly in the database.
From a development perspective it also allows the DBAs/database programmers to work on sql code without having to go through application code to work on it. (separation of responsibilities essentially).
Do stored procedures protect against injection attacks? For the most part yes. In sql server you can create stored procedures which are not effective against this, mainly by using sp_executesql. Now this doesn't main that sp_executesql is a security hole, it just means that more precaution needs to be taken when using it.
This also does not mean that stored procedures are the only way to protect against this. You can use parameritized sql to accomplish the same task of protecting against sql injection.
I do agree with other people stored procedures can be cumbersome, but they have their advantages too. Where I work, we have probably 20 different production databases for various reasons (don't ask). I work on a subset of maybe three, and my teammate and I know those three really really well. How do stored procedures help us? People come to us and when they need to grab that information out of those databases, we can get it for them. We don't have to spend hours explaining the schemas and what data is de-normalized. It's a layer of abstraction which allows us to program the most efficient code against the databases we know. If this isn't the case for you, then maybe stored procedures aren't the way to go, but in some instances they can add a lot of value.
Should queries live inside the classes that need the data? Should queries live in stored procedures in the database so that they are reusable?
In the first situation, changing your queries won't affect other people (either other code or people generating reports, etc). In the second, the queries are reusable by many and only exist in one place, but if someone breaks them, they're broken for everyone.
I used to be big on the stored proc solution but have changed my tune in the last year as databases have gotten faster and ORMs have entered the main stream. There is certainly a place for stored procs. But when it comes to simple CRUD sql: one liner insert/update/select/delete, using an ORM to handle this is the most elegant solution in my opinion, but I'm sure many will argue the other way. An ORM will take the SQL and DB connection building plumbing out of your code and make the persistence logic much more fluidly integrated with your app.
I suggest placing them as stored procedures in the database. Not only will you have the re-use advantage but also you'll make sure the same query (being a select, update, insert, etc...) it is the same because you are using the same stored procedure. If you need to change it, you'll only change it in one place. Also, you'll be taking advantage of the database server's processing power instead of the server/computer where your application resides. That is my suggestion.
Good luck!
It depends / it's situational. There are very strong arguments for and against either option. Personally, I really don't like seeing business logic get split between the database (in stored procedures) and in code, so I usually want all the queries in code to the maximum extent possible.
In the Microsoft world, there are things like Reporting Services that can retrieve data from classes/objects instead of (and in addition to) a database / stored procedures. Also, there are things like Linq that give you more strongly typed queries in code. There are also strong, mature ORMs like NHibernate that allow for writing pretty much all types of queries from code.
That said, there are still times when you are doing "rowset" types of things with your queries that work much better in a stored procedure than they work from code.
In the majority of situations, either/both options work just fine.
From my perspective, I think that stored procs are the the way to go. First, they are easier to maintain as a quick change to one means just running the script not recompiling the application. Second they are far better for security. You can set permissions at the sp level and not directly on the tables and views. This helps prevent fraud because the users cannot do anything directly to the datbase that isn't specified in a stored proc. They are easier to performance tune. When you use stored procs, you can use the database dependency metadata to help determine the affect of database changes on the code base. In many systems, not all data access or or even CRUD operations will take place through the application, having the code there seems to me to be counterproductive. If all the data access is in one place (an idea I support), it should be in the database where it is accessible to all applications or processes that might need to use it.
I've found that application programmers often don't consider the best way for a database to process information as they are focused on the application not the backend. By putting the code for the database in the database where it belongs, it is more likely to be seen and reviewed by database specialists who do consider the database and it's perfomance. We support hundreds of databases and applications here. I can look in any database and find the code that I need to find when something is slow. I don't have to upload the application code for each of hundreds of different applications just to see the part I need to do my job.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Assuming you can't use LINQ for whatever reason, is it a better practice to place your queries in stored procedures, or is it just as good a practice to execute ad hoc queries against the database (say, SQL Server for argument's sake)?
In my experience writing mostly WinForms Client/Server apps these are the simple conclusions I've come to:
Use Stored Procedures:
For any complex data work. If you're going to be doing something truly requiring a cursor or temp tables it's usually fastest to do it within SQL Server.
When you need to lock down access to the data. If you don't give table access to users (or role or whatever) you can be sure that the only way to interact with the data is through the SP's you create.
Use ad-hoc queries:
For CRUD when you don't need to restrict data access (or are doing so in another manner).
For simple searches. Creating SP's for a bunch of search criteria is a pain and difficult to maintain. If you can generate a reasonably fast search query use that.
In most of my applications I've used both SP's and ad-hoc sql, though I find I'm using SP's less and less as they end up being code just like C#, only harder to version control, test, and maintain. I would recommend using ad-hoc sql unless you can find a specific reason not to.
I can't speak to anything other than SQL Server, but the performance argument is not significantly valid there unless you're on 6.5 or earlier. SQL Server has been caching ad-hoc execution plans for roughly a decade now.
I think this is a basic conflict between people who must maintain the database and people who develop the user interfaces.
As a data person, I would not consider working with a database that is accessed through adhoc queries because they are difficult to effectively tune or manage. How can I know what affect a change to the schema will have? Additionally, I do not think users should ever be granted direct access to the database tables for security reasons (and I do not just mean SQL injection attacks, but also because it is a basic internal control to not allow direct rights and require all users to use only the procs designed for the app. This is to prevent possible fraud. Any financial system which allows direct insert, update or delete rights to tables is has a huge risk for fraud. This is a bad thing.).
Databases are not object-oriented and code which seems good from an object-oriented perspective is can be extremely bad from a database perspective.
Our developers tell us they are glad that all our databse access is through procs becasue it makes it much faster to fix a data-centered bug and then simply run the proc on the production environment rather than create a new branch of the code and recompile and reload to production. We require all our procs to be in subversion, so source control is not an issue at all. If it isn't in Subversion, it will periodically get dropped by the dbas, so there is no resistance to using Source Control.
Stored procedures represent a software contract that encapsulates the actions taken against the database. The code in the procedures, and even the schema of the database itself can be changed without affecting compiled, deployed code, just so the inputs and outputs of the procedure remain the same.
By embedding queries in your application, you are tightly coupling yourself to your data model.
For the same reason, it is also not good practice to simply create stored procedures that are just CRUD queries against every table in your database, since this is still tight coupling. The procedures should instead be bulky, coarse grained operations.
From a security perspective, it is good practice to disallow db_datareader and db_datawriter from your application and only allow access to stored procedures.
Stored procedures are definitely the way to go...they are compiled, have execution plan before hand and you could do rights management on them.
I do not understand this whole source control issue on stored procedure. You definitely can source control them, if only you are a little disciplined.
Always start with a .sql file that is the source of your stored procedure. Put it in version control once you have written your code. The next time you want to edit your stored procedure get it from your source control than your database. If you follow this, you will have as good source control as your code.
I would like to quote Tom Kyte from Oracle here...Here's his rule on where to write code...though a bit unrelated but good to know I guess.
Start with stored procedures in PL/SQL...
If you think something can't be done using stored procedure in PL/SQL, use Java stored procedure.
If you think something can't be done using Java Stored procedure, consider Pro*c.
If you think you can't achieve something using Pro*C, you might want to rethink what you need to get done.
My answer from a different post:
Stored Procedures are MORE maintainable because:
You don't have to recompile your C# app whenever you want to change some SQL
You end up reusing SQL code.
Code repetition is the worst thing you can do when you're trying to build a maintainable application!
What happens when you find a logic error that needs to be corrected in multiple places? You're more apt to forget to change that last spot where you copy & pasted your code.
In my opinion, the performance & security gains are an added plus. You can still write insecure/inefficient SQL stored procedures.
Easier to port to another DB - no procs to port
It's not very hard to script out all your stored procedures for creation in another DB. In fact - it's easier than exporting your tables because there are no primary/foreign keys to worry about.
In our application, there is a layer of code that provides the content of the query (and is sometimes a call to a stored procedure). This allows us to:
easily have all the queries under version control
to make what ever changes are required to each query for different database servers
eliminates repetition of the same query code through out our code
Access control is implemented in the middle layer, rather than in the database, so we don't need stored procedures there. This is in some ways a middle road between ad hoc queries and stored procs.
There are persuasive arguments for both - stored procedures are all located in a central repository, but are (potentially) hard to migrate and ad hoc queries are easier to debug as they are with your code, but they can also be harder to find in the code.
The argument that stored procedures are more efficient doesn't hold water anymore.
link text
Doing a google for Stored Procedure vs Dynamic Query will show decent arguments either way and probably best for you to make your own decision...
Store procedures should be used as much as possible, if your writing SQL into code your already setting yourself up for headaches in the futures. It takes about the same time to write a SPROC as it does to write it in code.
Consider a query that runs great under a medium load but once it goes into fulltime production your badly optimized query hammers the system and brings it to a crawl. In most SQL servers you are not the only application/service that is using it. Your application has now brought a bunch of angry people at your door.
If you have your queries in SPROCs you also allow your friendly DBA to manage and optimize with out recompiling or breaking your app. Remember DBA's are experts in this field, they know what to do and not do. It makes sense to utilise their greater knowledge!
EDIT: someone said that recompile is a lazy excuse! yeah lets see how lazy you feel when you have to recompile and deploy your app to 1000's of desktops, all because the DBA has told you that your ad-hoc Query is eating up too much Server time!
someone said that recompile is a lazy excuse! yeah lets see how lazy you feel when you have to recompile and deploy your app to 1000's of desktops, all because the DBA has told you that your ad-hoc Query is eating up too much Server time!
is it good system architecture if you let connect 1000 desktops directly to database?
Some things to think about here: Who Needs Stored Procedures, Anyways?
Clearly it's a matter of your own needs and preferences, but one very important thing to think about when using ad hoc queries in a public-facing environment is security. Always parameterize them and watch out for the typical vulnerabilities like SQL-injection attacks.
Stored Procedures are great because they can be changed without a recompile. I would try to use them as often as possible.
I only use ad-hoc for queries that are dynamically generated based on user input.
Procs for the reasons mentioned by others and also it is easier to tune a proc with profiler or parts of a proc. This way you don't have to tell someone to run his app to find out what is being sent to SQL server
If you do use ad-hoc queries make sure that they are parameterized
Parametized SQL or SPROC...doesn't matter from a performance stand point...you can query optimize either one.
For me the last remaining benefit of a SPROC is that I can eliminate a lot SQL rights management by only granting my login rights to execute sprocs...if you use Parametized SQL the login withing your connection string has a lot more rights (writing ANY kind of select statement on one of the tables they have access too for example).
I still prefer Parametized SQL though...
I haven't found any compelling argument for using ad-hoc queries. Especially those mixed up with your C#/Java/PHP code.
The sproc performance argument is moot - the 3 top RDBMs use query plan caching and have been for awhile. Its been documented... Or is 1995 still?
However, embedding SQL in your app is a terrible design too - code maintenance seems to be a missing concept for many.
If an application can start from scratch with an ORM (greenfield applications are far and few between!) its a great choice as your class model drives your DB model - and saves LOTS of time.
If an ORM framework is not available we have taken a hybrid of approach of creating an SQL resource XML file to look up SQL strings as we need them (they are then cached by the resource framework). If the SQL needs any minor manipulation its done in code - if major SQL string manipulation is needed we rethink the approach.
This hybrid approach lends to easy management by the developers (maybe we are the minority as my team is bright enough to read a query plan) and deployment is a simple checkout from SVN. Also, it makes switching RDBMs easier - just swap out the SQL resource file (not as easy as an ORM tool of course, but connecting to legacy systems or non-supported database this works)
Depends what your goal is. If you want to retrieve a list of items and it happens once during your application's entire run for example, it's probably not worth the effort of using a stored procedure. On the other hand, a query that runs repeatedly and takes a (relatively) long time to execute is an excellent candidate for database storage, since the performance will be better.
If your application lives almost entirely within the database, stored procedures are a no-brainer. If you're writing a desktop application to which the database is only tangentially important, ad-hoc queries may be a better option, as it keeps all of your code in one place.
#Terrapin: I think your assertion that the fact that you don't have to recompile your app to make modifications makes stored procedures a better option is a non-starter. There may be reasons to choose stored procedures over ad-hoc queries, but in the absence of anything else compelling, the compile issue seems like laziness rather than a real reason.
My experience is that 90% of queries and/or stored procedures should not be written at all (at least by hand).
Data access should be generated somehow automaticly. You can decide if you'd like to staticly generate procedures in compile time or dynamically at run time but when you want add column to the table (property to the object) you should modify only one file.
I prefer keeping all data access logic in the program code, in which the data access layer executes straight SQL queries. On the other hand, data management logic I put in the database in the form of triggers, stored procedures, custom functions and whatnot. An example of something I deem worthy of database-ifying is data generation - assume our customer has a FirstName and a LastName. Now, the user interface needs a DisplayName, which is derived from some nontrivial logic. For this generation, I create a stored procedure which is then executed by a trigger whenever the row (or other source data) is updated.
There appears to be this somewhat common misunderstanding that the data access layer IS the database and everything about data and data access goes in there "just because". This is simply wrong but I see a lot of designs which derive from this idea. Perhaps this is a local phenomonon, though.
I may just be turned off the idea of SPs after seeing so many badly designed ones. For example, one project I participated in used a set of CRUD stored procedures for every table and every possible query they encountered. In doing so they simply added another completely pointless layer. It is painful to even think about such things.
These days I hardly ever use stored procedures. I only use them for complicated sql queries that can't easily be done in code.
One of the main reasons is because stored procedures do not work as well with OR mappers.
These days I think you need a very good reason to write a business application / information system that does not use some sort of OR mapper.
Stored procedure work as block of code so in place of adhoc query it work fast.
Another thing is stored procedure give recompile option which the best part of
SQL you just use this for stored procedures nothing like this in adhoc query.
Some result in query and stored procedure are different that's my personal exp.
Use cast and covert function for check this.
Must use stored procedure for big projects to improve the performance.
I had 420 procedures in my project and it's work fine for me. I work for last 3 years on this project.
So use only procedures for any transaction.
is it good system architecture if you
let connect 1000 desktops directly to
database?
No it's obviously not, it's maybe a poor example but I think the point I was trying to make is clear, your DBA looks after your database infrastructure this is were their expertise is, stuffing SQL in code locks the door to them and their expertise.