Since SQL Server doesn't have packages, what do programmers do to get around it?

Question

I have a SQL Server database that has a huge proliferation of stored procedures. Large numbers of stored procedures are not a problem in my Oracle databases because of the O

Answer 1

1) Like people have said, Schema's are a more logical and ANSI compliant way to organize database tables and procedures.

2) Software engineering best practices are that we should never make a change directly on any server. Since all database sprocs are scripted and under configuration control, we can arrange those scripts into any folder structure we want.

3) The best argument against oracle packages is that based on experience and research on the Ask Tom site, one can't update a package without taking it off line. This is unacceptable. With SQL Server, we can update stored procedures on the fly, without interrupting production operation.

Update: WeMartin, you say "In a true production environment, changes should never be tested in production. Updates should be moved from a test environment to production in a scheduled and orderly manner. In a 24/7 system, then redundant production environment should handle down time while servers are updated".

I'm not at all implying that ANY changes are tested in production. Even if Changes are tested on 9 lower develop environments, these now completely and thoroughly tested changes will need to be deployed to the production server. At that point, using Oracle packages, the production server has to be brought down in all cases, even for minor sproc changes.