Jump to content

Talk:SQL

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Wiki Education Foundation-supported course assignment

[edit]

This article was the subject of a Wiki Education Foundation-supported course assignment, between 6 September 2020 and 6 December 2020. Further details are available on the course page. Student editor(s): ASCXX.

Above undated message substituted from Template:Dashboard.wikiedu.org assignment by PrimeBOT (talk) 08:30, 17 January 2022 (UTC)[reply]

[edit]

Hello fellow Wikipedians,

I have just modified 2 external links on SQL. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 16:47, 4 June 2017 (UTC)[reply]

DQL, DCL, DDL and DML

[edit]

The link to data query language redirects to Query_language that is very general and very vague about SQL. The links for DCL, DDL and DML try to be a combination of a relevant language in general and SQL specifically, but perhaps that is relevant to each of those other pages. Sam Tomato (talk) 02:03, 21 March 2019 (UTC)[reply]

Turing completeness

[edit]

The change in "&oldid=947475103" stated that " ... the most recent SQL standard actually *is* Turing complete, but many popular implementations are not ...". This raises the question of what we are speaking about: Reflects the article the SQL standard or the numerous implementations?--Kelti (talk) 08:34, 27 March 2020 (UTC)[reply]

Don't believe me too much, because I have been away from data bases almost 30 years ago. Being warned, here is what remember.
Recursive queries were possible since SQL3, that made possible to compute recursive functions. The other thing that I roughly remember is that recursive queries were explained with fixed point combinators in some data base book that was taken from the lambda calculus. Anyway recursion is necessary for Turing completeness.
Remember that relations are sets, and SQL was based in relation operations, i.e. SQL operators are based set operators, union, intersection, cross product, projections, selection and joins. The late can be expressed with cross product, projection and selection. Recursive iteration make sense if you repeat joins until you arrive to a fixed point, otherwise you may be surprised by non-termination. (Really bags or multi-sets, see a comment posted by other person below.)
I studied that almost 40 years ago, so it is not a recent feature. — Preceding unsigned comment added by 2806:106E:B:EA86:5571:765A:3CF:AAAF (talk) 03:23, 2 August 2022 (UTC)[reply]

Is SQL an open format?

[edit]

In the second Infobox (file format), SQL is introduced as an Open (Yes value) format.

Although it is not a "free standard" and we should buy it, it costs about CHF 178.00 !!! Do we should change "Open format" to "No" by this criteria?

Thanks, Hooman Mallahzadeh (talk) 10:10, 31 May 2020 (UTC)[reply]

Seems fair to change this to "no" based on this criteria and from Open format, even SQL is a text-based format. See also List of open formats. +mt 21:51, 1 June 2020 (UTC)[reply]
@Mwtoews: Thanks for your reply, Here is the definition of open format:
OPEN FORMAT - We will say that a file format is open if the mode of presentation of its data is transparent and/or its specification is publicly available.
In here: SQL#ITTF publicly available standards and technical reports
and here: https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
Explicitly stated that it is "Publicly Available".
I changed it to "Yes (but not free)" value.
Thanks again, Hooman Mallahzadeh (talk) 05:23, 2 June 2020 (UTC)[reply]

HiveQL or HQL be considered as SQL ?

[edit]

Curious to know whether HiveQL or the language similar to SQL but used in a Hadoop cluster environment and used via Hive interface can be considered as a type of SQL? --TheHiveBeeline (talk) 21:11, 2 September 2020 (UTC)[reply]

SQL does stand for Structured Query Language

[edit]

I've added a source confirming that Donald D. Chamberlin intended SQL to stand for "Structured Query Language." Some people say it doesn't stand for anything; hopefully this will put that claim to rest. Qzekrom (she/her • talk) 16:56, 14 January 2021 (UTC)[reply]

Distributed SQL vs SQL

[edit]

