Talk:SQL

my friend - sql is an abomination so is html the standards are formulated so it's easy to learn and train mass mart engineers that are clueless most of the times anyway; only a hand full of people realize these problems: you're one of them.

Spatial databases has been around for ages in fact much longer than relational but harder to grasp hence the majority of sheep flock the other way.

Here it sounds like bugzilla simply made a poor or short sighted architectural/design decision - you cannot blame them for this they used what they know is best at the time. Lots of relational database today have wrappers for MDX allowing you to query a relational database in that form. Some even have special tools that cache index information on spatial form.

A mature or long running system normally indicates these problems you speak of.

No use crapping about it; hence the opportunity presents itself to introduce similar wrappers for whatever database bugzilla runs on, maybe MySQL.

I'd think hibernate to be a worthy candidate if they don't have it already.... !!!

--. 07:24, 1 September 2010 (CEST)

No valid point was made! This article is complete nonsense and grammatically deficient at that. Try some number agreement on your statements! The author shows how little he or she knows about the subject by creating new terms at will. SQL is neither modeling nor a database: it is a query language. It is right in the name Q is for query! Just like in OQL (object query language) Should your query performance be poor, ask for assistance from an expert: you are doing plenty wrong. 30 years of industry experience getting it right says this author is bogus, or at least too inexperienced to speak on this topic.

--SMJ 07:51, 1 September 2010 (CEST)

I feel the need to respond to SMJ's.

The author is not some novice. He wrote an application that is downloaded some 8 million times a year by fellow developers! His experience and ability is unquestionable!

Complete nonsense? No! SQL is a language and the author says so. SQL is however constructed around assumptions about how the data is stored (tables of data) and manipulated (set relation semantics). This provides a general tool and yes performance can be improved in a variety of ways. There is however no getting away from the fact than this arrangement of data is not always what is required and supporting SQL can give an unnecessary overhead. To quote the wikipedia page on NoSQL (which includes reference link to research) "Typical modern relational databases have shown poor performance on data-intensive applications including indexing a large number of documents, serving pages on high-traffic websites and delivering streaming media."... and so Google and Amazon store some of their data in non-relational databases with no SQL.

As one other example it should be noted that chess games are held in bespoke non-SQL databases by the various chess programs. Chess databases do not store games as tables of data but as trees so that games can be efficiently navigated through and queried. Queries are made against the characteristics of the position and not just against a set of data.

Grammatically deficient? I'm sure your Czech is much worse than his English! I've certainly seen worse grammar than in this article. SMJ's wasn't perfect either: "It is right in the name Q is for query!" is missing punctuation between the 2 clauses!

--Dan Sheppard 15:32, 1 September 2010 (CEST)

It's all about data size and performance. There are many options. You can infuence it by DB architecture, selection of SQL machine, caching techniques, HW sizing and replication. NoSQL is also option but it's just a different data structure and you can also stuck in the similar troubles as in SQL. Also NoSQL is often used because many SQL machines are not easily scalable.

--Jiri Tulach 23:19, 2 September 2010 (CEST)

I would say to anyone having doubts about eh relational model, not to say any particular SQL product, that they look at Chris Date's work, including his innumerable interviews and articles in which he takes on any and all complaints regarding the relational model.

Honestly, I've read a lot of his back and forth with a wide variety of opponents and I haven't ever judged him to be the loser in an argument.

Of all the books he's written over the years, The book he would tell you to read at this point in time (2011) is probably his Intro. to DB systems : (and at sig)

http://www.amazon.com/Introduction-Database-Systems-8th/dp/0321197844/ref=dp_ob_title_bk

I have no particular love for SQL, it's one of those technologies someone else can do better, and I let them. But the relational model which underlies all SQL products is not something whose limitations were are suddenly discovering- quite the opposite, it's the solution to those limitations.

As Date likes to point out, hierarchical models of data representation, even if that data is itself hierarchical, are a path we've been down before and the relational model is the solution to the intractable problems we encountered there. As Sanatayan said, those who dont' know history are doomed to repeat it and repeating history is what we're doing when we embrace things like OODBMS etc. etc. as models of representation.

But Date explains this so much better. If I thought I had a legitimate gripe against the relational model, not to say a database product, I would first check to see what Date had to say lest I leave myself open to eventually being exposed as someone who really does't know have a firm grasp on the subject :(

--softwarevisualization 03:20, 24 February 2011 (CET)