「タイプ」と「クラス」は、C# や Ruby の予約語または問題のある単語である可能性が高く、将来、新しいデータベース スキーマに対してプログラミングするために使用する可能性のある 2 つの言語です。
そのため、これらの言語との潜在的な競合を回避するために、テーブルでこれらのフィールド名の代替名を探しています。
この場合、それは Machines テーブルからのもので、次のものがあります。
「class」フィールド (値は「manual」または「computerized」のようなものになります)
と
「タイプ」フィールド (値は「旋盤」または「ミル」になります)
フィールドを「machineclass」および「machinetype」と呼ぶこともできますが、それは私のスキーマの残りの部分の命名スキームと一致しません (つまり、フィールドでテーブル名を再利用しません…たとえば、Machine.name を使用します) 、Machine.machinename ではありません)
この狂気について何か考えはありますか？
冗長性を追加して、"type_id" と "class_id"、または "type_name" と "class_name" と呼ぶこともできます。
私はバイリンガル (英語とスペイン語) なので、clase = class、tipo = type を使用します。または、すべてを英語のままにしたい場合は、category = class、kind = type のような同義語を選択します。また、_v1 _v2 _v3 ... を列名に連結して、コードをより簡単に文書化するために新しい列が必要なアプリにリビジョンまたは新しいバージョンを作成します。
単純。SQL でも同様に常に発生します。選択したより大きな命名規則を破らないようにしながら、その特定の問題の命名が必要です。
私たちの命名規則（あなたのものと同じ問題が解決されています）は、このようなものを指示します. 読みやすく理解しやすいだけでなく、予約語の競合を回避していることも確認できます。
クラス
の種類
私たちはすでに持っています：
行
数
MachineClass と MachineType は間違っています。
Klass は、使用できるクラスの一般的なスペルミスです。タイプの良いスペルミスが存在するかどうかはわかりません。
Klass は Ruby On Rails で使用される可能性がありますが、よくわかりません。klass の変数を隠したくないので、klass を使用する前にそれを再確認します。
通常、_id を追加して解決します
ルックアップテーブルはMachine_Types.type_id, Machine_Types.name
簡単にMachine.type_id結ぶことができますjoin Machine_Types using(type_id)
データベースフィールドが「タイプ」または「クラス」と呼ばれることに問題はありません-少なくともC＃の観点からは。ほとんどの ORM マッパーは、'type' および 'class' と呼ばれるプロパティを持つクラスを生成しますが、これは有効です。DataReader を使用する場合は、インデクサーを使用し、フィールド名は文字列として渡されます。
データベースのフィールド名が C# キーワードと「衝突」するケースは考えられません。
優れたソリューションではありませんが、C# では大文字と小文字が区別されます。Class または Type という名前の変数またはクラスを持つことができ、クラスまたは型の予約語と競合しません。