|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Anything better than TSQL?it is a phenomenal data query language. However, in my view, it may be a little too much so, because with all of its control constructs and additions to SQL92, it almost gives the appearance of and certainly gives the opportunity to be used as a general purpose programming language. However, as a programming language, it is not very good at all. Although it is certainly capable of doing most any general purpose task (and almost certainly turing complete), it is decades behind any major language today (again, I speak regarding its consideration as a general purpose programming language). Now to the question. Recently, I've been doing a good deal of business logic that, for legacy and practical reasons is implemented in TSQL. Is there a way to use a more capable language in perhaps another layer atop SQL Server while still retaining the local access to all of the database contents? Maybe embedded TSQL in C# or vice versa? I know that such a thing is considered unneccessary, and that the standard response would probably be 'redesign your database' or 'build some middleware thing', but out of curiosity I have to ask if there is another option. Thanks for your input, Kyle SQL Server 2005 does exactly what you want. Too bad it's still in beta.
Show quote "Kyle" <K***@discussions.microsoft.com> wrote in message news:F04F95F9-EFCE-4300-BD3F-8ED1A82D3016@microsoft.com... > Recently I've been doing a good amount TSQL programming, and I think > it is a phenomenal data query language. However, in my view, it may be a > little too much so, because with all of its control constructs and additions > to SQL92, it almost gives the appearance of and certainly gives the > opportunity to be used as a general purpose programming language. However, as > a programming language, it is not very good at all. Although it is certainly > capable of doing most any general purpose task (and almost certainly turing > complete), it is decades behind any major language today (again, I speak > regarding its consideration as a general purpose programming language). > > Now to the question. > Recently, I've been doing a good deal of business logic that, for legacy and > practical reasons is implemented in TSQL. > Is there a way to use a more capable language in perhaps another layer atop > SQL Server while still retaining the local access to all of the database > contents? > Maybe embedded TSQL in C# or vice versa? > I know that such a thing is considered unneccessary, and that > the standard response would probably be 'redesign your database' or > 'build some middleware thing', but out of curiosity I have to ask if there > is another option. > > Thanks for your input, > > Kyle T-SQL is a simple one-pass compiler that was not meant for application
development. The original "rule of thumb" was never write a proc over one page (50 lines) long. You can embed SQL into any of the ANSI X3J languages, but we also have the SQL/PSM Standard if you want a language designed to be used with SQL. you can build COM components and use them within TSQL using sp_OACreate which
is maybe what you could look into. You could also create extended stored procedures written in C, C++ although these run in the same address space as SQL Server so a crash inside one of these procedures can bring down the server. This fact alone usually makes my choice simple - create COM objects in VB and most of the programming world will understand it and because it will run in a seperate address space to SQL Server - the component won't bring down the server. regards, Mark Baekdal http://www.dbghost.com http://www.innovartis.co.uk +44 (0)208 241 1762 Build, Comparison and Synchronization from Source Control = Database change management for SQL Server Show quote "Kyle" wrote: > Recently I've been doing a good amount TSQL programming, and I think > it is a phenomenal data query language. However, in my view, it may be a > little too much so, because with all of its control constructs and additions > to SQL92, it almost gives the appearance of and certainly gives the > opportunity to be used as a general purpose programming language. However, as > a programming language, it is not very good at all. Although it is certainly > capable of doing most any general purpose task (and almost certainly turing > complete), it is decades behind any major language today (again, I speak > regarding its consideration as a general purpose programming language). > > Now to the question. > Recently, I've been doing a good deal of business logic that, for legacy and > practical reasons is implemented in TSQL. > Is there a way to use a more capable language in perhaps another layer atop > SQL Server while still retaining the local access to all of the database > contents? > Maybe embedded TSQL in C# or vice versa? > I know that such a thing is considered unneccessary, and that > the standard response would probably be 'redesign your database' or > 'build some middleware thing', but out of curiosity I have to ask if there > is another option. > > Thanks for your input, > > Kyle I would shy away from using COM components in SQL. My experience using them is
that they are slow and can cause problems if designed to be free-threaded instead of single threaded apartment. For now, your best bet is to continue using T-SQL or... SQL 2005 will really provide what you want. It will allow for procedures in C# (or VB.NET) inside of SQL Server. Microsoft has announced the release of SQL 2005 on November 9th this year. Thomas Show quote "Kyle" <K***@discussions.microsoft.com> wrote in message news:F04F95F9-EFCE-4300-BD3F-8ED1A82D3016@microsoft.com... > Recently I've been doing a good amount TSQL programming, and I think > it is a phenomenal data query language. However, in my view, it may be a > little too much so, because with all of its control constructs and additions > to SQL92, it almost gives the appearance of and certainly gives the > opportunity to be used as a general purpose programming language. However, as > a programming language, it is not very good at all. Although it is certainly > capable of doing most any general purpose task (and almost certainly turing > complete), it is decades behind any major language today (again, I speak > regarding its consideration as a general purpose programming language). > > Now to the question. > Recently, I've been doing a good deal of business logic that, for legacy and > practical reasons is implemented in TSQL. > Is there a way to use a more capable language in perhaps another layer atop > SQL Server while still retaining the local access to all of the database > contents? > Maybe embedded TSQL in C# or vice versa? > I know that such a thing is considered unneccessary, and that > the standard response would probably be 'redesign your database' or > 'build some middleware thing', but out of curiosity I have to ask if there > is another option. > > Thanks for your input, > > Kyle And in the real world people have to deal the situation at hand - keep it
real - we all want the budget for the next best technology but we need to deal with the present in a realistic manner. 2005 is still not available which is useless to people who need to deal with the present production systems, be helpful not ignorant of the situation at hand. Can the problem wait? Does the problem need a solution currently available? Simple questions that ultimately will give you the path you need to follow. when waiting is the best option it means you have to wait - your business can wait? when you need a solution - get it, make it work if it fits and the business requires the function. regards, Mark Baekdal http://www.dbghost.com http://www.innovartis.co.uk +44 (0)208 241 1762 Build, Comparison and Synchronization from Source Control = Database change management for SQL Server regards, Mark Baekdal http://www.dbghost.com http://www.innovartis.co.uk +44 (0)208 241 1762 Build, Comparison and Synchronization from Source Control = Database change management for SQL Server Show quote "Thomas Coleman" wrote: > I would shy away from using COM components in SQL. My experience using them is > that they are slow and can cause problems if designed to be free-threaded > instead of single threaded apartment. For now, your best bet is to continue > using T-SQL or... > > SQL 2005 will really provide what you want. It will allow for procedures in C# > (or VB.NET) inside of SQL Server. Microsoft has announced the release of SQL > 2005 on November 9th this year. > > > Thomas > > > > "Kyle" <K***@discussions.microsoft.com> wrote in message > news:F04F95F9-EFCE-4300-BD3F-8ED1A82D3016@microsoft.com... > > Recently I've been doing a good amount TSQL programming, and I think > > it is a phenomenal data query language. However, in my view, it may be a > > little too much so, because with all of its control constructs and additions > > to SQL92, it almost gives the appearance of and certainly gives the > > opportunity to be used as a general purpose programming language. However, as > > a programming language, it is not very good at all. Although it is certainly > > capable of doing most any general purpose task (and almost certainly turing > > complete), it is decades behind any major language today (again, I speak > > regarding its consideration as a general purpose programming language). > > > > Now to the question. > > Recently, I've been doing a good deal of business logic that, for legacy and > > practical reasons is implemented in TSQL. > > Is there a way to use a more capable language in perhaps another layer atop > > SQL Server while still retaining the local access to all of the database > > contents? > > Maybe embedded TSQL in C# or vice versa? > > I know that such a thing is considered unneccessary, and that > > the standard response would probably be 'redesign your database' or > > 'build some middleware thing', but out of curiosity I have to ask if there > > is another option. > > > > Thanks for your input, > > > > Kyle > > > There are other solutions than using a COM component in SQL. For example, you
could call the COM component directly. You could use a Web Service etc. Further, 2005 IS a viable option given that you can get a Go Live license. Both of those options are better, IMO, than calling a COM component through T-SQL. I would put COM components called through T-SQL at the bottom of my list of choices. There are far better solutions available. > when you need a solution - get it, make it work if it fits and the business That's fine to a point. The problem comes when that "temporary" solution becomes > requires the function. a permanent solution. Correcting problems caused by this scenario can be a far bigger headache than doing it right the first time. Thomas Show quote "mark baekdal" <markbaek***@discussions.microsoft.com> wrote in message news:0572C462-09E9-48D1-A4BB-A19D9BCA3599@microsoft.com... > And in the real world people have to deal the situation at hand - keep it > real - we all want the budget for the next best technology but we need to > deal with the present in a realistic manner. 2005 is still not available > which is useless to people who need to deal with the present production > systems, be helpful not ignorant of the situation at hand. Can the problem > wait? Does the problem need a solution currently available? > Simple questions that ultimately will give you the path you need to follow. > > when waiting is the best option it means you have to wait - your business > can wait? > > when you need a solution - get it, make it work if it fits and the business > requires the function. > > > regards, > Mark Baekdal > http://www.dbghost.com > http://www.innovartis.co.uk > +44 (0)208 241 1762 > Build, Comparison and Synchronization from Source Control = Database change > management for SQL Server  |
|||||||||||||||||||||||
Other interesting topics