Re: complex - split string in sql - need help

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Since 80%+ of the total cost of a system is in maintaining it,
anything that makes it harder to maintain is a bad idea. Anything

That coming from the only person on here who would actually recommend and argue for passing 100's - 1000's of parameters to a stored procedure instead of using a single value CSV or table valued parameter - your comment is frankly laughable.

The rest is just ignorant and inaccurate prattle from a person unwilling to bring himself up-to-date with the current product and the realities of the current business environment and problems in it.

--ROGGIE--

"--CELKO--" <jcelko212@xxxxxxxxxxxxx> wrote in message news:bb2bec6f-f810-4a19-94f1-d2468292c62d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Look at the list of CLR languages at:

http://blogs.ugidotnet.org/nettools/articles/8060.aspx

How many of them do you program in? Hell, how many of them have you
even seen? I am old and I don't know most of them. And they missed
Algol!

Well, they are now in your database and as the DBA, you have to
maintain all of them. Do you really believe that over time no
developer will inject his favorite language into the schema; he will
sit and learn to write good SQL and start thinking in sets. Yeah.
Sure.

What I see is the developers using SQL as a file system for the
procedural language they already know. As one guy put it , "Why
should I learn Squirrel (yes, that is how he pronounced SQL) when I
can do everything in VB?" and he did not mind that his programs will
never scale. He is leaving soon to the next job and he will be
replaced by another "code monkey" who knows C#, Java or whatever the
language du jour is at the time he is hired. I am the guy that makes
his money fixing this stuff.

Quick, what is the internal representation of TRUE and FALSE in all of
those languages? The answer is +1, 0 and -1 in VB and C# -- which
are proprietary MS products. But SQL doesn't have Boolean data type
anyway. Then there are 4-5 different models for pointers; I would
have look it up. But SQL doesn't have a pointers. You can probably
make a list of "data types in CLR Language X that do not map to SQL"
yourself. So they get stuffed into Blobs or XML where you cannot use
straight SQL on them, nor can the SQL use indexes, hashing or whatever
access method it has.

In fact, even when they match an SQL data type, the conversion rules
are different -- the Standard covered only the X3J languages. Each
implementation of the non-X3J languages does not have to do the same
way. And they don't.

NULLs and indicators are another problem. SQL Server people don't
know about indicators that are part of the SQL Standard. Most of them
have never written in more than one other language family. That is
why I wrote THINKING IN SETS.

Do you remember the MOD() function debate in Pascal days? There are
3-5 ways to compute a modulus; versions of Pascal did it differently
from each other, FORTRAN disagrees with PL/I. Oracle even gives you a
warning in their documentation that they do not match the usual
mathematical definition of MOD(). The basic problem was how to handle
negative integers and decimals.

What is LOG(0.0)? Undefined? NULL? Infinity (using IEEE floats)?
Infinity (using a language specific symbol -- Centura, nee Gupta
SQL)?

In Xbase languages, string comparisons are not case sensitive and the
longer string in truncated (i.e. "smith" = "Smithsonian'), but not in
SQL which is case sensitive and the shorter string is padded with
blanks. Do you know the string rules for ALL of the languages on the
list?

Since 80%+ of the total cost of a system is in maintaining it,
anything that makes it harder to maintain is a bad idea. Anything
that makes data inconsistent is a bad idea. Anything that makes code
hard to impossible to port is a bad idea -- unless you want to plan
for failure and/or no growth. CLR does all of these things

.

Relevant Pages

  • Re: SQL
    ... The "expression engine" can be logically seperated from a relational ... query language, in theory they could without busting relational. ... They all are typed, as well as SQL. ... The only difference is "A1" (a run-time object of the type String) vs. A1 ...
    (comp.object)
  • Re: SQL
    ... The "expression engine" can be logically seperated from a relational ... query language, in theory they could without busting relational. ... They all are typed, as well as SQL. ... everything as pretty much a string. ...
    (comp.object)
  • Re: Using the catalogue
    ... >>> that field name is in, field type is String, and ... A D language assumes an open ended ... >> form of dynamic SQL as an extension - that should be up to the task. ...
    (comp.databases.theory)
  • RE: How do I change a data type using SQL?
    ... string; however, a string might not convert to a number. ... Jerry Whittle, Microsoft Access MVP ... The data type on the field throws me off. ... Need to use the SQL view. ...
    (microsoft.public.access.queries)
  • Re: Full-Text Catalog does not build...
    ... You're welcome, Oleg, ... I've not confirmed if the Arabic language will be a FTS supported ... language in SQL Server 2005, you may want to review the ...
    (microsoft.public.sqlserver.fulltext)