August 16, 2004 at 4:54 pm
re speed:
With MS SQL Server, Microsoft will testify that a SP using temp tables and cursors will be most likely recompiled at execution time. Cursors have a reputation for being slow.
re scripts:
There are 2 disadvantages of scripts in SPs. One is that it is difficult to maintain source and version control. Two is that it does not promote reuse of code very well. Project time and development time is bound to be longer and that does count.
re future:
c# and java SPs will make a HUGE difference. But we have to keep them under good source control.
re concept of a data store:
I think a data store is just that, and there is a lot more advantage in running business code under com+ and j2ee.
August 17, 2004 at 2:48 pm
"I think a data store is just that, and there is a lot more advantage in running business code under com+ and j2ee."
I suppose you think an F-15 is just a place to store jet fuel? Let's get real, databases (relational or otherwise) were NOT developed as a convenient place to store data and those who think that's all they are for are in desperate need of an education.
The relational model of data in particular was developed on the twin pillars of set theory and predicate logic to provide a workable and flexible way to represent the CONSTRAINTS (rules) that define what the data IS. Earlier attempts at the same goal in the network and hierarchical models of data management failed because they were too complex and inflexible.
Do you suppose that programmers had no means of persisting data prior to the invention of database systems? Of course they did! The problem was that file based storage systems data are dependent on the application that create the files and any other applications that need to use the data was forced to duplicate the business rules. Databases were developed to relieve the pain and inefficiencies of that method. Besides, just how long do you think your com+ or j2ee code will be around? It's almost a sure bet that the data will far outlive any application. Now we have programmers and "database professionals" who haven't learned this simple lesson making statements like that found in several posts above. Taking giant leaps into the past. Think about it...
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
August 17, 2004 at 10:21 pm
For the sake of code maintenance and the speed of writing it, object oriented languages like c#,c++,java merely require a persistant data store. Object databases &/or object APIs like jdo,odmg etc will improve project efficiency. This appears to be the trend. All F15s end up superseded. Lets make giant steps into the future, even if an rdbms is hidden behind the api.
August 17, 2004 at 11:20 pm
Code maintainability and coding speed come in way behind data quality, or they should. The most maintainable code is worthless if you don't have good data. Besides the more the business rules are built into your code the more complex the code must be and thus it becomes that much harder to maintain and that much more prone to error. Long experience has shown that data quality suffers as well, so what you are advocating is a lose-lose "solution."
The F-15 is already superseded by the F-22, but what you are suggesting is like replacing it with a U2. It is certainly nothing new and was never meant, and thus completely inadequate, to fill that role.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
August 18, 2004 at 12:35 am
Does Bruce Powell not realise that cursors are slow only when compared with set based SQL statements? They are probably quick compare with running the loop over a client recordset.
Also Bruce should remember that source code control is not limited to C# etc. In my last 2 projects we used VSS for all sprocs and UDFs.
August 18, 2004 at 4:27 pm
what stops a user editing a stored procedure via the properties menu in enterprise manager?
August 18, 2004 at 7:21 pm
Only the in-house standards stop a user doing this (bypassing VSS and changing sprocs directly). We ask developers to check out of VSS to a local folder, edit and test in Query Analyser, save back the file and check in.
When release time comes the code is extracted and applied in bulk from VSS to the release database, so if a user has bypassed VSS then their code does not get released and so they learn to use VSS next time.
August 18, 2004 at 8:20 pm
that is what we do but some lazy dba/developer always breaks the system so as to do it quick & easy; happens particularly when we work with a dba of a client on a dev job.That dba is in the habit of not using source control "at all". When our code is integrated into an ide, the source control runs smoothly. I have tried to integrate editing of SPs into the same ide with a sql plugin, but it is so easy to bypass it. The temptation to edit in Enterprise manager is great.
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply