2

私は11年以上データベースを使用してソリューションを開発してきましたが、テーブルの列に名前を付けることについて、かなり物議を醸す意見を「開発」したようです。常に3文字または4文字のタイプのプレフィックス、つまりintGroupIDを付けます。 nvcTitle、dtmCreated、bitPlayerHaterなど。私は他の何人かの開発者と協力してきましたが、彼らは皆、昔ながらのプレフィックス規則を絶対に軽蔑していました。

（ええ、私はここで何も発明しませんでした、私はそれをあきらめることを拒否しているだけです:)

私の主な理由は、仲間の開発者がデータの構造を理解しようとするときに、できるだけ多くの情報を提供することです。列のタイプを即座に知ることで、あなた（または少なくとも私）はあなたが扱っているもののより良い精神的イメージを得ることができます。また、C＃やVB.NETでの作業と比較して、クエリを作成する場合、通常、IDEからの同じインテリセンスサポートはありません。

これまでのところ、この特定のトピックについて私の考えを変える可能性のあるキラーな議論を思い付くことができた人は誰もいません。他にも同じように物議を醸している命名規則がいくつかあり、わかりやすくなっていますが、列の接頭辞はより多くの人を怒らせているようです。

データベース列のプレフィックスを付けるのはなぜそんなに悪い習慣だと考えられているのですか？

4

8 に答える 8

11

「ハンガリー記法」と呼ばれるものです。

開発者 (およびデータ アーキテクト) として、私はそれが無価値だと思います。それは多くの情報を提供しません。

  1. 型情報の一部について、簡単で不正確な説明を提供するだけです。たとえば、長さを省略します。

    オブジェクトが BLOB である、より複雑なデータベース環境では、BLOB 内のオブジェクトのタイプに関する情報はまったく提供されません。

  2. データ型の変更は面倒です。

  3. あいまいな接頭辞を覚えておく必要があります。ですかvcName、strNameそれともuniName？

  4. SQL は型変換を自動的に処理するため、面倒な型固有の命名はほとんど意味がありません。

  5. 最も重要:データの意味に関する有用なドキュメントは提供されません。私の経験では、ほとんどの場合、人々は意味を腐敗させています。int か string かで混乱することはめったにありません。知りたいときは、意図した型の部分的な要約ではなく、TOAD または ACTUAL 型を提供する他のツールを使用してテーブルを説明するだけです。

[ほとんど役に立たないと言いましたが、これはおそらくあなたが探している「キラー議論」ではないことがわかりました。ハンガリー語表記法の価値であると感じる実際の理由をポイントごとに更新して質問を更新していただければ、ポイントごとに対処できると助かります。]

于 2009-06-15T11:11:16.987 に答える
2

列名に型のプレフィックスを付けない最大の理由は、単に論理名を入力するのではなく、列のプレフィックスを覚える (そして入力する) 必要がある場合に、クエリを入力するプロセスが非常に長くなる傾向があることです。 (strFirstName ではなく FirstName など)。

于 2009-06-15T11:11:39.230 に答える
0

私は何年もの間、ハンガリー語の名前付きデータベースに取り組んでいたと言おうとしていました...それはほとんど問題ありませんでしたが、何年にもわたって、数字の前に付けられたフィールドのいくつかには実際に英数字が含まれ、ブール値のフラグには含まれていませんでした。 varchars の一部が clob になり、次々と...とにかく若いプレーヤーにとって重大なトラップを表すのに十分です。

私は命名規則に実際に「間違った」ものは何もなかったし、そうも思わなかった...それは開発者が対処できる少し無力なものだ...しかし、それがほとんど価値をもたらさないことに同意する...プログラマーは一般的に非常に賢い人であり、db-schema のデータ型を記憶することは、実際にはそれほど難しいことではありません...特にシステムを長期間使用する場合はなおさらです。

全体として、私はハンガリー語の表記法を否定しますが、それを使用するシステムを継承し、新しいテーブルを作成した場合、慣例に従います...どちらにしても、私の鼻から皮を剥ぐことはありません.

彼らが泣き言を言い続けるなら、私に送ってください。たとえば、Java プログラムの PascalCase や、大文字のない定数など、実際に腹​​を立てるものを与えます ;-)

余談ですが、私はコントロール (およびコントロールのみ) に名前を付けるための VB 標準も Java に継承しました。また、Java コーディング標準に反する場合でも、共通語として機能するほど広く知られ、使用されています。

コーディング標準に関する私の精神:

  • うまくいくことは何でもしてください。
  • 少なくとも 1 つの公開された標準を読んで理解しますが、独断的に従わないでください。ポイント1を参照してください。
  • ローマにいるとき... 一貫性が「一緒にハングアップ」するための鍵です。ポイント1を参照してください。

乾杯。キース。

于 2009-06-15T11:56:02.680 に答える
0

通常、あなた、またはあなたのデータを扱う人は、データの基礎を知っている必要があります。クエリは実際には厳密な型が強制されているわけではないため、任意のクエリをパラメーター化できます。初めてクエリをテストするときは、うまくいくか失敗するかのどちらかです。修正してから次に進みます。

ビジュアル IDE での作業に関しては、オブジェクト (テキストボックス、コンボボックスなど) に共通の規則で名前を付けることを強制しない多くのショップを見てきました。私が歴史的に行ってきた多くのことは動的に生成、リンク、バインドされているため、txtFirstName、btnOk、cboStateList などのコントロールでそのようなプレフィックスを使用します。次に、コントロールの最初の 3 文字を取り除き、名前を実行時にデータ オブジェクトに自動バインドするフィールド (該当する場合)。ただし、最初に述べたように、テーブル内の列名のプレフィックスは、それが役立つよりも多くの問題を引き起こす可能性があります。

ちょうど私のドルの価値 (2 セントからのインフレ)

于 2009-06-15T11:11:50.213 に答える
0

問題は、いわゆる Apps Hungarian Notation と Systems Hungarian Notation の間にあります。前者は、持っているデータの種類に関する情報を追加します (たとえばdx、「左境界線からのピクセル数」を意味する場合があります)。一方、後者は、持っているデータの種類に関する情報を追加します (たとえばbit、を意味しますbit)。

現在のプログラミング環境とメソッドでは、使用している変数の型を調べる必要はありません。IDE とコンパイラは、間違っているかどうかを教えてくれます。したがって、これは本質的に冗長なデータであり、これらの名前からソースの (自動) 生成を開始すると邪魔になり始めます。

// just looks wrong:
public void SetSomething(bool bitPlayerHater)

Making Wrong Code Look Wrongに関する Joel の記事を読んでください。特に「私はハンガリーです」というセクション。

于 2009-06-15T11:15:06.040 に答える
0

さらに、データ型を変更する必要がある場合 (思ったよりも頻繁に発生します - Unicode に移行したばかりです)、コード全体で列名を変更する必要があります。（それは悪いことです！）:-)

于 2009-06-15T11:18:59.900 に答える