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


Relational Model Advantages


Relational Model Advantages

Author
Message
Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)

Group: General Forum Members
Points: 45079 Visits: 39910
Which group of customers is having the most influence on the future direction of database systems right now?


Heh... apparently, the wrong ones... look at what they did to Office 2007 and look at all the good features they removed between SQL Server 2000 and 2005.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
sqlvogel
sqlvogel
SSC-Addicted
SSC-Addicted (484 reputation)SSC-Addicted (484 reputation)SSC-Addicted (484 reputation)SSC-Addicted (484 reputation)SSC-Addicted (484 reputation)SSC-Addicted (484 reputation)SSC-Addicted (484 reputation)SSC-Addicted (484 reputation)

Group: General Forum Members
Points: 484 Visits: 3706
Jeff Moden (12/6/2009)
SQL Server and all relational databases aren't much more than glorified file handlers.

And OO languages are just syntactic sugar! After all, everything can be done with machine code! ;-)

Tables are really nothing more than files with lines (rows) and fields (columns)

Tables are nothing of the kind! A file is a one dimensional stream of bytes. Rows and columns are just two dimensions. Relational tables on the other hand may have any number of dimensions. Data values in a relation cannot be accessed by row or column indices like a spreadsheet. I think that's a pretty important and fundamental distinction for most people.
Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)

Group: General Forum Members
Points: 45079 Visits: 39910
Actually, with a bit of fore thought, it's quite easy to build a table that can be referenced as if it were a multidemensional array. It's not a common practice and it's generally frowned on when you do, but it's easy to do.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Michael Meierruth
Michael Meierruth
SSChasing Mays
SSChasing Mays (647 reputation)SSChasing Mays (647 reputation)SSChasing Mays (647 reputation)SSChasing Mays (647 reputation)SSChasing Mays (647 reputation)SSChasing Mays (647 reputation)SSChasing Mays (647 reputation)SSChasing Mays (647 reputation)

Group: General Forum Members
Points: 647 Visits: 2507
David,

You say everything can be done with machine code.
But does machine code understand the concept of tables?
Or do you insert the concept of tables into your machine code?

And you say:

Data values in a relation cannot be accessed by row or column indices like a spreadsheet. I think that's a pretty important and fundamental distinction for most people.

Haah: so you're an Excel freak!

I personally use SQL queries together with Excel in end-user applications. The level of detail required by the end user leaves me no choice. Thus I'm sure you're familiar with VBA.

On the other hand, you have these Excel freaks who just want a plain flat file extraction and they take care of the rest with pivot tables and filters and all that Excel stuff.
TomThomson
TomThomson
SSChampion
SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)

Group: General Forum Members
Points: 10707 Visits: 12008
David Portas (11/26/2009)

3. Developer productivity. SQL is a seriously deficient language for the 21st century when compared to other languages in the object-oriented world (C++, Java or C#). SQL’s 1980’s style type support, lack of type-inheritence and lack of relation types, relation variables or relation assignment are serious omissions that certainly cost development time and effort on practically every project. Incomplete support for set-based queries and the consequent need to rely on row-by-row processing are another feature of SQL. These defects are why abstraction layers that hide SQL complexity and limitations are so popular today.

This is pure insanity. C++ is probably the most abysmal pig's breakfast of a programming language in serious use today, and comparing SQL (whatever dialect) to C++ is like comparing the crown jewels to horse dung. Maybe if we introduced pointers and pointer arithmetic and coercions between arithmetic types and pointers into SQL you would think we had improved the language? Pure insanity probably wasn't strong enough!

None of C++, Java, and C# makes a decent stab at polymorphism or at inheritance, none of them has classes as first class objects in the language which would be the OO equivalent of SQL having relation variables, so you are barking up the wrong tree there. And C++ doesn't even provide type abstraction ("friend", anyone?).
Take a few examples. The need to eliminate duplicates from queries or from tables without keys are very common requests in forums that deal with SQL problems.
The need to elimate duplicates from queries is exactly the same in relational calculus as it is in SQL - or have you decided (unilaterally - even Date wouldn't agree with you) that we can make do with a subset of relational algebra that doesn't include projection?
Assignment and comparison of tables or sets of rows are two other very frequent SQL problems. Since SQL doesn’t have any straightforward syntax for table assignment or comparison the code has to be written again and again for each new project. RDBMS doesn’t suffer from any of these problems.
SQL has extremely straightforward syntax for adding a rowset to a table, so I don't understand your problem with either table assignment or rowset assignment. It's a pity in fact that rowset and table are considered different and that this is reflected in the syntax, but that's a problem that most relational calculi suffer from too. And yes, it would be nice to have the symmetric difference operator on row sets (or tables, doesn't matter which) in SQL - it would save me a whole line of code (yes, that's one single short line of code) every time I wanted to use it (actually the asymmetric difference would be more useful, but that would mean I had to use it twice to do comparison for equality, so the code saving in the single uncommon instance you have picked would be less).
Inability to support anything other than a few basic types also causes big challenges for developers who are forced to write or duplicate code to emulate native or user-defined types in other languages.

Try supporting Haskell values or even Hope+ values in C++. How do I represent a continuation or a monad or for that matter a table with 1,000,000 rows each about 10,000 bytes long in C++ or in Java or in C# without going down to incredibly detailed low level implementation that I wouldn't have to consider in some other languages (in SQL for the last object named)?
As a very conservative estimate I think it’s not unreasonable to assume a full-time developer writing complex SQL might save 1-2 days per month by using a more full-featured relational language instead. In other words it could be a 5-10% saving on development costs.

Any evidence for this, or is your "conservative estimate" just a number plucked from the top of your head?

If I seem to be confrontational here, that's intentional - David Portas' confrontational and unsubstantiated claim about defects in SQL compared to languages like C++ which contain far more defects deserves a confrontational response.

Tom

PaulB-TheOneAndOnly
PaulB-TheOneAndOnly
Hall of Fame
Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)

Group: General Forum Members
Points: 3093 Visits: 4639
Tom.Thomson (4/4/2010)
[quote]If I seem to be confrontational here, that's intentional - David Portas' confrontational and unsubstantiated claim about defects in SQL compared to languages like C++ which contain far more defects deserves a confrontational response.


:-D you made my day Tom. By the way, I'm 100% in agreement.

_____________________________________
Pablo (Paul) Berzukov

Author of Understanding Database Administration available at Amazon and other bookstores.

Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
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