|
Posted by William Stacey [MVP] on 06/03/05 16:17
> I agree with what you've said. But it opens the door for them to do
> what they have generally been precluded from doing before: Design
> tables, views, etc. It blurs the line. And having seen schemas
> designed by Java developers I tremble in fear at what the VB crowd
> might be capable of doing.
- Not a VB programmer, but if I was, would be offended by that statement.
You seem to have some issue with VB.
- VB/C#/Managed C++/J# Hello World app reduces to ~same IL and binary. The
language does not matter.
- If you take VB and C#/C++ crowd out of the picture, who is writing the
applications?
- You still can't design tables/views in VB or C#, you need DDL or a Tool
(SSMS or VS). CLR does not change this.
- CLR integration does not magically allow them to do crazy things. They
still need to use SQLClient inside the DB to submit SQL statements, which
they have been able to do for a long time anyway - so this does not change.
- Your client base (i.e. programmers) does not change just because of CLR
integration. If you have 100 programmers yesterday, having SqlClr does not
mean your going to have 200 VB programmers tomorrow. Besides you still need
to have controls in-place as always. Your not going to let anyone code
against your DB anyway.
- TSQL has been improved and is not going away any time soon.
- What they do get is another tool in the box to improve productivity for
*certain procs/functions. Most procs/functions will still be in TSQL.
- When working in both, the gap is very noticeable when working in TSQL
without strong typing, intellisense, etc. Anything they can do to add
typing and compile time checks can only improve things IMO. Typing and
overloaded procs/functions would be a good start.
--
William Stacey [MVP]
Navigation:
[Reply to this message]
|