SQLキーワードに大文字を使用する十分な理由はありますか？[閉まっている]

デフォルトは大文字のようですが、キーワードに大文字を使用する理由は本当にありますか？新しいストアドプロシージャのようなものを作成しようとするたびに、SQL Serverが提供するものと一致させようとしただけだったので、大文字を使い始めました。でも、Shiftボタンを押しっぱなしにしておく必要のある5番目の赤ちゃんの指がひどいので、大文字の使用をやめました。大文字に戻すべき理由は何ですか？

編集：回答をありがとう。私はCOBOLが王だった当時はまだプログラミングをしていなかったので、これに気づきませんでした。これから小文字のままにします。

それは単にスタイルの問題であり、おそらく編集者がコードのカラーリングを行わなかった時代に始まったのでしょう。

以前はすべて大文字を好んでいましたが、今はすべて小文字に傾いています。

個人的に、私は私のSQLが私に怒鳴るのを好きではありません。ITは私にBASICまたはCOBOLのことを思い出させる。

そのため、データベースオブジェクト名がMixedCaseのT-SQLを小文字にした方がいいです。

読みやすく、リテラルとコメントが目立ちます。

SQLは古いです。大文字が叫びます。見た目が変で見苦しい。

間違いなく真実ではありますが、大文字のキーワードが適切な慣例であるSQL言語に特有の理由に対処するものはありません。

多くの新しい言語とは異なり、SQLには多数のキーワードがあり、構文を精神的に解析するために、キーワードと識別子を区別するリーダーの機能に依存しています。

あなたの質問への直接的な答えは、「SQLコードの読者が、ほとんどの現代の言語ではそうではないのに、なぜSQLキーワードの読者が大文字のキーワードからそれほど多くの恩恵を受けるのか」に対する答えです。

• キーワードを頭の中で維持することに依存することは、多くの現代の言語にとっては合理的ですが、SQLには不合理です。キーワードが多すぎ、バリエーションが多すぎます。

• 句読点の手がかりに依存することは、ほとんどの最近の言語では合理的ですが、SQLには不合理です。キーワードの正確な順序に応じて構文が示されるため、数が少なすぎます。

• キーワードを区別するために自動蛍光ペンに依存することは、通常の場合、現代の言語では妥当ですが、SQLで蛍光ペンが達成できることの現実を無視します。ほとんどの場合、SQLのすべてのバリアントのすべてのキーワードがカバーされているわけではありません。SQLは、蛍光ペンが役に立たないコンテキストで頻繁かつ定期的に読み取られます。

これらはSQLに固有の理由の一部であり、SQLコードのリーダーは、キーワードの大文字で標準化し、識別子の大文字以外の（つまり、小文字または混合）大文字のみを使用することで最適に機能します。

強調表示すると役立つことがあります。しかし、蛍光ペンがSQLを持っていることを知っている場合のみ。エディター/フォーマッターがSQLを処理していることを合理的に認識できない状況でSQLを使用することがよくあります。例には、インラインクエリ、プログラマーのドキュメント、および別の言語のコード内のテキスト文字列が含まれます。同じことは、PythonやC ++などの言語の場合ほど頻繁には当てはまりません。はい、それらのコードはこれらの場所に表示されることがありますが、SQLコードの場合とは異なります。

また、読者は通常、特定のSQL実装が使用するキーワードのサブセットのみを認識する蛍光ペンを使用します。あまり一般的でないキーワードの多くは、SQLバリアントをよく知っているキーワードを除いて、強調表示されません。そのため、読者は、蛍光ペンを使用している場合でも、適度に複雑なSQLステートメントでキーワードを区別するためのさらに直接的な方法が必要です。

したがって、読者は頻繁に（そしてそれがいつになるかを事前に知ることはできません）、SQLステートメント自体の内容からの支援が必要であり、ライターが何をキーワードとして意図していて、何を識別子として意図しているのかを知る必要があります。そのため、SQLコンテンツ自体がリーダーのキーワードを区別する必要があり、大文字のキーワードを使用することが、これを行う従来の便利な方法です。

ゴードンベルの例は正確ではありません。通常は、クエリ全体ではなく、キーワードのみが強調表示されます。彼の2番目の例は次のようになります。

SELECT name, id, xtype, uid, info, status, 
base_schema_ver, replinfo, parent_obj, crdate, 
ftcatid, schema_ver, stats_schema_ver, type, 
userstat, sysstat, indexdel, refdate, version, 
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

キーワードの方が目立つので、これははるかに読みやすいと思います。構文の強調表示を使用しても、大文字で表記されていない例を読むのははるかに困難です。

私の会社では、SQLのフォーマットをもう少し進めています。

SELECT      name, id, xtype, uid, info, status, 
            base_schema_ver, replinfo, parent_obj, crdate, 
            ftcatid, schema_ver, stats_schema_ver, type, 
            userstat, sysstat, indexdel, refdate, version, 
            deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
    sysobjects.col1=systhingies.col2
WHERE category = 0
    AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

関連するエンコーディング（ASCII）がまだ提案されていないため、ほとんどの人が大文字の文字を超えてコード化する可能性がなかった時期がありました。6ビットのみが利用可能でした。SQLがより最近である一方で、小文字の小文字はまだプログラミングでは一般的ではありませんでした。

なお、一部の人は、請求 DATABASEが切迫感をGETと高速クエリを実行すること。

