Talk:SQL/Archive 1

message: The spelled-out name is 1000x less common than the initials (according to google), and the initials don't have any other common meanings.  I think the full name should redir to the initials.  Any reason not to? Stan 19:52, 23 Oct 2003 (UTC)
replies: text: I'm surprised it wasn't moved there already. You certainly have my vote. Jan Hidders 15:41, 24 Oct 2003 (UTC)
replies: text:  Done.  Hopefully the next person to get the urge to move it back to the spelled-out name will see this bit of the talk page and reconsider. :-) Stan 17:15, 24 Oct 2003 (UTC)
thread_title:  Full name 

message: From the article:
SQL code can rarely be ported between database systems without major modifications. Most people in the field believe that this lack of compatibility is intentional in order to ensure vendor lock-in for proprietary database systems.
Is this really true? Are there any references to back up the "most people in the field..." assertion? I think there are some equally plausible reasons for the lack of compatibility between implementations of SQL:
* SQL is very large (the spec is 1500+ pages) and complex; it's also ambiguous in places and difficult to understand. Even understanding what is standards-conformant behavior can be tricky in some situations.
* Database vendors tend to be conservative about making backward-incompatible changes. Since many vendors already implemented some features (say, stored procedures or sequences) in one way or another before they appeared in the standard, it can be difficult to migrate from the vendor's implementation of the concept to the standards-compliant implementation.
* Databases are extremely complexes pieces of software, and the ability of any standards document to allow for easy portability between different database systems is limited (the large swaths of functionality that are treated as implementation-defined by the SQL standard is one major example of this). So blaming the poor state of compatibility solely on vendors (and worse yet, claiming that it is an intentional decision on their part) doesn't seem to be telling the whole story.
* It may be possible to write Vendor-neutral SQL, but one generally has to go out of their way to do it, and it may result in code more verbose than vendor-specific code. For example, some dialects ignore case (capitalization) when comparing, while others don't. If you want generic SQL, then you have to convert case for potentially every comparision done, resembling: WHERE UPPER(FOO) = UPPER(BAR)
-- Neilc 06:40, 30 Jul 2004 (UTC)
thread_title:  vendor lock-in? 

message: Template:Cleanup-technical or 
What's the practicality for the use of this template? Isn't the evaluation of what's too technical going to vary by each individual reader? For example, if I (as a non-principal author) can understand the content of an article, is that grounds enough for removing it, or do we have to put it to a vote every time we want to remove such a tag? I'm also unclear as to the overall intent of such a tag. Is this supposed to create pressure for evolving towards a "Wikipedia for Dummies" authorship style? - Bevo 15:10, 22 Mar 2005 (UTC)
replies: text: At the very least, the overview at the top of the article should be comprehensible to someone who does not have a background in the subject.  It's changed a bit since I put that template in place, but it could still use some clarification (e.g., what the hell is the "Third Manifesto" and why is it so important that it goes on top?).  It's not intended to create a "Wikipedia for Dummies", nor is it intended to keep technical information out of wikipedia; but it does need to at the very least move from general to specific and provide for those who are not computer scientists to have somewhere to start. siafu 19:25, 22 Mar 2005 (UTC)
thread_title:  Template:Cleanup-technical 

message: I'm not so sure these ought to be seperate sections.  My understanding is that they're properly a part of DML and DCL.  Any objections? DanP 00:01, 2 Jun 2005 (UTC)
replies: text: Yes!!  I object!  Data retrieval and projection ( SELECT ) and Data Manipulation Language are two very different things when mastered.  Many custom software packages that include transactional and reporting functions have language in their contracts saying that performance targets apply only when no reports are running.  DigitalEnthusiast 23:35, 21 December 2006 (UTC)
thread_title:  Data transaction and Data retrieval? 

message: We seem to have multiple pages for different topics about SQL. Shouldn't these be merged into this article?
The articles I think should be merged are:
* Join (SQL)
* Insert (SQL)
* Drop (SQL)
* Begin work (SQL)
* Alter (SQL)
* Null (SQL)
* Prepare (SQL)
* Delete (SQL)
* Update (SQL)
* Table (database)
Before I do something like this, can someone perhaps give reasons why I should not do this? - Ta bu shi da yu 7 July 2005 03:11 (UTC)
:Table (database) should definitely not be merged in. It is something that is not specific to SQL. I'm ambivalent about the others, though. -GregoryWeir 7 July 2005 20:45 (UTC)
::Sounds fair. Will keep this open for a while, however. - Ta bu shi da yu 7 July 2005 23:52 (UTC)
:You shouldn't do it because this article would become overly large, paqrticularly as they get expanded with differences between implementations. Could well be why they are in different places already. In the event that you go ahead, do remember to preserve the full GFDL history so this article doesn't become a copyright infringment. Jamesday 12:59, 17 July 2005 (UTC)
replies: text: Personally, I'm against it. The resulting article would either be gigantic, or it would contain less content than the individual articles do now. Either result would be bad. It's not like navigating from one related page to the other is difficult, and frankly I  think it's organizationally nicer to have more pages rather than less, since it makes searching easier. There seems to be this tendency on WP to get merge-happy, and I think it should be avoided where not clearly advantageous. Here, it's not. --Kadin2048 17:32, 2 August 2006 (UTC)

text: Merging Insert (SQL) (and others) into SQL would be akin to merging addition into mathematics.  SQL is not a complex language, but the myriad nuances of each command, statement, and operator makes a good argument for segregating them into their own articles. CodeNaked 14:33, 21 September 2006 (UTC)
thread_title:  Merging pages