I do not think my description of Distributed SQL database architecture should be merged into this article despite the tag. If I were to create the term I would have called them Distributed Relational. While they do execute SQL in a distributed manner, the means it which they (Spanner, Cockroach, et al) achieve consistency and how they store data is more interesting than that they support SQL the language. In my opinion User:CommanderWaterford's addition of a merge tag seems to be a reaction to the name of the technology rather than the contents of the article. Reboot (talk) 19:58, 26 January 2021 (UTC)[reply]

Reboot, this doesn't appear to be gaining any traction. I've removed the tag from the Distributed SQL article, which I think was added in error before you finished writing the article. I see has since been reviewed as part of the NPP process, so I think we can draw a line under this now. Best GirthSummit (blether) 18:03, 29 January 2021 (UTC)[reply]

Lists or multisets aka bags

[edit]

The article says:

tables and query results are lists of rows; the same row may occur multiple times, and the order of rows can be employed in queries (e.g. in the LIMIT clause)

A relational database with no extensions, contains relations in the mathematical sense, i.e. A relation is a subset of the cross product of sets, thus a set. For efficiency reasons, those relations are indexed by keys. I don't remember the LIMIT clause, but in principle an SQL query may produce a bag as a result. Depending on what is queried, repeated rows may be meaningful or not. Those tables with repeated rows, i.e. bags also called multisets, are not part of the database relations, they are inferred. A relational database should be normalized to model the world it represents. Having bags instead of sets in the database, could make normalization not possible, because the normal forms have smaller relations from which queries infer either relations which may be projected in bags. Those bags in actual queries are ordered for efficiency, not logical, reason. On the other hand, lists are successions, the order is meaningful. while and while . So that part of the article should say:

query results are either sets or multisets, where the same row may occur multiple times in multisets.

if everybody agree.

Can someone say more about time travelling? How Datalog (by 1984) has influenced SQL (by 1974)?

[edit]

In the entry "Influenced by" say "Datalog", a posterior query language based in predicate calculus written almost 10 years after SQL. Datalog is a kind of Prolog for relational data bases. It has recursion. On the other side SQL is based in relational calculus, where recursion is achieved via something related with the fixed point combinators in lambda calculus. Recursion was added to SQL3 if my memory doesn't fail me. Because it was needed to make the relational calculus equivalent to predicate calculus, a theoretical requirement. Both, SQL and Datalog, have a solid theoretical foundation, I could say both are discovered languages as opposed to invented languages coming from someone inspiration. It is a case of convergence in their development not of inspiration.

9075-16:2023 Part 16 - SQL/PGQ

[edit]
  1. As of spring 2023 this part is only a working draft, hence not part of the standard.
  2. The author says that JSON is introduced as a new data type - in opposition to 'JSON as a character string'. Unfortunatelly I don't have access to the working draft. Can the author publish a link to it?
  3. Please explain the stated correlation between 'Property Graph Queries' on the one hand and 'data type JSON' on the other hand.
  4. The text 'SQL/MDA' seems to be a copy/past error?

Kelti (talk) 07:09, 19 May 2023 (UTC)[reply]

SQL pronunciation clarification tag

[edit]

@Zanahary: What needs cleared up by the tag you placed? - AquilaFasciata (talk | contribs) 16:55, 13 April 2024 (UTC)[reply]

I don’t understand what “often… for historical reasons” means Zanahary (talk) 17:01, 13 April 2024 (UTC)[reply]
Because it was historically called sequel? What do you interpret it as? - AquilaFasciata (talk | contribs) 17:11, 13 April 2024 (UTC)[reply]
I interpreted it to mean that it is presently referred to as sequel only in the context of historical discussion. Does it mean that it used to be called sequel but is no longer? Zanahary (talk) 21:36, 13 April 2024 (UTC)[reply]
Ahh, gotcha; the latter example is correct but I can see the confusion. - AquilaFasciata (talk | contribs) 14:28, 18 April 2024 (UTC)[reply]
It was historically named SEQUEL, but that doesn't mean it is true that it is historically pronounced "sequel." It is very common today, especially in the SQL Server community, to pronounce it "sequel." I think both should be given as valid pronunciations without the "historically" qualifier. WanderingDev (talk) 16:24, 11 July 2024 (UTC)[reply]