Sql Flaws Discussion

Discussions related to SqlFlaws

My list of top ranked SQL flaws or missing features based on discussion in ExBaseRant. --top

1. Lack of locally-defined named sub-query referencing (or user-defined temp views)
2. Lack of user-defined or locally-defined functions
3. Inflexible control over column info and column sets.
4. Null-handling behavior - overhaul Nulls
5. Doesn't require explicit keyword for Cartesian join (too easy to accidentally create)
6. Aliased columns cannot be used in some clauses, requiring expression duplication or that the long name be re-stated.
7. Dates, Booleans, conditionals, and capitalization not standardized across vendors
8. Needs better "auto-joins" based on key dictionaries (natural join depends on column naming)

(Subject to change based on further pondering. Thus, be careful about referring to numbers alone.)

(Moved discussion from NullVersusNone because it's comparing query language features in general, not just Null vs. None.)

It sounds like this is turning into a definition battle. LaynesLaw? Perhaps we actually are agreeing that Null, or things like Null, are implemented poorly. I'm all for overhauling Null, regardless of what the fix is called. But do we really need to toss out SQL entirely to fix nulls (and perhaps the duplication issue)? Why not fix SQL? It would have a better chance of taking off. If you want to sell Rel, then focus on convenience of syntax and expression because the problems you mention about Nulls and duplications are generally orthogonal to SQL in the larger sense. A kind of SQL++ could fix some of the shortcomings of the current batch. -t

[I don't want to sell Rel. It's free and OpenSource. I want to give it away! Note that TutorialDee is, in effect, your "SQL++". One of its designers, Hugh Darwen, is a former SQL standards committee member. TutorialDee is based on his and ChrisDate's recognition of the limitations and flaws in "standard" SQL. But, there's a point at which fixing the flaws in a language means it's either no longer the same language, or the fixes will be contradictory to characteristics of the original language, so retaining its syntax will only result in confusion. So, yes, we really do need to toss out SQL entirely. By your argument, I suppose we don't need any new programming languages -- a kind of FORTRAN++ could fix some of the shortcomings of the current batch.]

By "sell" I meant "promote successfully". And I am not saying that Rel or D is "bad", but merely that focusing on purity is not going to carry much weight as far as acceptance. Expressiveness is more important than purity to most. Further, if I thought SQL was wonderful, I wouldn't have drafted up SMEQL (TopsQueryLanguage). And, Fortran has become more modern over the years. However, its niche-ier now, but still serves its niche fairly well. It is still competitive in its niche. It would be interesting to look at what's fixable about SQL and what isn't, and see how unpopular the non-fixable parts are. --t

See? not even you want to go an find out how to fix SQL? (SMEQL certainly does not look as an evolutionary "fix" of SQL). Maybe you could lead with an example by transforming SMEQL in to a series of incremental fixes for SQL? Although I think your time would be better spent learning Rel (or AlphoraDataphor, which BTW has a syntax that is closer to SQL, but it certainly is not a "fixed" SQL) and helping polish the rough spots... --LuxSpes
Issues such as Nulls and uniqueness are mostly orthogonal to key concepts behind SMEQL. SMEQL is motivated mostly by expressiveness and meta ability with column info, not about fixing "purity" problems, although does not rule it out. Like I said elsewhere, sometimes we WANT impurity because it better matches the messy external world. If I addressed something like uniqueness further, I'd make both types of result sets available, per user selection. I assist the user, I don't dictate. Obviously we are targeting different issues with different flavors of fixes and will shape our solutions to fix what we personally see as the "big" problems. (See list above.) --top

[It's good, then, that TutorialDee is considerably more expressive than SQL. I'm not focusing on purity for purity's sake. I'm focusing on purity because it has benefits in terms of predictability & correctness of results and ease of generation of results. Those are practical, not theoretical, concerns. I'm sure SQL will still be around for a while, but it will be eventually be reduced in importance to precisely where it belongs -- as a mere low-level protocol to allow D languages to communicate with legacy SQL DBMSes. It might be interesting for someone to look at what's fixable about SQL and what isn't, but it isn't interesting to me. I've seen the future and I've no interest in looking back, especially as Rel is becoming increasingly popular despite being, at present, little more than a teaching tool. When I release some of the front-end and connectivity facilities I'm working on now (which will make it much more practical without diminishing its beneficial purity) I've no doubt it will experience significant growth in popularity.]

I disagree that purity usually has no down-sides. I don't think we'll ever settle that because you remember far more problems caused by "purity faults" than I do for whatever reason or human biases we each possess, and we will most likely trust our own memories over others'. Thus, it is probably pointless to debate it further. You target the purity crowd and I'll target the expressiveness crowd and maybe both will end up with something that satisfies each goal noticeably better than SQL. This town is big enough for the both of us. -t

While I do believe purity is important because it promotes predictability and consistency, I do also find that a good number of people are attracted by expressiveness. Now, in my opinion there should be more information promoting the expressiveness advantages of TutorialDee syntax over SQL. --LuxSpes

[I agree. Alas, there are only 24 hours in a day. Therefore, for now, I must emphasise writing code over promotion.]

Expressive

What exactly is expressiveness though? Is there a wiki page about it? Sounds kind of vague and almost like a BuzzWord. Lisp expressive? Ruby expressive? My expressive is bigger than your expressive (get out measuring tapes). How can you really figure out what is more expressive than something else? Some languages express certain things differently, but it isn't always more expressive, it's just "differently expressive".

I guess we should be concerned about expressing things the best way, or the right way, rather than including billions and millions of ways of expressing the same thing.

MarchTen