私たちが読んだテキストの文字の10％未満が大文字です。したがって、私たちの脳は大文字よりも小文字を認識することに熱心です。研究によると、大文字のテキストを読むのに時間がかかります。以下は一例です。

http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals

上記の例では、1つまたは2つの単語だけを話している場合でも、違いが生じることを強調しています。

これは、SQLが非常に古い言語（1974）であるため、考案されたとき、ほとんどのキーボードには小文字がなかったためです。言語文書は当時のテクノロジーを反映したものでした。

調査によると、すべてのCAPSは読みにくいため、米国連邦道路管理局は、以下のように、統一交通制御装置に関するマニュアルで大文字と小文字が混在する標識の使用を義務付けています。

従来の道路案内標識の場所、道路、高速道路の名前のレタリングは、小文字と最初の大文字の組み合わせでなければなりません。

ニューヨークポストも出版した：

調査により、すべて大文字の標識を読むことは困難であることが示されています。道路から離れて見つめるために費やされたこれらの追加のミリ秒は、特に高齢のドライバーの間で事故の可能性を高めることが示されています。

大文字を使用する正当な理由はなく、使用しない正当な理由もあります。

SQLキーワードには大文字を使用します。私はこの日と年齢で読むこととばかげたことは難しいと思います。

SQL言語は、大文字と小文字を区別しないものとして定義されています。そのシフトキーから指を離してください！

大文字はキーワードの可視性を向上させますが、コードの強調表示とインデントで補うことができます。
クエリエディターや他のツールはt-sqlコードの編集に不思議であり、小指を拷問する必要がないため、小文字を使用しています。

モンキーは、サルが私のために行います。パターンマッチング-私が見たようにそれを行うと、句の構造が精神的にもっと簡単に整列します。

大文字は読みにくくなります。すべての単語の輪郭は箱のような形をしています。ディセンダーやアセンダーはありません。小文字のFTW！

私はそれがより読みやすいと思います。各句の先頭に改行を入れたり、句の間をインデントしたりする場合も同様です。

フォーマット製品を試してください（私はRed GateのSQL Prompt / SQL Refactorを使用しています）。大文字の使用方法を設定でき、コードは常に一貫した形式になります。小指を休ませて、コンピューターに任せてください。

大文字を使い続ける理由の1つは、あなた（または他の誰か）がメモ帳などでコードを表示しているときに読みやすくなることです。つまり、「キーワード」とテーブル名、SP、UDFなどを簡単に区別できます。

適合のための適合以外、いいえ。これは非常に主観的なトピックですが、すべてのSQLで大/小文字混合を使用することを好みます。SQLの方がはるかに読みやすく、キーワードがすべて色分けされている最新のIDEでは何も失われません。

Microsoft SQL Server Management Studioのインテリセンス/オートコンプリートでは、予約語に大文字または小文字のいずれかを使用できますが、MAX（）、SUM（）などの大文字の関数呼び出しを使用できます。

そうであっても、パーサーはまだmax（）およびsum（）の小文字バージョンを処理できます。

これは、処刑の性質に関して両義性を意味するため、単に個人的な好みの問題です。

私はすべて大文字で書かれたものはすべて嫌いです（そしてすべての大文字をさらに入力するのが嫌いです）が、コミュニティに反対するように自分を説得することはできませんでした。いつものように、Vimとそれに関連するパッケージは、非常に多くの問題の解決策です。

http://www.vim.org/scripts/script.php?script_id=305

通常どおり入力するだけで、入力時にキーワードが自動的に大文字になります。あいまいなSQLの呪文をすべて使用したわけではありませんが、まだ失敗していません。

ほとんどのmySQLコードをPHP内から呼び出し、すべてのPHP編集をvim内で行います（この場合はVIMと思います;-)。これで、PHP内のmySQLコードを強調するプラグインが確実に存在するようになりましたが、それを見つけられなかったので、探すために時間をかける必要はありません。したがって、私はすべてを大文字にすることを好みます。私はこれを見つけます：

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
CREATE TABLE IF NOT EXISTS HISTORY
(
   ID INT NOT NULL AUTO_INCREMENT,
   INSERTDATE TIMESTAMP DEFAULT NOW(),
   ALTERDATE TIMESTAMP(8) DEFAULT NOW(),
   DELETEDATE TIMESTAMP(8),
   ALTERCOUNT INT DEFAULT 0,
   SELECTCOUNT INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB
";

mysqlQuery( $query, $con );

これよりもはるかに優れたPHPとSQLの区別に役立ちます。

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
create table if not exists history
(
   id int not null auto_increment,
   insertdate timestamp default now(),
   alterdate timestamp(8) default now(),
   deletedate timestamp(8),
   altercount int default 0,
   selectcount int default 0,

   primary key(id),
)engine=InnoDB
";

mysqlQuery( $query, $con );

また、何らかの理由で、私はallcapsとラクダのケースを混ぜるのが嫌いです：

CREATE TABLE IF NOT EXISTS history
(
   ID INT NOT NULL AUTO_INCREMENT,
   insertDate TIMESTAMP DEFAULT NOW(),
   alterDate TIMESTAMP(8) DEFAULT NOW(),
   deleteDate TIMESTAMP(8),
   alterCount INT DEFAULT 0,
   selectCount INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB

それはID私をいらいらさせます。代わりにすべきidですか？またはiD？