Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Relational Model Advantages Expand / Collapse
Author
Message
Posted Monday, December 7, 2009 6:20 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:27 AM
Points: 35,770, Visits: 32,437
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #829786
Posted Monday, December 7, 2009 7:17 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Wednesday, December 10, 2014 2:32 AM
Points: 451, Visits: 3,470
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.


David
Post #829837
Posted Monday, December 7, 2009 9:56 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:27 AM
Points: 35,770, Visits: 32,437
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #830034
Posted Saturday, December 12, 2009 10:39 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Today @ 7:14 AM
Points: 546, Visits: 2,148
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.
Post #833376
Posted Sunday, April 4, 2010 8:57 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 5:50 PM
Points: 7,923, Visits: 9,649
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
Post #896416
Posted Sunday, April 4, 2010 9:55 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Tuesday, January 28, 2014 8:15 AM
Points: 3,065, Visits: 4,639
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.


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.
Post #896426
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse