この問題を対象とした質問がたくさんあることは知っています。適切な命名規則の提案は数多くありますが、私たちのチームでは議論がありました。
チーム メンバーは、テーブルに sProducts のような名前を付け、主キーに ProductGuid のような名前を付ける必要があると主張しています。
彼のシステムには 2 つの接頭辞 (s、h) があるので、s は static と h を表します。申し訳ありませんが、わかりません。そこにはまったく論理がありません。彼は、大規模なオラクルと IBM システムはすべてそのように機能していると述べています。私は oracle または ibm システムを使用したことがないので、s や h などのプレフィックスを追加するための規則はありますか? そして、それらは何の略ですか？
同じことをする人はいますか？その質問で申し訳ありませんが、常にsを追加したくないので、理由がわかりません...
彼は、大規模なオラクルと IBM システムはすべてそのように機能していると述べています。
かなり大胆な発言です。おそらく彼は間違っていると思います。たとえ私がデータベースについて何も知らなかったとしても、そう言えます。（私は800社以上のコンサルタントをしてきました。これは見たことがありません。）
今日の信念をテーブル名にエンコードすると、明日の問題が生じます。テーブルがビューになり、ビューがテーブルになり、ビューがテーブル値関数になり、静的テーブルが明日 "h-word" になることは珍しいことではありません。
静的テーブルが最終的に h-word になったら、そのテーブルをどうしますか? 名前はそのまま？そのテーブルを見つける必要があるたびに、もっと考えなければなりません。名前を H ワードに変更しますか? これで、静的であることに依存するすべてのアプリが壊れました。名前を変更して、古い名前で更新可能なビューを作成しますか? そもそも、名前が良ければ回避できた多くの作業のように思えます。
私はあなたの質問の提示に混乱しています。「接尾辞」に言及していますが、「接頭辞」を示しています。
ここには宗教的な問題がたくさんあります...
これをフィールド/列/属性のコンテキストで提示します。他の種類のものも、一貫した形を持つ必要があります。
多くの命名規則 (命名標準とは異なります) の根本的なソースは、1970 年代の IBM の「OF 言語」です。
OF は PRIME-MODIFIER-CLASS 形式を使用し、顧客のアカウント番号に CUST-ACCT-NO を生成しました。
良い名前は、いくつかのタスクを達成することを望んでいます...それがどのような種類のデータ (日付やテキストなど) であり、それがビジネスにとってどのようなものであったかを示します。
CLASS という単語 (接尾辞ですが、ハンガリー記法では接頭辞) は、今日のデータ型のようなものの短いリストです。日付、テキスト、コード、フラグ (今日のバイナリ)、金額など。
CLASS の単語は、12 つか 2 つを超えてはなりません。
PRIME/MODIFIER ワードは、システムがサポートしているビジネス上の問題により焦点を当てます。
いずれにせよ...最も難しいのは、一貫性を保つことです。
BIG no no CODE を CD および CDE と略します。
ダッシュ (-)、アンダースコア (_)、キャメルケースなどの区切り文字の問題は、技術環境によって決定されるため、議論する価値はありません。
これらの問題のいずれにおいても、最も重要な問題は一貫性です...人間がひどいものです。
正しい命名規則はありません。あなたが思い描いているものが複雑すぎて他の人が理解できない場合、あなたは悪い選択をしたことになります。
ところで...命名規則は私たちが主に扱っているものです...運が良ければ、ほこりっぽい忘れられたマニュアルに書き留められているという漠然とした考えです。
命名基準は、コンパイラと同じように自動的に適用されるものです。
私は、優れた命名規則 (DBA によって施行された) を持つ大規模なシステムに取り組んできました... データ要素または段落名を一目で見て、それが最も解放されたものを知ることができるという感覚。