Slashdot Mirror
An Alternative to SQL?
Golygydd Max writes "Dave Voorhis from the University of Derbyshire has developed a program incorporating Tutorial D, a language designed to overcome of the shortcomings of SQL, and developed some years ago by Hugh Darwen and Chris Date. Until now, no-one had done anything with it but Voorhis is hoping for wider adoption; although we think it would be like pushing water uphill though." Update: 10/13 12:43 GMT by T : An anonymous reader writes "It's being picky I know, but the university in question is in fact called The University Of Derby, not Derbyshire."
Who remembers "Knowledgeman", that database language of 20 years ago which got eclipsed by dBase???
What are the shortcomings to sql? it seems to be able to handle anything you'd need it to do.
Try using Lotus Domino for a week. You'll be begging to go back to SQL.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Is there anything that SQL can't do? I've been using various RDBMS for years and it hasn't come up yet.
SQL also has decades of optimizations in reliable code...no one will be dropping their Oracle license over this.
I use SQL a lot and I agree that has failings. The clumsiness inherent in, say, nested joins is quite amazing when you consider how important databases are in modern industry. This is a consequence of the "near-English"ness that SQL strives for, but that property is also what causes people to adopt SQL in the first place. We'll probably look back at SQL in five years and laugh... but weren't people saying that five years ago?
apterous.org
so to overcome the (not really all that many) shortcomings of sql we will all learn how to use something completely new. Yeah, adoption going to be quik and complete........
"goodbye and hello, as always" ~Prince Corwin, from Zelazny's Amber series
The name doesn't help... "Tutorial D" doesn't sound advanced at all...
Try proposing to your boss to replace your mySQL database with "Tutorial D" for... no good reasons? Will happen. Soon. Right?
Eureka Science News - automatically updated
"SQL is sloppy and unpredictable; Tutorial D is a correct relational database language."
sounds a lot like
"C is sloppy and unpredictable; Pascal is a correct programming language."
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Seems like it can handle just about everything but maybe I'm not thinking outside the box. The biggest limitation is my lack of knowledge about how to do the things I want to do.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
My buggywhip manufacturing plant uses good old fashioned chained flat files. No one in their right mind would EVER use some *toy* database structure, especially that whole relational database poppycock. balderdash!
meh
Ever heard of TSQL? Neither would have I, if I hadn't been forced to read about it in college. It would seem that there has been a huge number of variants of SQL over the years that have tried to make it "better." The benefits just never seem to outweigh the cost of learning a new language.
For those of you that haven't been assimliated into the borg, microsoft's new version of SQL server accomodates for a new query language called XQuery which takes a lot of the best parts of XPath and XSLT and combines them and obviously the underlying framework is XML. This will cover a lot of the shortcomings over Transact SQL for those that are willing to adopt it, and honestly, it's really not that bad.
Any language is going to have quirks and inconsistencies between dialects.
SQL has worked so far but if Tutorial D really is better then bring it on.
I've gotten over SQL the "short commings" though
If you read the article, this isn't about replacing SQL, but more about testing new ideas and languages that could replace SQL. This is better than just saying, "We have a better language. Switch now or be assimilated.", and I'm glad someone's finally taking this approach. Unfortunately, the article only mentions one specific problem with SQL, but I'm sure there are others that these people might eventually solve.
Hurricane Ivan: A 17th century prison collapsed. All of the inmates escaped.
One big thing I think a database could use is a hierarchy key instead of using parentid's as "foreign keys", is just one of the shortcomings. If I wanted to make a threaded thing for my forums, for example, I'd have to make a big PHP script just to sort it properly. I would have loved to have MySQL do it automatically. SQL has a very limited syntax, as well, and is inconsistent. "INSERT INTO table VALUES ('', '', '');" That's one of the only times you see the parenthasis used in that way. You don't see it here: "SELECT * FROM table WHERE id = '';" or "UPDATE table SET id = '';" I would like to have the ability to easily use my own functions just as you do with any language. It's especially important in database software.
Ask and Discuss your HTML and other web dev stuff
Hey! Having graduated colledge as a technical writer, much of whose work has been lost due to virii on my boxen, I think you are being unfair. I hope you loose your job, as I did.
UPDATE tblUsers SET Karma=Karma-1 WHERE UID=743982;
liqbase
that SQL is SOL.
I have gas, but my car uses petrol.
Comment removed based on user account deletion
It might be logically 'perfect' in terminal of relational math, but as a language, it's obtuse. The only book I could find on Bi Temporal database design ended up with all the tutorials written in this Utopian/Acadamian SQL language... holy crap was that annoying.
The reaons for wanting a change from SQL I agree with, but Tutorial D you'll never catch me using.
We need something to combine the power and speed of SQL query syntax with the nested filtering ability of XPath, yet doesn't require the entire DOM to be in memory to work.
-Malakai
A Dragon Lives in my Garage
Almost all the Object Oriented stuff people layer on predicates are, at best, an ad hoc, and poor, means of optimizing execution speed.
Let me explain.
One of the principles of polymorphism is that the same method has the same abstract meaning regardless of the kind of object. A predicate considered as a method subsumes such polymorphism by simply trying the various possible implementations of the method and committing to only those that succeed. If more than one succeeds then so be it -- that's the whole idea of relations as opposed to functions.
So, one reason you want all this OO stuff is the inheritance hierarchies keep you from going through all possible interpretations of a given method when the vast majority of them will fail for a given object.
Another, related, problem is that inheritance provides defaults without requiring a lot of thinking on the part of the computer. What I mean by "thinking" here is the sort of thing that is done by statistical imputation of missing data via algorithms like expectation maximization (EM) or multi-relational data mining via inductive logic programming.
So, the other reason you want all this OO stuff is so you can avoid mining a background database to provide reasonable defaults for various aspects of the data.
Some might be concerned that over-riding isn't absolute in such a system -- that you don't absolutely block, say, more generic methods when you have more specific ones present, and they're right. You don't block those methods -- you lower their priority by lowering the probability of those implementations via the statistical methods of imputation and/or induction. In a microthreading environment they most likely won't get any resources allocated to them before other higher priority implementations have succeeded. In a single threaded/depth-first environment they will be down the list of desired alternatives -- but they won't be discarded until something equivalent to a prolog cut operation kills them off.
However, and this is the important point, the work that has been expended toward OO facilities has vastly outstripped the effort that which has been put toward more parsimonious ways of optimizing predicate systems.
One of the better predicate calculus systems out there -- more promising due to its use of tabling to avoid infinite regress on head-recursive definitions and its optimization of queries using some fairly general theorems of predicate calculus -- is XSB. It has an interface to odbc and a direct interface to Oracle, but it would be better if it had something like a recoverable virtual memory substrate to support its roll-back semantics.
Seastead this.
Is right here.
From the introduction: "Rel is intended to serve multiple purposes:
-It is a tool for learning, teaching, and exploring relational database concepts in general;
-It is a tool for discovering the power and expressiveness of a true relational language;
-It is a tool for learning Tutorial D;
-It is a relational database server;
-It may serve as a prototype or "working blueprint" for future implementations of Tutorial D or any "D" language (more on this later);
-It may serve as a platform for experimenting with and/or examining database engine internals. "
Dude, do you hear that whooshing sound? It's the the sound of the GPs joke going right over your little head.
If it becomes too complex because of too many tables, make some views which reduce the complexity for generic parts of queries.
bash$
Geesh, links to a press release and trade rag article, and not even the name of the project itself? Go read some real information about Rel, look at the examples, download the source, have fun.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
For those interested, the paper describing this language (linked to from the article) is available here. There's a link to the grammar of the language at the end of that paper.
I use SQL quite a lot. It's certainly great for a lot of things, but it does have some limitations here and there. For instance, trying to deal with things like hierarchical structures, or joining on having identical/similar children, is a nightmare in SQL. Even if the query doesn't need to be efficient to run, it can still be extremely complicated to write and test. SQL simply wasn't designed or intended to deal with those sorts of structures.
Unfortunately, short of using external code outside the database, it's so often a choice between using SQL or nothing else for writing a query in a particular database rather than an option between SQL and another language. In some ways it's like being forced to write every program in C or every program in Java or every program in Lisp, where realistically one or another might be better suited to a particular task.
I suppose one of the reasons for only supporting SQL is that a predictible query language makes it easier to arrange data structures so they can be queried most efficiently. Still, it'd be nice to see an alternative front-end language or two supported in one or more of the major databases. Not every query needs to be ultra-efficient, and there have been many times where I would've liked to trade an efficient query execution for a language where what I wanted was more writeable.
Comment removed based on user account deletion
Prior to PostgreSQL, the Postgres database
was based on another query language other than
SQL.
One of the main reasons why
PostgreSQL took off after this was that
it changed over to SQL in response to
community/industry request and requirements
(and openness to community contributions),
bringing it in line with the industry
standard.
I suspect that the next evolutionary step will
be to allow multiple query languages to be used
on the same DB engine.
this proposed language is like a superset of sql. It also sort mixes itself with PL/SQL-like constructs as well. I think it's rather novel and it could make your optimization tasks easier if you had access to something like this... less trying to think in terms of the language, more in terms of how you want to acutally manipulate the data.
This is _not_ a query builder. It's going back, looking at what relational algebra is, seeing what people do with SQL, and then making sure the language has all the idioms required to be "complete" and not arbitrary.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
The article criticises SQL but the author has little familiarity with SQL for example:
"but the syntax is often inconsistent and unless you use one of the many vendor-specific supersets of SQL it can be tricky to express complex series of operations in a concise manner."
But in fact, SQL is so popular because complex expressions need little changing from specific vendor offerings. If people choose to program using the subsets, then well and good, but the ANSI standard is generally thought to be sufficient. This is like arguing for the abolishment of HTML and XHTML because Microsoft make a flawed browser - hopefully the database language is better than the reasoning here.
It then goes on to say "The idea is that there should be no arbitrary restrictions on the syntax of the query language, but at a lower level the database shouldn't run up against idiotic limitations. The limitation in existing implementations that generates the most comment from the various parties in the debate is the problem with "null" values in relational databases. Put simply, a database field has a type (50 characters, for instance, or a floating point number to two decimal places, or an 8-bit integer), but when you don't fill the field in (i.e. it's "null") it loses all its meaning. Even the ANSI standards state that if a field is null it's said not to exist - so if you ask a database for "all entries where field X is not equal to 47" it won't return any of those where field X is null because instead of saying "Null doesn't equal 47", the value "null" is deemed not to be comparable with any non-null field."
Well, for starters, null is not numeric zero, null is the absence of any data whatsoever, and every SQL doc in the world tells you to not mistake it for zero. Any arithmetic expression containing a null always evaluates to null. For example, null added to 7 is null. All operators (except concatenation) return null when given a null operand. That's exactly why it's the ANSI standard.
If you want to find "all entries where field X is not equal to 47" then pass your attribute a value like "0".
SQL is neither clunky nor obsolete. Tutorial D may actually be a better database modelling method, but the article's criticisms aren't sufficient to exault Tutorial D whatsoever. The "Project D" syntax and model may possibly be better, but these criticisms aren't a convincing reason to scrap SQL.
Si tacuisses philosophus mansisses. If you had kept quiet, you would have remained a philosopher.
select client.name, client.id, product.id, product.name, product.price from client_table client, product_table product where client.id = product.client_id and client.id = ? and product.discontinued = 0 order by product.price
Assuming you substitute something for ?, that will effectively join the two tables into one, and give you a list for all products from a certain client (given by ID) which have not been discontinued, and order these results by price.
The World Wide Web is dying. Soon, we shall have only the Internet.
Compare the symbolic forms:
Example, theta join
And the implementation in SQL:
SQL join example
Specifically in Tutorial D (and hence Rel) you would do this:And subsequently do shit with T1. That's it.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
RPG already overcomes the shortcomings of SQL
One of my favorite idiosyncracies with null is Null = Null is Null (unless you turn that off in the DB), but Group by groups together equal values except it also groups nulls!
I looked at the articles, which are too broad by the way, and I didn't see enough of an explaination to make out real detail.
However, it seems as if Tutorial D is nothing more that a purely mathematical improvement of SQL. In other words, it's like comparing Lisp to Prolog or ZF Set Theory to HBG. (Okay, I'm not a logician..., so you math wizards can hold off on the flames.) I'm all for improving SQL. It just seems like Tutorial D addresses the usual complaints about the hazy concept of a NULL in a database.
SQL or any derivative thereof will be inherently complex. This is because SQL is merely an implementation of Relational Algebra. That's the key. Real RDBMS's are inherently mathematical in nature. Complex SQL queries are tough. Too often the average database programmer couldn't even tell you what the definition of a set, function (i.e. the mathematcial definition), or a cross-product is. Yet, they'll write code (or not) that incorporates complex joins. Incidentally, they'll do the same thing with regexs too. Programming still has it's deeply mathematical roots. Not as much as I'd like, but still...
In short, if you're looking for some cool new English Query tool to save the day, you won't find it here. Still, if you're a SQL wonk looking for a new toy or an improved SQL, this may be of interest to you.
Oh, by the way, I used to have a copy of Date's database book. I sold it along with my copy of Foley and Van Dam, Sipser's Theory of Computation, and Aho and Ullman's compiler design book [the "dragon" book] because I needed to pay the rent. Interestingly enough, the books retained a pretty high resale value even after all these years.
What do you mean my sig is repetitive? What do you mean my sig is repetitive? What do you mean....
And if it were actually relational, then it might be interesting in the current discussion. But it ain't. That it comes up is funny, in context, because mistaking things like XML for relational is something that Date regularly has massive heart failure over.
I forget what 8 was for.
Jack Black and some bald dude have gotten into databases?
SQL was a language designed to allow relatively unskilled operators to be quickly trained for data entry using the language directly, and thus it was designed to be English-like, flexible, and forgiving.
SQL is only vaguely reminiscent of the true mathematics behind the relational data model. It continues to be used and expanded, despite its restrictions and shortcomings, because it is far and away more popular than any other database language.
The fundamental assumption of the relational model is that all data is represented as mathematical relations, or rather, a subset of the Cartesian product of n sets. Unlike SQL, in the mathematical model reasoning about such data is done in two-valued predicate logic (that is, without a null value), meaning there are two possible evaluations for each proposition: either true or false. The data is operated upon by means of a relational calculus and algebra.
The relational data model permits the designer to create a consistent logical model of the information to be stored. This logical model can be refined through a process of database normalization. A database built on the pure relational model would be entirely normalized. The access plans and other implementation and operation details are handled by the DBMS engine, and should not be reflected in the logical model. This contrasts with common practice for SQL DBMSs in which performance tuning often requires changes to the logical model.
As many others have pointed out, there are decent tools out there for generating SQL for you. I've used Hibernate quite a bit. It has saved from writing a ton of SQL, but I've still written a lot of HQL (Hibernate Query Language.) Hibernate also has a Criteria class for completely eschewing a query language in favor of purely programmatic queries. It is very limited though.
All that being said, the problem with Hibernate and any other SQL generator is very simple. They are not themselves querying and accessing data. They are specifying an intermediate language that is then in turn parsed and executed. If writing SQL is liking speaking to a translator, then using Hibernate is like speaking to a translator who then speaks to another translator, etc. What the Tutorial D guys are after is a native language that makes the translation(s) as transparent as possible.
I have been working on an SQL alternative myself for a while. My approach is more functional (not procedural) in nature. If the language is designed based on this, then new operations can be added without having to add to the syntax of the language. This would help vendor compatibility because if vendor B does not offfer an operation that vendor A does, then a DBA can simply add a clone of the "function" without tweaking the language parser.
Tutorial D uses infix notation, which tends hard-wire operations to a syntax parser. Prefix (functional-style) is more flexible, consistent, and easier to parse. For example, new parameters can be added to prefix without changing existing calls. It is just an extra, perhaps optional, parameter. It is hard to do with with infix.
My relational replacement would also make it syntactically easier to perform relational operations on things such as column name lists. The column list is simply a table in its own right (perhaps with syntactical shortcuts); thus it can have table operations (relational algebra) done on it just like tables. It is "conceptual reuse" you can say.
Table-ized A.I.
We (BitMover, the people who produce BitKeeper) are building a database on top of our SCM system (yes, that's a little weird but it works out well).
/xyzzy/ {print $ID}' /rob|lm|wscott/ && $STATE =~ /open|assigned/ {print $ID, $SUMMARY}'
We played around with straight SQL syntax, flirted with ruby as the syntax, and ended up with awk (actually nawk). It was the best balance between simple enough for normal people to understand and powerful enough to get the job done.
So we can do stuff like
bk db -s'select from bugs
bk db -s'select from bugs where $OWNER == "rob" {print $ID}'
bk db -s'select from bugs where $OWNER =~
etc. The where clause and the print clause (print is implied) are full on awk scripts, do whatever you want with them.
We're big fans of not reinventing the wheel. Awk is a little weird but it's 95% of the way there and a few tweaks made it perfect for us. So why invent a whole new language? Especially when all the awk code is about 100K of text on x86 and includes a full on regular expression library.
that they are trying to give you the best of both worlds. Expressions that can be expressed simply in SQL have short forms in the language too. Expressions that were hard to express in SQL but easy in R.A. are still pretty basic forms.
By not trying to be like SQL, and more like {T,PL}SQL, I think they get the freedom they need.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Quote
Most people who use databases in anger are familiar with the concept of a relational database.
Unquote
Maybe someone could enlighten me as to why the word
anger is in the first sentence of the article. Why
would using databases in anger be relevant? I use
databases in finanical situations, is that similar
to anger?
see, if you were born around 1940 you could have been using IMS/DB, VSAM, ISAM, IDMS, etc back in the 70s.
Tons of opportunities there for low-level access to your data. Of course, there's a reason that all those database management systems were abandoned for a 'busted ass super high level language'. It's because they sucked to maintain, they didn't evolve well as business requirements changed over time, and if you had the *most* basic of business questions - you'd never get an answer without a month of writing code.
But don't despair - pick up a little more SQL and you may find it isn't that tough.
By creating a new language, "Tutorial D", developers are excluding the other languages as much as they're including new features in the new language. Why not just add a Java package that includes the new syntax? To get anywhere in software development, even Tutorial D code will have to interoperate with existing systems and programmers with existing skills. Someone will have to code a "Tutorial D" JDBC driver, and ODBC, and all kinds of middleware that eats performance, developer time, and introduces the maintenance pitfalls of complexity. And by adding a package to an existing language, they can skip reimplementing the features of the existing language that they include in this new one, like loops, branches and character output. The effort seems as vain as the endless 19th Century conceits of inventing complete philosophical systems from scratch, to serve the reputations of egomaniacs dominating university debates. Why can't everyone just speak Object, with procedural slang and set-theoretical poetry?
--
make install -not war
It is not true that no one ever did anything with Date's and Darwen's ideas on a relational language. Check, for instance, the category I edit at the Open Directory, or even Darwen's own The Third Manifesto website with its list of projects.
Probably the poster is confused about the nature of Tutorial D. As it names indicate, it is but an example of a possible 'D', and one targeted at instruction at that. This accounts for its COBOLishness. It is possible to implement a non-Tutorial D that is completely faithful to the Relational Model and the Third Manifesto, yet has a distinct flavour.
For example, Alphora Dataphor implements D4, which was a compliant D until having had to incorporate SQL NULLs quite recently, and it has a Pascal flavour to it; Opus and Duro are C-like; there was a guy wanting to implement a C#-like D-flat language; Alfredo Novoa is implementing Tutorial D itself in MS.Net; and so on.
By the way, it is interesting that until now the more ambitious projects, that seem to be Alphora's and Mr Novoa's, are in MS .Net. Time for the free software community to rise to the challenge!
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I might also introduce keywords POSSIBLY and CERTAINLY that collapse tri-state logic (true, false, maybe) into boolean logic. Thus, POSSIBLY(a = 5) would be true when a is UNKNOWN but CERTAINLY(a = 5) would be false.
Date advocates a different approach - no NULL at all. Instead, he has some sort of parallel table structure; a row in one table for the value being present and in another for the value being absent. With some more complex way of constraining it so there would be no contradictory information in the tables. I don't like this approach - having no NULLs seems simpler than having two, but not once you add in the weirdness of contraints. And not once you realize many tables have multiple nullable columns. Joining so many tables together would get ridiculous quickly.
In practice NULL seems to not be a huge problem for me. Occasionally a field can either unknown or inapplicable, and I need to distinguish between the two; I have to do a kludgy thing with another field and a CHECK constraint. But for the most part, it's just an extra half second of thought when writing the logic, which isn't too bad. But it does trip newcomers. It would be worth fixing if you were designing a new relational query language from scratch.
Why don't you participate in the development in one of the OSS database systems (like Postgres) to [add temporary views] Bingo, there is your 'variable' functionality without inventing a whole new language.
1. It is not that likely that I will get a chance to use it at work.
2. SQL stinks in other ways that I would like to see fixed. In other words, I think it is time to explore a complete overhaul. Why be stuck with a "good enough" language forever? We are finally getting away from COBOL as the dominent biz language, so how about we work to get away from its relational cousin known as SQL?
They keep tacking stuff onto COBOL to try to modernize it, but the result is a language only a mother can love. They are even adding OOP to it.
Table-ized A.I.
I use PostgreSQL for all my DB stuff. Comparing it to MySQL is like comparing a mini-pickup to an 18-wheeler. PostgreSQL ANSI support is good, and it's very stable.
When I write custom apps (pretty much all I do) I write to the full capabilities of PostgreSQL. It's "man enough" to handle the biggest projects I'll likely ever see, and I'm not worried that the vendor will up and leave, since there isn't one.
In fact, PostgreSQL has had an interesting history in that the primary supporters of it have changed several times. PostgreSQL has weathered them all with grace, and remains today an excellent database package with a good, active community and quality developers.
So, I don't worry about JDBC, I don't write to cross platform, I could give a whit about Oracle or DB2 or whatever, but I don't. PostgreSQL is free, plenty good enough, and it won't go away.
Why bother trying to make my application portable?
PS: The article's example about null is stupid. Null = "I don't know". In that context, how could you include values of " 47" if you don't know what the value should be for a particular record?
I'm interested in this new DB language, if it actually offers a real benefit - but the article does a lousy job of getting me excited about it...
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Lisps allow usage of SQL-like syntax inside programs without stuff like "SELECT X FROM Y WHERE Z = ? ORDER BY A" or "SELECT X FROM Y WHERE Z = '" + something + "' ORDER BY A". Look here and here.
Maybe try an object-oriented database....Relational databases aren't the only game in town
Object DB's don't have enough solid theory behind them. There is too much inconsistency and lack of consensus in the attempts to formalize them.
It may be because one man, Dr. Codd, created relational theory, and thus there is a narrow set of principles to follow. OO has yet to find a Great Consolidator of similar caliber. (I am skeptical it will happen, but won't rule it out.)
OO-DB's tend to resemble the type of systems that Dr. Codd was actually trying to "fix" when he came up with relational theory. Thus, OO-DB's tend to seem "primitive" to relational fans.
Part of the problem is that database themselves run counter to "pure" OO encapsulation. Encapsulation dictates and/or allows each entity to define and handle its own operations. This creates at least two problems:
1. There is no guarentee that the operations will be compatible or consistent across classes. One class might have a Find operation, but another call it Search, for example.
2. Encapsulation requires that a single entity (class) handle its own implimentation. However, automated optimization requires the implementation be consistent and known to something outside the entity. In other words, implementation efficiency coordination breaks encapsulation. Objects can't be selfish about their implementation.
Attempts to solve these tend to make it turn into relational in the end anyhow, making it seem futile to keep OO-ness.
Table-ized A.I.
Tutorial D with a truly relational rdbms has already been implemented. The company is Alphora. The product is Dataphor. see http://www.alphora.com/
Talking SQL nowadays strikes me as being like talking raw assembler. You can do it, the tools are even rather nice nowadays, but any sane developer would use a higher level wrapper.
Like for instance, Hibernate. It does serialize/reconstitute, handles nested objects and data structures, and it's very nearly as easy as programming with regular heap-allocated objects. In any big app if you didn't use some such, you'd end up reimplementing it.
I see no reason wrappers like Hibernate have to backend onto SQL and only SQL. They could as easily emit and control this "Tutorial D" language.
> Usually, IMO, performance tuning, when it requires altering the storage schema, is done using one of two methods: > 1) Denormalization > 2) Higher normal forms > 3) Summary tables I agree with you if you mean that these are the tricks the (optimal) RDBMS could use "under the cover" to optimize the access plan (making them "transparent" to the application). Let's take the "Denormalization" as an example: we have two entities A and B that are loaded once a day with a batch. We know that they're mostly joined together in the queries. My idea of an "optimal" RDBMS is that I can define the two entities and the application can query them individually or joined together. Then I decide to start the "tuning" phase and I give the RDBMS an "hint" to change the physical layout of the data and keep them just in a single "data store". I keep inserting tuple in A,B entities and the RDBMS would keep the "abstraction" of two indipendent entities. The joined query (that is the more frequent) can get the data from the 2 entities from the same blocks. If the application evolves in a way that the individual queries become more frequent I'd have to "revoke" the hint and separate the datastores WITHOUT changing the application. The SQL RDBMS are beginning to have these features (what I describe here is more or less the Oracle CLUSTERED TABLE) but on other databases the solution is to change the logical schema when they just want to change the phisical layout of the data.
This message doesn't need a sig