エンティティ名とテーブル名

Question

レガシーデータベース（.NET C＃を使用）を介して新しいシステムを開発します。約500のテーブルがあります。データアクセス層にORMツールを使用することを選択しました。問題は、エンティティの命名規則にあります。

データベース内のテーブルの名前は、TB_CUST - 顧客データを含むテーブル、またはTP_COMP_CARS - 社内車のような名前です。接頭辞の最初の文字はモジュールを定義し、2番目の文字は他の表との関係を定義します。

実体をより意味のある名前にしたいと思います。 TB_CUSTのようにCustomerまたはCustomerEntityだけです。もちろん、テーブル名を指すコメントがあります。

しかし、DBAとプログラマは一人で、このような名前は必要ありません。彼はエンティティ名をテーブル名と全く同じにしたいと考えています。彼は2つの名前を覚えなければならないと言っているが、それは難しくて面倒だ。私は彼に、OOPの原則に精通していないと言わなければならない。

TP_COMP_CARSのようなエンティティ名の場合は、Get TP_COMP_CARSまたはSaveTP_COMP_CARSのようなメソッド名が必要です。これは読めなくて醜いと思います。

あなたの意見を教えてください。誰が正当で、なぜそうです。

は事前

Answer 1

にORMツールの全体的なアイデアをいただきありがとうございます、データベースオブジェクトを覚えるの必要性を回避するためです。 通常、すべてのテーブル名とカラム名を持つデータベースクラスを作成するので、何も覚えておく必要はなく、ORMはデータベース "名前"を通常のエンティティにマッピングする必要があります。

それは主観的ですが、私の意見では、あなたが正しいと彼は間違っている....新しいコードで、主に仕事に行くされて

Answer 2

？その人はIMHO命名規則を決定する必要があります。

個人的にはもちろん私はあなたの解決策を考えています。すでに言及したように、ORMを使用する場合、DBを直接頻繁に使用する必要はありません。

Answer 3

妥協として、TB_CUSTのような名前を使用できます。ここではデータベースと直接連携しますが、データ転送オブジェクトにはCustomerのような名前を使用します。優れたコードを書くには、使用しているデータソースの抽象化を作成する必要があります。あなたのコード全体にGetTB_CUST()を持っているのはちょっとGetTB_CUSTFromThatSQLDatabaseWeHave()のようなものです。

Answer 4

2つの異なるドメインで使用されている命名規則は、単に整列しません。例えば、Javaでは、クラスの名前とフィールドの名前の大文字と小文字の区別が非常によく定義されています。一般的に、アプリケーションは異なる命名標準を持つまったく別のデータベースに移植される可能性がありますが、Business Logicの名前とデータベースの名前の対応を要求するのは妥当ではありません。少し複雑なマッピングを考えてみましょう.1つのエンティティが1つのテーブルに対応していない可能性があります。

ちょうどそう難しいことではありません

そして、本当に、来る...

Customer == TB_CUST 

！私はあなたと一緒にいて、ORMのコードとマップに意味のある名前をつけます。DBA /プログラマーのための学習はそれほど苦痛ではないはずです。私の推測は、それが現実よりもずっと悪いと感じるものだと思います。

Answer 5

個人的に私はこのようなテーブル名は嫌いですが、それはレガシーシステムであり、DBAはテーブルの名前を変更する気がしません。テーブルの名前を変更することもできます。新しいシステムを開発している間もレガシーシステムが稼働し続けるように、古いテーブル名を表すビューを作成するだけで済みます。これがオプションでない場合は、ORMを使用してテーブル名をエンティティ名にマップできます。または、データアクセスレイヤーでORMを抽象化して、ドメインモデルに素敵なエンティティ名を定義し、DALに名前変換を実行させることができます。

Answer 6

は、「私は

。OOPの原則に彼は本当に慣れていないと言っている。しかしTP_COMP_CARSのようなエンティティ名の場合に取得TP_COMP_CARSまたはSaveTP_COMP_CARS..Iのようなメソッド名があるはず、これは読めないと思います

あなたの意見を教えてください。誰が正しいのですか？

ITシステムが管理するものに与えられる名前は、「OOPの原則」とはまったく関係ありません。

「標準的な」ゲッターとセッターの方法には、同じ名前が与えられています。これらは単に「OOPの原則」ではなく、合意と慣例です。

問題は、ある種の「人間工学」（ひいては自己文書化値）である。

getTP_COMP_CARSが醜いように見えるのは当然です（ただし、あなたが「読めない」と主張しています）。また、「より現代的」な命名規則を遵守し始めるなら、同義の名前の間のマッピングを維持しなければならないどこかに誰かがいなければならないことも事実です。 （そして、TP_COMP_CARSのような名前は完全な「自然言語単語」の名前よりも自己記述性が低いということは間違いです。通常、そのような名前は、同じ意味で何度も何度も繰り返し使用されるニーモニック・ワード誰もが覚えておくのに十分なほど簡単です）。

これについては間違いがありません。そのような名前は、私たちが今住んでいる日の前の日常的な大会でした。少なくとも、これらの名前は、いわゆる「より現代的」なシステムによって私たちに課せられたbraindead（大文字小文字を区別する）命名規則とは対照的に、大文字小文字を区別しないという利点があります。

今から20年後、私たちは最近、 "braindead"という名前の命名規則を使用します。

Answer 7

データベースに500のテーブルがある場合、それらの名前をまっすぐに保つことにはすでに課題があります。うまくいけば、あなたはメタデータとそれらをより意味のあるものにするいくつかのグラフィカルモデルを持っています。

次の500個のORMオブジェクトを作成するときには、別の課題があります。意味のある名前を付けても、あまりにも多くのものがあり、すべてが明白になることを本当に望むことができます。だから、あなたは2つの問題があります。

2つの500個のテーブルをリンクする方法がない場合、3つの問題があります。 ORMのクエリのパフォーマンスをデバッグし、DBAが認識しない名前を使用することを検討してください。あなたの慎重に作られた名前について考えてみましょう。データベースに直接ヒットしたレポートを作成するときは無視しなければなりません。

したがって、ORMでデータベース名を使用するのは非常に難しいです。しかし、私はいくつかのものを微調整します：

• 名前があまりにもわかりにくい場合は - 私はDBAの名前を改善するために働くと思います。より良い名前に移行する簡単な方法は、ビューを通してです。理想的には、最終的にthoという元の混乱する名前を取り除きます。
• アンダースコアからキャメルケースなどに変更することは名前の変更と見なされるべきではありません。それは単なるセパレータの変更です。したがって、あなたの言語に適切な名前を使用してください。
• データベースプレフィックスはおそらく削除される可能性があります。実際には、名前が「非正規化」され、名前に移植されたテーブル名の属性です。それらがモデルのサブセクションを示すならば重複を避けるために必要であるかもしれないが、一般的に重要であるかもしれない。