|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
a question for the soldiers on the lineAs with any new weapon holding the promise of a greater edge in battle,
sql2k5’s true worth can only be measured by the seasoned veteran who has used it under fire. To you veterans i now ask: Is the CLR feature proving it self a better performance alternative to application level processing on any level? I'd like to hear of what you've experienced in the field. -- thanks (as always) some day i''m gona pay this forum back for all the help i''m getting kes Hi
:-))) Well, i'd prefer using CLL only in cases where T-SQL is a weak. For example , some complex string maipulations. http://www.sql.co.il/books/insidetsql2005/ Itzik Ben-Gan has discusseed about where to use CLR ? Show quote "WebBuilder451" <WebBuilder***@discussions.microsoft.com> wrote in message news:D1F23293-8BDD-4C03-84D6-24693AEEA202@microsoft.com... > As with any new weapon holding the promise of a greater edge in battle, > sql2k5’s true worth can only be measured by the seasoned veteran who has > used > it under fire. To you veterans i now ask: Is the CLR feature proving it > self > a better performance alternative to application level processing on any > level? > I'd like to hear of what you've experienced in the field. > -- > thanks (as always) > some day i''m gona pay this forum back for all the help i''m getting > kes I wouldn't want to give a general statement on whether CLR is good or bad.
Say for example, CLR datatypes can let you have some complex datatypes for your tables in the database and thats good. But, I would go for that only if its impossible to store the data with the in-built datatypes. CLR aggregates is a good feature, but try running the perfmon and get the number of garbage collection thats happening when you do an aggregate on large volume. Now an aggrgation on a CLR datatype will require a CLR aggrgate. So, see what all will you be doing with the CLR datatype before you choose one. Scalar UDFs may be replaced with the CLR counterpart for which I heard the breakeven point was 6 integer operations (someone wrote in this newsgroup) And Table valued function.. for a single line table valued function (paramerized view) its still better to go with T-SQL, but all multi-line table valued functions can be replaced with the CLR equivalent, since CLR TVF can stream the results, whereas T-SQL TVF will have an intermediate storage or so I believe. Some MVP can (and will very soon) validate that. And like Uri said, complex string manipulations can be moved to CLR. But I would look at CLR this way, you run a stored procedure in T-SQL and send the result to front end (say 10000 records) and on that 10000 records you want to do some manipulation and a filter (only possible with the .NET class libraries) so that only some 100 records are really going to be used for further processing. In that case, you wasted on the movement of 9900 records over the network. You can instead move that functionality to the database with a CLR function or a SP and send only those 100 records to the front end. May be not the best explaination :) but I hope I put the idea across... >> : Is the CLR feature proving it self a better performance alternative to application level processing on any level? << Whart CLR does in practice is let non-SQL programmers continue to avoidlearning declarative programming and RDBMS. The guy that was spooling rows to temp tables (aka scratch tapes) to use cursors in loops (aka 1950's sequential file programming) can do without learning T-SQL kludges now. CLR shifts the burden of maintaining (n) different languages to the DBA and/or maintenance programmers. Oh, did I mention that those languages all have slightly different semantics to go along with the very different syntax? Look at Boolean values in C# and VB -- two proprietary languages from the same vendor! Or look at the MOD() function in the X3J languages. String comparison rules in Xbase, COBOL, etc. Temporal expressions that exist only in SQL.. The list goes on and on. In theory it is even worse. Why did we spend decades arriving at tiered architectures and verifiable software engineering prinicples to throw them away? With (n) different rules embedded in the DB, I cannot have any consistent data over time. What happens when I want to move to a new platform? The tiers are now blurred into a monolithic structure that has to be thrown out when you scale up or down. You no longer have a "component stereo system", but have returned to the 1950's console unit in a very solid piece of oak furniture. Decades ago, Dijkstra made a remark about how we keep repeating the same errors over and over in IT; he was right. ok, i think you gave me the answer that i wanted to hear. And the one it
seem's i'm discovering is true. It's a first shot at giving sql server and application language, ergo sql2005 is now an application server. I note MS has said otherwise, but with the inclusing of other features such as a web service that is "not a web server, but will accept web requests". We are looking at a half a** attempt to make it more functional for the non-sql programmer at the expense of performance. Now, for you i have a personal question; Is there a certification for sql developers that you would recomend? I need to learn better sql habits and get a better understanding of MSSQL administration, but mostly development better db skills. Thanks -- Show quotethanks (as always) some day i''m gona pay this forum back for all the help i''m getting kes "--CELKO--" wrote: > >> : Is the CLR feature proving it self a better performance alternative to application level processing on any level? << > > Whart CLR does in practice is let non-SQL programmers continue to avoid > learning declarative programming and RDBMS. The guy that was spooling > rows to temp tables (aka scratch tapes) to use cursors in loops (aka > 1950's sequential file programming) can do without learning T-SQL > kludges now. > > CLR shifts the burden of maintaining (n) different languages to the DBA > and/or maintenance programmers. Oh, did I mention that those languages > all have slightly different semantics to go along with the very > different syntax? Look at Boolean values in C# and VB -- two > proprietary languages from the same vendor! Or look at the MOD() > function in the X3J languages. String comparison rules in Xbase, > COBOL, etc. Temporal expressions that exist only in SQL.. The list > goes on and on. > > In theory it is even worse. Why did we spend decades arriving at > tiered architectures and verifiable software engineering prinicples to > throw them away? With (n) different rules embedded in the DB, I cannot > have any consistent data over time. What happens when I want to move > to a new platform? The tiers are now blurred into a monolithic > structure that has to be thrown out when you scale up or down. You no > longer have a "component stereo system", but have returned to the > 1950's console unit in a very solid piece of oak furniture. > > Decades ago, Dijkstra made a remark about how we keep repeating the > same errors over and over in IT; he was right. > > >> ok, i think you gave me the answer that i wanted to hear. And the one it seem's i'm discovering is true. << Amen!>> It's a first shot at giving sql server and application language, ergo sql2005 is now an application server. << If you wanted an application language inside SQL, there is already theSQL/PSM standard in place in DB2 and Mimer, planned for MySQL and future releases of some other products. No "force fitting" a language into the RDBMS. >> I note MS has said otherwise, but with the inclusing of other features such as a web service that is "not a web server, but will accept web requests". We are looking at a half a** attempt to make it more functional for the non-sql programmer at the expense of performance. << Not just performance; data integrity, cost of maintaining code andportability are important, too. >> Is there a certification for sql developers that you would recomend? I need to learn better sql habits and get a better understanding of MSSQL administration, but mostly development better db skills. << I recommend my own courses (surprise!), what you can get at a PASSconference and the stuff from SQLskills. Kimberly Tripp and crew are good speakers and are centered on SQL Server techniques; I tend to be the Standard SQL/RDBMS design and practices guy. >I need to learn better sql habits I'm here to give you another view. 'Better sql habits' is like militaryintelligence. It is a 'joke':) The good news is that the target of Joe's criticism is indeed jibberish. The bad news is that his view is just more jibberish:) It's a day for somaphors (plural for metaphors): If you want to communicate with people in other than your mother tongue do you think 'sanskrit' is a reasonable choice? What do you call someone who confuses 'means' and 'ends'?:) Ms. Delaney writes books about 'Inside Sql Server'. Has anyone written a book about the 'outside' of sql server? If you really want to learn about application development, database modelling and data manipulation and want to make the best use of Sql Server visit here: www.alphora.com best, steve http://racster.blogspot.com/ NHibernate (or Hibernate depending on platform) is another interesting
thing: http://www.hibernate.org/343.html Articles: http://www.codeproject.com/dotnet/nhibernatept1.asp http://www.theserverside.net/tt/articles/showarticle.tss?id=NHibernate http://weblogs.asp.net/pwilson/archive/2005/05/26/409042.aspx http://www.fincher.org/tips/Languages/NHibernate.shtml KL Show quote "Steve Dassin" <rac4sqlnospam@net> skrev i meddelandet news:OGJ5o3jyGHA.2208@TK2MSFTNGP03.phx.gbl... > >I need to learn better sql habits > > I'm here to give you another view. 'Better sql habits' is like military > intelligence. > It is a 'joke':) The good news is that the target of Joe's criticism is > indeed jibberish. > The bad news is that his view is just more jibberish:) > It's a day for somaphors (plural for metaphors): > If you want to communicate with people in other than your mother tongue > do you think 'sanskrit' is a reasonable choice? > What do you call someone who confuses 'means' and 'ends'?:) > Ms. Delaney writes books about 'Inside Sql Server'. > Has anyone written a book about the 'outside' of sql server? > > If you really want to learn about application development, database > modelling > and data manipulation and want to make the best use of Sql Server visit > here: > www.alphora.com > > best, > steve > > http://racster.blogspot.com/ > > Thanks for the links:)
Show quote "KL" <non***@nowhere.com> wrote in message news:urS422oyGHA.3440@TK2MSFTNGP06.phx.gbl... > > NHibernate (or Hibernate depending on platform) is another interesting > thing: > > http://www.hibernate.org/343.html > > Articles: > http://www.codeproject.com/dotnet/nhibernatept1.asp > http://www.theserverside.net/tt/articles/showarticle.tss?id=NHibernate > http://weblogs.asp.net/pwilson/archive/2005/05/26/409042.aspx > http://www.fincher.org/tips/Languages/NHibernate.shtml > > KL > > > "Steve Dassin" <rac4sqlnospam@net> skrev i meddelandet > news:OGJ5o3jyGHA.2208@TK2MSFTNGP03.phx.gbl... >> >I need to learn better sql habits >> >> I'm here to give you another view. 'Better sql habits' is like military >> intelligence. >> It is a 'joke':) The good news is that the target of Joe's criticism is >> indeed jibberish. >> The bad news is that his view is just more jibberish:) >> It's a day for somaphors (plural for metaphors): >> If you want to communicate with people in other than your mother tongue >> do you think 'sanskrit' is a reasonable choice? >> What do you call someone who confuses 'means' and 'ends'?:) >> Ms. Delaney writes books about 'Inside Sql Server'. >> Has anyone written a book about the 'outside' of sql server? >> >> If you really want to learn about application development, database >> modelling >> and data manipulation and want to make the best use of Sql Server visit >> here: >> www.alphora.com >> >> best, >> steve >> >> http://racster.blogspot.com/ >> >> > > --CELKO-- (jcelko***@earthlink.net) writes:
> Whart CLR does in practice is let non-SQL programmers continue to avoid I don't know really... The guy who used to write all is data manipulation> learning declarative programming and RDBMS. The guy that was spooling > rows to temp tables (aka scratch tapes) to use cursors in loops (aka > 1950's sequential file programming) can do without learning T-SQL > kludges now. in client code, can now move his code to the server, and at least save the network roundtrips. He still gets far from optimal performance, but it's better than before. Then again, some people who realise that the network roundtrips are costly, will now think that they can write CLR code in SQL Server, and loop over result sets all day long. Then yet again, when working in T-SQL these guys probably mainly uses curssos. Anyway, the CLR is a feature that really invites to abuse. There is a countless number of ways you can implement bad solutions with the CLR in SQL Server, and we can be sure that many of these ways will be tried. But that does not mean that CLR is crap from start to end. CLR code can be a very valuable supplement for things that are difficult to do in T-SQL. In SQL 2000 you can use extended stored procedures or OLE objects, but these solutions are ridden with instability problems, and are difficult to implement and use. CLR is also good for computation that does not inolve data access, like complex string manipulation. Say for instance that you have a table with imported data where numbers looks like: 00000012345600000å which actually means -123456. While this string can be converted in SQL, the CLR does it faster. -- Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se Books Online for SQL Server 2005 at http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx Books Online for SQL Server 2000 at http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx >> Say for instance that you have a table with imported data where numbers look like: 00000012345600000å which actually means -123456. While this string can be converted in SQL, the CLR does it faster. << Shouldn't that be done in the ETL tool and not the DB? Isn't that whatthe T means? And since the ETL tool is designed for this kind work, shouldn't it be much faster than pure SQL or CLR code? And what if the CLR languages you support in your schema are not any better than SQL at such strings but now add the overhead of embedding them? > Shouldn't that be done in the ETL tool and not the DB? Isn't that what Last fall I was refactoring a large ETL application. Moved all the> the T means? And since the ETL tool is designed for this kind work, > shouldn't it be much faster than pure SQL or CLR code? transformations except for the really complex ones to the server. Saved big time on network bandwidth. Performance in production got several times better. SQL is really really good at performing set based updates and inserts. >> Last fall I was refactoring a large ETL application. Moved all the transformations except for the really complex ones to the server. Saved big time on network bandwidth. << Look at Sunopsis. This product calls itself an ELT tool. It generatesvarious native SQL code and the flows between different target products. They get good numbers with a simple GUI interface and can take advantage of proprietary features on either end. Very useful with Teradata and parallel systems. --CELKO-- (jcelko***@earthlink.net) writes:
>>> Say for instance that you have a table with imported data where numbers look like: 00000012345600000å which actually means -123456. While this string can be converted in SQL, the CLR does it faster. << > Maybe. In our case we see this format when we get data from a> Shouldn't that be done in the ETL tool and not the DB? Isn't that what > the T means? And since the ETL tool is designed for this kind work, > shouldn't it be much faster than pure SQL or CLR code? competitor's system, every time we have taken one of their customers, and we need to convert the customer's data to our system. So it's not a general ETL procedure. True, we could run a script over the bulk files before we import them, and then load them in a nice form. Then again, that is just one of the many transformations we need to make, and most others are table-driven like mapping transaction types and that sort of thing. And since every conversion is a one-off thing performance is not top priority. When we ran the conversion for our biggest customer, that was a stored procedure that ran for six days! (What is special with the weird format, is that when I run ad-hoc queries on the input data, I prefer to see real numbers. And I run quite some ad-hoc queries on that data. There are always new suprises from that old system!) > And what if the CLR languages you support in your schema are not any During the beta of SQL 2005 I tested this precise format and compared> better than SQL at such strings but now add the overhead of embedding > them? a CLR function, a T-SQL function and T-SQL builtins. The CLR function beat the T-SQL builtins with some margin. But it's a correct observation that you need to account for the overhead of the function call. Invoking the CLR just for a simple charindex is likely to be a bad idea. -- Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se Books Online for SQL Server 2005 at http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx Books Online for SQL Server 2000 at http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx Hi Erland,
How would you rate CLR as compared to its predessessor, extended stored procedures? Alexander Kuznetsov (AK_TIREDOFSPAM@hotmail.COM) writes:
> How would you rate CLR as compared to its predessessor, extended stored Night and day. Extended stored procedures are expensive to call, you > procedures? cannot use them as functions, and most of all an unhandled exception brings down the entire SQL Server. -- Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se Books Online for SQL Server 2005 at http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx Books Online for SQL Server 2000 at http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx I can understand your comment since I think I know who you are Celko,
however you are completely and utterly wrong, it's in fact SQL that is 1950's programming, not the use of modern object oriented languages. SQL showed it's age already when it was created and we have been living with it's ridicolous shortcomings ever since. But this religious debate is being done much better elsewhere, suffice it to say that I'm not alone in thinking that we need to move away from SQL, we need something brand new, integrating the CLR is a step on the way but not really the answer. Also, you are completely wrong that the DBA is going to have to maintain code in (n) languages, to me a DBA is a wannabee programmer, what this does is move the responsibility to a real programmer and the dedicated DBA role is dying out. (Celko = http://www.google.com/search?q=Celko+sql&rls=com.microsoft:sv&ie=UTF-8&oe=UTF-8&startIndex=&startPage=1 ) know your sources ;) KL. Show quote "--CELKO--" <jcelko***@earthlink.net> skrev i meddelandet news:1156689798.846926.176820@b28g2000cwb.googlegroups.com... >>> : Is the CLR feature proving it self a better performance alternative to >>> application level processing on any level? << > > Whart CLR does in practice is let non-SQL programmers continue to avoid > learning declarative programming and RDBMS. The guy that was spooling > rows to temp tables (aka scratch tapes) to use cursors in loops (aka > 1950's sequential file programming) can do without learning T-SQL > kludges now. > > .... >> it's in fact SQL that is 1950's programming, not the use of modern object oriented languages. SQL showed it's age already when it was created and we have been living with it's ridiculous shortcomings ever since. << SQL did not exist until the 1980's, with SQL-86 as the first standard.Would you mind defining 1950's languages? What I saw in them was: 1) Weak typing -- REDEFINES in Cobol, EQUIVALENCE in Fortran, union in C, the use of pointers in assembly languages. The application defines the data. 2) Contigous storage as part of the language spec. This was needed for item (1), but it went further by requiring row major or row minor array ordering (Fortran versus PL/I). The reason that READ (a,b,c) was not the same as READ(b,c,a). Etc. 3) Hardware features defining language constructs. The 3-way IF in Fortran from IBM hardware; the ++a and a++ in the C family from DEC hardware. 4) Flow control -- the classic SP if-then-else, while-do and begin-end in various forms. As opposed to SQL's declarative syntax. 5) Direct Compilation. That is, when I put the same code thru the same compiler on the same hardware and system configuration, I will get the same executable code every time. This is certainly not true for SQL's optimizers 6) The assumption of a single user job rather than sessions sharing data. Two jobs could not read and/or write the same tape at the same time. >> I'm not alone in thinking that we need to move away from SQL, we need something brand new, integrating the CLR is a step on the way but not really the answer. << We used to sday the same things about Cobol; in fact, I wrote aneditorial in COMPUTERWORLD on that topic. But ~80% of the commerical software actually running major companies is still in COBOL. >> a DBA is a wannabee programmer, what this does is move the responsibility to a real programmer and the dedicated DBA role is dying out. << A "Real Programmer"?? It takes six years to become a Journey UnionCarpenter in New York State, but a "cowboy coder" can take a 4-week MS certification course. Or are real programmers those off-shore commodity workers that are popular these days? Think about 1000 cowboys being responsible for a Fortune 500 database without any central control. Be afraid, be very afraid. Yes, dedicated DBA role is dying out, but he is replaced far more specialized people. The physical DBA, the logical DBA, the data architect, the data steward, security and permissions guy, data miners, data auditors, etc. As ever you give an "opinion" without even understanding what CLR is or
gives to teh SQL Server Data Engine - NOTE the deliberatly not using the term RDBMS of which SQL Server is no longer, yes it does relational database but it does a lot of other stuff too, RDBMS within SQL is probably 5% of the product now. What experience do you have with CLR? What bench marks have you done comparing server side processing, out of data tier processing?? CLR shifts nothing anywhere, database professionals within teh SQL Server space should now fully understand .NET and atleast one of its languages not just because of CLR but because of the ETL tool that ships with the product and also to understand the more complicated environments that are being developed because business complexities and competition are so far developed. YOUR days where a database just stored the data, had some check constraints and gave back a result set are well gone, in fact they where gone on version 7.0! It really is time you woke up and smell the coffee and stop regurgating the usual canned drivel that you've been doing for the past 10 years and go back and learn about the changes that have happened within the database world and client server worlds.... > Why did we spend decades arriving at Because technology has changed so must the engineering principles, > tiered architectures and verifiable software engineering prinicples to > throw them away? principals and techniques have improved significantly from when I was coding on the mainframe in PL/1 and from my entry into client/server development 16 years ago in 1990. > With (n) different rules embedded in the DB, I cannot Why not? Centralising business logic makes perfect sense to me, it prevents > have any consistent data over time. tampering and accidents you also only need to code the rules once and in one langauge rather than having to do it in 'n' langauges depending on what the application is... > What happens when I want to move Do you have any stats to backup that this is a widescale problem? Platform > to a new platform? migration is usually done in order to improve business value and as such its not just a straight port - what would the business value be on a straight port? > The tiers are now blurred into a monolithic You totally misunderstanding .NET.> structure that has to be thrown out when you scale up or down. > You no You totally misunderstanding .NET.> longer have a "component stereo system", but have returned to the > 1950's console unit in a very solid piece of oak furniture. -- Show quoteTony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials "--CELKO--" <jcelko***@earthlink.net> wrote in message news:1156689798.846926.176820@b28g2000cwb.googlegroups.com... >>> : Is the CLR feature proving it self a better performance alternative to >>> application level processing on any level? << > > Whart CLR does in practice is let non-SQL programmers continue to avoid > learning declarative programming and RDBMS. The guy that was spooling > rows to temp tables (aka scratch tapes) to use cursors in loops (aka > 1950's sequential file programming) can do without learning T-SQL > kludges now. > > CLR shifts the burden of maintaining (n) different languages to the DBA > and/or maintenance programmers. Oh, did I mention that those languages > all have slightly different semantics to go along with the very > different syntax? Look at Boolean values in C# and VB -- two > proprietary languages from the same vendor! Or look at the MOD() > function in the X3J languages. String comparison rules in Xbase, > COBOL, etc. Temporal expressions that exist only in SQL.. The list > goes on and on. > > In theory it is even worse. Why did we spend decades arriving at > tiered architectures and verifiable software engineering prinicples to > throw them away? With (n) different rules embedded in the DB, I cannot > have any consistent data over time. What happens when I want to move > to a new platform? The tiers are now blurred into a monolithic > structure that has to be thrown out when you scale up or down. You no > longer have a "component stereo system", but have returned to the > 1950's console unit in a very solid piece of oak furniture. > > Decades ago, Dijkstra made a remark about how we keep repeating the > same errors over and over in IT; he was right. > I give up, go ahead and slam him :)
Show quote "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message news:O1MFepryGHA.3632@TK2MSFTNGP04.phx.gbl... > As ever you give an "opinion" without even understanding what CLR is or > gives to teh SQL Server Data Engine - NOTE the deliberatly not using the > term RDBMS of which SQL Server is no longer, yes it does relational > database but it does a lot of other stuff too, RDBMS within SQL is > probably 5% of the product now. > > What experience do you have with CLR? What bench marks have you done > comparing server side processing, out of data tier processing?? > > CLR shifts nothing anywhere, database professionals within teh SQL Server > space should now fully understand .NET and atleast one of its languages > not just because of CLR but because of the ETL tool that ships with the > product and also to understand the more complicated environments that are > being developed because business complexities and competition are so far > developed. > > YOUR days where a database just stored the data, had some check > constraints and gave back a result set are well gone, in fact they where > gone on version 7.0! > > It really is time you woke up and smell the coffee and stop regurgating > the usual canned drivel that you've been doing for the past 10 years and > go back and learn about the changes that have happened within the database > world and client server worlds.... > >> Why did we spend decades arriving at >> tiered architectures and verifiable software engineering prinicples to >> throw them away? > > Because technology has changed so must the engineering principles, > principals and techniques have improved significantly from when I was > coding on the mainframe in PL/1 and from my entry into client/server > development 16 years ago in 1990. > >> With (n) different rules embedded in the DB, I cannot >> have any consistent data over time. > > Why not? Centralising business logic makes perfect sense to me, it > prevents tampering and accidents you also only need to code the rules once > and in one langauge rather than having to do it in 'n' langauges depending > on what the application is... > >> What happens when I want to move >> to a new platform? > > Do you have any stats to backup that this is a widescale problem? Platform > migration is usually done in order to improve business value and as such > its not just a straight port - what would the business value be on a > straight port? > >> The tiers are now blurred into a monolithic >> structure that has to be thrown out when you scale up or down. > > You totally misunderstanding .NET. > >> You no >> longer have a "component stereo system", but have returned to the >> 1950's console unit in a very solid piece of oak furniture. > > You totally misunderstanding .NET. > > -- > Tony Rogerson > SQL Server MVP > http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a > SQL Server Consultant > http://sqlserverfaq.com - free video tutorials > > > "--CELKO--" <jcelko***@earthlink.net> wrote in message > news:1156689798.846926.176820@b28g2000cwb.googlegroups.com... >>>> : Is the CLR feature proving it self a better performance alternative >>>> to application level processing on any level? << >> >> Whart CLR does in practice is let non-SQL programmers continue to avoid >> learning declarative programming and RDBMS. The guy that was spooling >> rows to temp tables (aka scratch tapes) to use cursors in loops (aka >> 1950's sequential file programming) can do without learning T-SQL >> kludges now. >> >> CLR shifts the burden of maintaining (n) different languages to the DBA >> and/or maintenance programmers. Oh, did I mention that those languages >> all have slightly different semantics to go along with the very >> different syntax? Look at Boolean values in C# and VB -- two >> proprietary languages from the same vendor! Or look at the MOD() >> function in the X3J languages. String comparison rules in Xbase, >> COBOL, etc. Temporal expressions that exist only in SQL.. The list >> goes on and on. >> >> In theory it is even worse. Why did we spend decades arriving at >> tiered architectures and verifiable software engineering prinicples to >> throw them away? With (n) different rules embedded in the DB, I cannot >> have any consistent data over time. What happens when I want to move >> to a new platform? The tiers are now blurred into a monolithic >> structure that has to be thrown out when you scale up or down. You no >> longer have a "component stereo system", but have returned to the >> 1950's console unit in a very solid piece of oak furniture. >> >> Decades ago, Dijkstra made a remark about how we keep repeating the >> same errors over and over in IT; he was right. >> > >  |
|||||||||||||||||||||||
Other interesting topics