わかりました、やりますかBusiness.Name
、Business.BusinessName
SubCategory.ID
それともSubCategory.SubCategoryID
あなたのデータベースではどうですか?
なんで?
私は両方で引き裂かれています。「正解」があればいいのに
唯一の「正しい」答えは一貫していることです。プロジェクトで使用するものを事前に決定し、それに固執します。
ID、名前などを使用する主な欠点は、2つのテーブルをオーバーラップするSQL結合を作成する場合、それらをテーブル名で修飾する必要があることです。
それにもかかわらず、IDと名前だけを使用する方がはるかに簡潔で読みやすいと思います。コードとテーブルは、目を通すのがはるかに簡単になります。入力が簡単で、冗長性が少なくなります。また、SQLクエリでSELECT Business.Name FROM ...と入力することは、SELECT BusinessNameFROM...と入力することほど面倒ではありません。
一般に、セマンティック情報を繰り返していることに気付いた場合は、それを排除する方法を探すか、少なくとも繰り返される理由を認識するように警告されます。これは、小規模(属性名)または大規模(動作パターンまたは一般的なクラス構造)である可能性があります。
「名前」や「ID」などの非常に一般的なプロパティの場合、私が使用した規則は、フィールドにエンティティ名を入力しないことです。もっと珍しいプロパティのために、私はエンティティ名を入れます。
これは命名規則の決定ですが、これが慣習であるプロジェクトを後悔していません。各IDにエンティティの名前を付けると、冗長すぎるように見えます。
主キーであるものすべてに対してIDを実行します。SubCategory.SubCategoryIDと言うのは冗長なようですが、
私は正しくないかもしれませんが、ID の方がおいしい料理だと思います。
オブジェクトを処理し、主キーが必要なリフレクティブなものを作成する場合は、どこでも簡単に知ることができ、式で決定しようとするためです。
もう1つは完全な好みであり、他の文字とその.netを入力するのに無駄な時間を費やす以外に実際の影響は見られないため、とにかく実際に名前空間を入力する人はいません。