February 3, 2009 at 9:11 am
Nah. He's just recursive. Not hierarchical. One's a potential subset of the other.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
February 3, 2009 at 12:34 pm
GSquared (2/3/2009)
Nah. He's just recursive. Not hierarchical. One's a potential subset of the other.
[font="Verdana"]Ah, so he's a "common table expression"? In which case, he's also useful in SQL Server 2005.[/font]
February 4, 2009 at 8:09 am
Jeff's more of an uncommon table expression...
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
February 4, 2009 at 7:33 pm
Bruce W Cassidy (2/2/2009)
Are you the reason they put hierarchies into SQL? So you could quote yourself? Self-referential and all that... :cool:[/font]
BWAA-HAAA!! Think of it this way... it's the only time I've put RBAR into production! 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2009 at 7:01 am
Gift Peddie (1/18/2009)
...Access and VFP are things Microsoft sells as database both are not relational.
Heh? Access is relational.
As would seem apparent by other people's posts, I also started off with Access. It's power came from linked tables and client-server environment that could be set-up using linked ODBC tables, pass-through queries (took me a while to get my head around those) and of course the (then) blunt tool of VBA, DAO\ADO and ActiveX. This was all meant to cater for small offices (think we got away with around 14 continual users).
However, ADP to SQL Server, OLE and ODBC back-ends brought around a minor revolution, having said that, it didn't make transactions and locking of client-side recordsets any easier...
I bit the bullet several years ago and decided to do the 9i OCA and OCP certifications (only wrote the OCA) but was probably well set in my ways by then as I couldn't understand why Oracle DBA's got so excited by manually being able to grow the size of table segments. Obviously I hadn't been in any circumstances where I had seen that raw power brought to bear but I'm still happily ploughing forth in SQL Server and quite grateful for it now with the advances in BI. Now all I need to do is rid myself of that pesky Oracle support...
Max
February 5, 2009 at 7:26 am
Heh? Access is relational
You starting in it does not make it relational starting with the data types, aggregate functions and DRI trigger wizard which is actually invalid in all RDBMS. The most important it comes without the third part of the relational model DCL(data control language.)
Kind regards,
Gift Peddie
February 5, 2009 at 7:29 am
Max (2/5/2009)
Gift Peddie (1/18/2009)
...Access and VFP are things Microsoft sells as database both are not relational.Heh? Access is relational.
No Microsoft Access is an application development tool.
Jet/ACE is a software component that is installed along with Access and other programs. The Jet/ACE engine is really a file sharing program that operates over the file system although from the user point of view it does exhibit certain features of a DBMS.
Jet/ACE is based on the SQL model rather than the relational model. The SQL model imitates the relational one in some respects but it lacks fundamental aspects and adds lots of things that are alien to the relational model proper (tuple multi-sets instead of sets, no relvar support, no relation assignment or comparison, no key inheritance, three-value logic, etc).
February 5, 2009 at 7:40 am
Gift Peddie (2/5/2009)The most important it comes without the third part of the relational model DCL(data control language.)
Not sure what you are getting at there. DCL has nothing to do with the relational model. It is part of the ANSI/ISO SQL Standard which was developed independently (much later) to any work on the relational model. The SQL Standard does not claim to be relational and can't sensibly be used as a benchmark of what is or is not relational.
February 5, 2009 at 7:52 am
On that note all RDBMS are not relational so when you develop the relational DBMS let me know so I can test drive it.
Kind regards,
Gift Peddie
February 5, 2009 at 8:14 am
This seems like a pretty old programming argument with a bit of a different technology. The terms "relational" and "RDBMS" can be loosly or tightly defined. So, it is pretty useless to argue whether a database engine is relational.
By some definitions, none are. By some definitions, XML is.
There used to be lots of arguments about programming languages like this. I heard lots of people say VB6 was not a programming language because it did not support inheritance. SmallTalk is the only Object-Oriented programming language (well, the only one I can think of right now) because every other programming language allows some degree of non-OO programming. Drawing a line in the sand doesn't do much good unless everyone actually agrees where the line should be.
This is all symantics and you really do your arguments a dis-service by going in this direction with your discussion. It's the programming version of name-calling.
February 5, 2009 at 8:52 am
Michael Earl (2/5/2009)This is all symantics and you really do your arguments a dis-service by going in this direction with your discussion. It's the programming version of name-calling.
It's a much more important and practical issue than that. The term "relational" (unlike "Object Oriented") has a very precise and well-defined meaning founded in mathematics and computer science. Relational DBMSs have different features and characteristics from SQL DBMSs. SQL databases have different types of problems and use different solutions to the relational ones. Furthermore, the SQL terminology and relational terminology are quite incompatible - sometimes using the same names for slightly different concepts.
The ISO and ANSI agree which is why the SQL standard doesn't contain the words "relation" or "relational". So unless you are wedded to the marketing departments at Oracle or Microsoft there are good reasons of accuracy, understanding and terminology for distinguishing between the Relational model and the SQL one. If we call SQL "relational" then what are we supposed to call the things that truly are relational?
I think it was worth clarifying Gift's remarks a bit but I'm not trying to argue with her or anyone else.
Gift Peddie (2/5/2009)
On that note all RDBMS are not relational so when you develop the relational DBMS let me know so I can test drive it.
There are quite a few to choose from these days. Try out Rel. It's really cool and easy to get started:
February 5, 2009 at 9:16 am
The Berkley DB (which is what Rel is based on) is not relational. It stores data as key-value pairs without relations. Yes, Rel may be "relational", but it's built on a non-relational engine and is essentially just a mapping/communication layer on top of that.
"SQL databases" don't really exist, per se. SQL is a language for communicating with a database, and isn't the database itself, any more than the data-connection layer of an application is the database.
Per basic relational theory, a "relation" is a set of tuples. In mathematics, and original relational database definition, tuples are ordered sets of attribute values, though later this was modified to unordered sets of name-value attributes in relational definitions.
Any database, therefor, that complies with storing data in related sets of tuples, is fundamentally relational in nature.
Where these deviate is where the theory gets into specifics beyond that point, and any scientist understands that theory and application are not the same thing.
So, the point of discussion then becomes how to define relational. Till that is universally agreed upon, there's no point to making absolute statements that something is or is not relational. Too many of the arguments about whether something is relational or not come down to quoting authority, which any student of logic recognizes is a falacy and should be avoided.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
February 5, 2009 at 9:24 am
(Chris Date, and others, have done a uniform language which can handle network data model, hierarchical data model, relational data model.)
The above is from the missing Jim Grey's last published interview in the link below so David is correct to an extent. And Chris Date tells you in his last published book the aggregates are created for scalar value but SELECT returns a table in reference to the algebraic flaw of the SQL SELECT statement. The Jim Grey interviews covers most relevant facts on the subject why DCL was added, stored procedures and other things used to solve business problems and he also covered E.F. Codd's database was read only and none updatable.
So the link David posted is also not relational because it did not cover relational data model of the Chris Date's theory. A software development platform must change and grow with business needs or it becomes obsolete Small Talk is an example.
http://www.ddj.com/database/197003537;jsessionid=QLRUFCKXV21SOQSNDLPCKH0CJUNN2JVN?pgno=5
Kind regards,
Gift Peddie
February 5, 2009 at 9:30 am
GSquared (2/5/2009)
The Berkley DB (which is what Rel is based on) is not relational. It stores data as key-value pairs without relations. Yes, Rel may be "relational", but it's built on a non-relational engine and is essentially just a mapping/communication layer on top of that.
An RDBMS is a mapping between a logical representation and physical storage. That was Codd's principle goal in inventing it. It makes no difference what the underlying storage engine is.
Per basic relational theory, a "relation" is a set of tuples. In mathematics, and original relational database definition, tuples are ordered sets of attribute values, though later this was modified to unordered sets of name-value attributes in relational definitions.
Any database, therefor, that complies with storing data in related sets of tuples, is fundamentally relational in nature.
Exactly so. And that's not the model used by any SQL DBMS. SQL uses a table, view and "table expression" model rather than one based on relations. SQL tables, views and table expressions are tuple bags, not sets. They don't always have keys (you can't actually have a key on a view in standard SQL). They don't always use relational operations like projection or join. They may be column-ordered or have duplicate or un-named columns, nulls and so on.
February 5, 2009 at 9:36 am
Gift Peddie (2/5/2009)
(Chris Date, and others, have done a uniform language which can handle network data model, hierarchical data model, relational data model.)So the link David posted is also not relational because it did not cover relational data model of the Chris Date's theory.http://www.ddj.com/database/197003537;jsessionid=QLRUFCKXV21SOQSNDLPCKH0CJUNN2JVN?pgno=5
I don't understand which parts of "Chris Date's theory" (I assume you mean "D") you think Rel doesn't implement. It implements all of the D prescription elements, including RVAs. The only fundamental thing lacking at the moment is possrep type support. Other relational systems perhaps have more mature implementations of the Third Manifesto ideas but Rel is very simple and easy to install and use. Why do you think it isn't relational?
Viewing 15 posts - 106 through 120 (of 250 total)
You must be logged in to reply to this topic. Login to reply