Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


The T-SQL Paradigm


The T-SQL Paradigm

Author
Message
Steve Jones
Steve Jones
SSC-Forever
SSC-Forever (41K reputation)SSC-Forever (41K reputation)SSC-Forever (41K reputation)SSC-Forever (41K reputation)SSC-Forever (41K reputation)SSC-Forever (41K reputation)SSC-Forever (41K reputation)SSC-Forever (41K reputation)

Group: Administrators
Points: 41722 Visits: 18876
Comments posted to this topic are about the item The T-SQL Paradigm

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Michael Valentine Jones
Michael Valentine Jones
Hall of Fame
Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)

Group: General Forum Members
Points: 3900 Visits: 11771
I think that SQL as a language is not really the problem. There are a lot of developers out there that really don’t do well in any language, but the quality of their work is more exposed in SQL where performance and accuracy is more of an issue.

The number one problem that most developers have when working with SQL Server is not using the language, but developing a schema that models the data accurately and completely. Deficiencies in the design of the data are much harder to fix once they make it into a production environment, and they make it hard for developers to write fast, efficient queries to get the data they need. At the same time, many developers seem unaware of the long term implications of bad logical and physical designs, so the most important aspect of database development gets the least amount of attention. Bad design leads to developers spending a lot of time trying to stand SQL on its head to do things it shouldn’t have to do with a well designed schema.

I remember a conversation with a developer where I questioned the fact that he used inappropriate data types and that none of his tables had a primary key. He dismissed this saying that he was designing for the “real world”, and couldn’t be bothered with things were of only “theoretical interest”.
DPhillips-731960
DPhillips-731960
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1178 Visits: 801
I concur with the previous post, and would also add that the IDE's for T-SQL or SQL in general could do with a lot more features.

SQL is still largely invented by the practitioner, instead of the science.
Frank Reterink
Frank Reterink
Forum Newbie
Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)

Group: General Forum Members
Points: 1 Visits: 14
I don't think T-SQL or SQL is a bad language. Knowing how to write SQl doen't mean understanding what it means to write correct SQL. Most developers don't think of collections when trying to solve a question to the database. When jou think of collections you're able to write fast performing set-based queries.
EdVassie
EdVassie
Hall of Fame
Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)

Group: General Forum Members
Points: 3746 Visits: 3829
I agree with Michael.

In the early days of databases, IMS got man to the moon in a hierachical fashion. IMS is still around and scales to any size you want and is fast. However, like any hierarchical/OO DBMS, in order to get good performance you need to plan your access paths in advance.

Relational databases were seen as a scientific answer to the problems of a hierachical database. The wonderful strength of a RDBMS is that you specify the set of data you want, and the RDBMS optimizer uses set-based mathematics to decide how to get it. This means your request can be sliced and diced to exploit parallelism, with the certainty the (barring bugs) the required result set can be assmbled from the various parallel streams. It also means that as business requirements change, the DBA can often respond by adding new indexes, re-partioning the data, etc, to give good performance to the business but without needing legacy applications to be re-written.

As most technology moves in circles, people are now looking again at HDBMS. XML is inherently hierachical in nature, likewise objects. IMHO we are in a temporary position for a few years where people want to exploit XML but were not born when the original move from HDBMS to RDBMS was made and do not understand the reasons for the move. Theer is a perceived simplicity in aligning the data store with the object definition that people want to exploit. They can 'prove' that it is performant by putting a few hundred or thousand rows into it, and as the systems being built are often version 1 applications thare is little legacy of old design decisions that are no longer appropriate to the business.

Give things a few years, and the dead weight of legacy applications that treated the data store more or less as a flat file, and 100-fold increase in data volumes and the problems of a HDBMS will be learned all over again. The mathematical basis of RDBMS will again be valued, and IT professionals will have a new time of plenty as XML-based databases get moved into a RDBMS so that the business can grow in the way it wants.

Original author: SQL Server FineBuild 1-click install and best practice configuration of SQL Server 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005. 1 Dec 2016: now over 39,000 downloads.
Disclaimer: All information provided is a personal opinion that may not match reality.
Quote: "When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist." - Archbishop Hélder Câmara
majorbloodnock
majorbloodnock
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1171 Visits: 3062
I think it's all too easy to forget that SQL is an agreed standard, and a very efficient tool for carrying out the work for which it was designed.

Applications often need to talk with databases; that's a fact of life. If a company decides to switch database vendors, how much application rewriting is required? Or developer retraining? OK, T-SQL is a diferent dialect to PL-SQL, but they're still both based closely on a standard, so movement between dialects is hardly rocket science.

We're always going to have a VHS vs Betamax argument about technical tools, with proponents of various languages/applications/databases/hardware/operating systems and so on justifying their preferences. Undoubtedly, plenty of those justifications are based on sound technical evidence, but they don't automatically make all the alternatives invalid. SQL, and all its related dialects, do their job very well. At that point, whether or not it is strange is irrelevant.

Semper in excretia, sumus solum profundum variat
kevriley
kevriley
SSCrazy
SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)

Group: General Forum Members
Points: 2807 Visits: 2606
I agree with Michael, it's not that SQL is difficult, in fact I think T-SQL is quite easy, it's making it perform that can be seen as difficult, and that boils down to underlying design and an ability to think in sets.


I don't do application development, so I would find C#, .Net, HTML 'difficult' because I don't know them. And as such I wouldn't try to develop anything in those languages. But your average developer has probably touched upon SQL in either college or some sort of dev training, so they think they can code in it. The real-world is also full of companies where there is no DBA, and the database work falls upon the developer with the most SQL experience, so what do you expect! Imagine an website designed and implemented by DBAs!


As a DBA I've been fortunate to work with a number of developers who understand their own limitations. Sure they can write simple queries, but when it comes down to more complex stuff, they leave it to the database devs or DBAs. And they certainly steer clear of database design. They also understand the limitations of so-called 'silver bullet solutions' like ORM and LINQ to SQL. It's when you meet or hear of developers who want to be able to do it all in their 'paradigm' that you get these 'fun' debates.

Is there a better way to build a query language? Probably.
Is it going to be easy? Probably not.

Theres got to be something in the fact that application development languages churn over at a rate of knots - they look nothing like they did 10, 15, 20 years ago - but SQL has remained relatively stable.

Attempts have been made to make it easier for developers to code against databases, the latest failure being LINQ to SQL, so lets just accept that trying to make set-based querying fit the OO or procedural model, whilst it can be implemented, never really works.




Kev
kevriley
kevriley
SSCrazy
SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)

Group: General Forum Members
Points: 2807 Visits: 2606
dphillips (4/3/2009)
I concur with the previous post, and would also add that the IDE's for T-SQL or SQL in general could do with a lot more features.


dphillips, like what?


Kev
vgermscheid
vgermscheid
Grasshopper
Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)

Group: General Forum Members
Points: 15 Visits: 258
For a domain specific language, in this case the domain being data management, T-Sql gets the job done. Having worked with both it (in MS and Sybase) as well as weith Oracle's PL/SQL, it has feature level advantages as well as disadvantages, but I've not found it lacking unless you're trying to build the entire application within stored procs.

I think those who say that it's missing features are using it in places where C# or others should play a stronger part. In this case you shoud be building application components or .NET assemblies (XP's in earlier SQL Server releases) that can extend the funcitonality of the lowly stored procs.

In other words, T-SQL is a usefull tool, but it's not a hammer and the worlds not a nail. :-)
bob.sargent@gmail.com
bob.sargent@gmail.com
Forum Newbie
Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)

Group: General Forum Members
Points: 6 Visits: 38
Opinion from a developer. Okay, an OLD developer.

I've been working with different query languages for quite a number of years starting with the dot prompt in dBase II. (I did say I'm old, didn't I?) I started learning T-SQL in MSSQL 6.5 and haven't looked back since. I think Microsoft has done a heck of a job with MSSQL. My experience with the "average" developer is they "haven't the time" to learn T-SQL and all it can do for them.

As for myself, I'm a c# programmer along with a number of other languages. When it comes to extracting data from a database, I've tried all the latest and greatest including Linq, managed code for MSSQL, various IDEs for SQL development, and ultimately end up back in the current iteration of a query analyzer writing my queries, functions, and procs by hand.

Shortcuts just for the sake of getting a job done faster are mostly detrimental to the overall effort. Learn the language. Apply it to some real-world examples. Hopefully you'll come to appreciate it.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search