November 18, 2009 at 3:21 pm
David Portas (11/18/2009)
Leaving aside the well-known disadvantages of procedural code, a trigger is not a substitute for a constraint because it does not enforce the rule. It allows the data to get into an invalid, inconsistent state and then corrects it.
In a trigger or DRI if the rule is violated the data update isn't made so no invalid state.
I am going to offer this little piece of advice, you keep mentioning "well-known disadvantages" but only highlight what are relatively minor issues. So instead of using that statement as crutch, prove it to us.
When SQL 2005 came out a .NET developer I worked with stated that SQL CLR would kill T-SQL, I just smiled and nodded, because he was mistaken, .NET suffers from the procedural model, one-by-one-by-one operations, T-SQL is best at dealing with sets..
The advantages of declarative referential integrity over procedural code are pretty well known I think. Significantly, declarative code is available to the optimiser for optimising other queries and performing query rewrites. Procedural code cannot do that. "Declarative, Not Procedural" is in fact one of the guiding principles of enforcing business rules (the Business Rules Manifesto). See: http://www.brcommunity.com
So doing it declaratively is a legitimate requirement and a workaround using procedural code is not nearly equivalent.
But in reality that "procedural code" if written correctly will still not be row-by-row", so not as procedural. Maybe not equivalent but not entire off either.
GSquared (11/18/2009)
David Portas (11/18/2009)
You don't think SQL will be replaced by RDBMS? That would be a pity.
Who knows? Since there really aren't any, it's impossible to say.
There are though! They exist already and there are bigger and better ones in development. The relational model needs advocates now, not tomorrow. It doesn't benefit from discussions about the finer points of SQL because that argument is already lost. Customers are and will abandon SQL where they can even if they have to replace it with non-relational systems. That's why I think there is an important debate to be had about the future, and SQL database professionals should be leading that debate.
1. When there is a viable real-world alternative, even in open-source, you are likely to have a better discussion. As long as there is nothing really usable or it is largely vapor-ware then advocating for it is questionable (IMO).
2. I don't care about the technologies "NEEDS", I care about having the tools to solve real-world problems.
3. "It doesn't benefit from discussions about the finer points of SQL because that argument is already lost." Arguable, sure, not a very strong argument but an argument none-the-less.
4. "That's why I think there is an important debate to be had about the future," In the future yes, until there is something readily usuable to solve real-world problems then it could be the best idea EVER, but it wouldn't get the attention it wants. We are debating what is really an idea, that has marginal substance and very little (if any) usable tools to really test it out with real-world problems.
5. Database professionals should lead a debate in what should be done about identifed issues, even if that means paradigm shift, but I'm not going to argue for or against a technology that isn't ripe for that debate, and in my view, this technology falls into that category. Maybe in the future as the technology grows and matures I could change my mind.
I realize that you believe that this is the best thing since sliced bread, and I'm not saying you are wrong, but a nice idea without a way to really use it and test it in a meaningful way is just that, a nice idea. Maybe when there is a fairly good set of tools, this discussion could continue but I don't care to discuss theory any further.
CEWII
November 18, 2009 at 4:21 pm
Not only that, even when the next best thing since sliced bread does arrive, SQL isn't going to go away over night. Want proof, look at COBOL. I can still find job openings for people with COBOL experience as there are millions of lines of COBOL code out there still doing the job that needs to be done.
January 31, 2010 at 10:21 am
Another discussion on the future of SQL started by Matt Whitfield:
http://ask.sqlservercentral.com/questions/3503/is-sql-on-the-way-out
January 31, 2010 at 11:47 am
Still don't see SQL, or its variants (T-SQL, PL-SQL, etc), going away any time soon. Just like COBOL, I see it having a long life, or at least until it doesn't matter to me any more.
March 1, 2010 at 9:18 am
David Portas (11/17/2009)
Strong typing and type inheritence
Maybe..
Every other major programming language benefits from strong typing. No C++, Java or C# developer I know of would dream of doing without it. Yet SQL's type system is still in the stone age.
If you think anything in C++ would be useful I have to disagree with you completely. C++ managed to get encapsulation so completely wrong that it had to invent "friends", it has no concept of existential types, and the type system for primitive objects (integers etc) is so hopeless weak as to be pretty well useless. C# isn't much better, and Java is almost as bad but in different ways. None of these languages provides existential types, so using their type systems would mean that it's impossible to provide several differnt implementations of the same type for use in situations where different data volumes or concurrency requirements or transaction rates could usefully use those different implementations.
Part of the reason that no progress is made on improving SQL (or replacing it with something better) is that the mob is following the money, which is on the abysmal imitation or an object-oriented type and class system that is provided in C++. Pointing at C++ as an example of usable strong typing that SQL might follow guarantees that no progress will be made - at least none in the right direction.
There is plenty of good literature on type systems that could be consulted to find suitable typing mechanisms for a DBMS. One good starting point is the survey paper by Luca Cardelli and Peter Wegner "On Understanding Types, Data Abstraction, and Polymorphism" in ACM Computing Surveys Volume 17 , Issue 4 (December 1985) Pages: 471 - 523. This is pretty old - 25 years ago - stuff, but apart from academics and a few people in industry who have had to design new languages pretty well no-one has paid any attention to it. The paper is available as PDF from Luca's website: http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf.
Or if you are interested in types only in the database context, there's maybe a better starting point: "GALILEO: a strongly-typed, interactive conceptual language" by Albano, Cardelli, and Orsini appeared in TODS (ACM Transactions on Database Systems) Volume 10 , Issue 2 (June 1985) Pages: 230 - 260 and presents a database language designed to have some useful properties. The stated aims are that
it should provide features to describe:
a. Data de?ned both declaratively, with abstraction mechanisms (aggregation, classi?cation and specialization), and procedurally (derived data).
b. Semantic integrity constraints, both standard (such as keys and mandatory values), and described by
a general purpose constraint speci?cation language.
c. Operations to give the behavioral semantics of the data in the schema.
d. The language should have a sound mathematical foundation.
and must also provide
a. A set of independent constructs to be used in any combination to achieve simplicity and expressiveness.
b. Features to design and test the solution incrementally.
c. A modularization mechanism to decompose the design into meaningful modular units that corre-
spond to a description of the database at different levels of successive re?nements, or to application
oriented views of the database.
These sound to me like good and useful aims.
That too is 25 years old (so it predates any real C++ compiler - there were only preprocessors to turn C++ into (bad) C in those days) but it describes a type and class system that is infinitely better than the one in C++ and is specifically desigbned for databases. It has, of course, been completely ignored by the database world, because it isn't SQL and also isn't fashionably object-oriented (a case could easily be made for claiming that it's more really object-oriented than C++, but lets not go there). That paper too is freely available: http://lucacardelli.name/Papers/Galileo.A4.pdf. It would be useful to hear your views on whether the type system designed there would be a good starting point for a DBMS (I don't expect you to like the whole language as it's not very D-like, but I think you might like the handling of types/classes).
Tom
March 1, 2010 at 9:34 am
David Portas (11/17/2009)
Elliott W (11/17/2009)
So in my view the three things you mention are already handled, could they be better, sure, but that doesn't support your position..Oh dear! I wasn't very clear maybe. My point was that duplicate rows, type coercian and three-value logic DO all exist in SQL. They are fundamental to the way SQL works but they are three major flaws that should be got rid of. I think the problems they cause are pretty well-known and extensively covered in textbooks.
I thought you were very clear, I don't know how Elliot read it the way he did. I also thought you were very wrong. Some form of type coercion is needed in pretty well any serious language - read Kernigan's critique of Pascal if you don't understand why. Ideally it needs a specific coercion operator (SQL has this: CAST) except where literal expressions are overloaded (I shouldn't need to cast N'abc' as varchar(7) if it occurs in a context where a value of type varchar(7) is needed) but that can be relaxed a bit (perhaps even more than it is in SQL) in the interest of avoiding verbosity. three-valued logic is bad only because it is not 4-valued or 5-valued or 6-valued (we need to know when we don't have a value for something, and it's nice to know also whether it's an "I don't care" or an "I don't know" or an "A value was provided but was out of range". I do agree with you on duplicate rows: but in a relational model with projections eliminating duplicates requires a lot of sorts, which might have an unpleasant performance impact.
Tom
March 1, 2010 at 11:41 am
Lynn Pettis (1/31/2010)
Still don't see SQL, or its variants (T-SQL, PL-SQL, etc), going away any time soon. Just like COBOL, I see it having a long life, or at least until it doesn't matter to me any more.
I agree completely - SQL will be around for a long time.
Fortran has been around for 56 years (so a bit longer tthan Cobol) and is still the language of choice in some application areas; it has evolved enormously over the decades.
SQL hasn't been aroung as long, but it too is evolving. 25 years ago when I inculded the ability to handle recursive queries in the requirement for the (functional set-oriented) data handling language for Flagship and it got implemented successfully and efficiently it was new and revolutionary; a couple of years later when we got it into ESQL it was still revolutionary(http://hal.inria.fr/docs/00/07/53/73/PDF/RR-1185.pdf - it's not the best paper, but it's available on-line). All attempts to get it into the SQL2 standard (which was eventually called something different) failed - it was too new, too different. Today we have recursive CTEs, no problem - that's evolution. Evolution is a sure sign that the language will live on for quite some time, so I don't see SQL disappearing in the next 50 years - but it will continue to evolve.
There will be hard engineering decisions to be taken: should we automatically clean up all projections to eliminate duplicates? That would certainly improve the language no end at the conceptual level: every result set, every table, every CTE would be a set instead of a bag. But it would not be pretty at the practical performance level. Some people (the "purists", let's call them) will want to be rid of those nasty duplicates. Others (the "one track and it's performance minded") will say you can't afford to do that. Which was will the argument go? Who knows?
I think we need to improve the type system, and include abstract types and existential types (perhaps modules). We need proper transaction nesting. I think we need to improve the constraint system, for example to add existence constraints and aggregate constraints. I think we need to look at DML syntax, which is pretty bizarre in places. We need support for unification (in the logic programming sense) and for resolution of constraint systems (in the logic constraint programming sense, as opposed to the DDL constraints sense). All these things (and many more) will lead to evolution but none of them will mean the end of SQL unless the infuential stick-in-the muds who have so effectively delayed evolution in the SQL standard in the past become so successful that the only way of getting a decent system is to give SQL up and break away.
I would like to see the language taking a more functional (in the declarative functional programming sense) view instead of its current very procedural view, perhaps with transactions in some sense corresponding to Haskell's monads. (Note: you can talk about sets declaratively, as in Prolog without cut or in Haskell, or you can talk about them procedurally, as in SQL; set-oriented contrasts with element-oriented not with procedural, and it is a source of irritation that so many SQL-ers claim the language is not procedural just because it is set oriented.) That would of course be a very big jump for SQL, so I don't think it will happen soon but I do hope (not expec, unfortunately) I live to see it.
Tom
Viewing 7 posts - 31 through 36 (of 36 total)
You must be logged in to reply to this topic. Login to reply