データベース設計:列挙タイプのテーブル構造設計法について、個人的に拙見
2915 ワード
列挙、1種のデータ型(C#言語に対して、もちろんJava、PHPもある)、プロジェクトの中で列挙を使うのは以下のいくつかの利点があります.
第一に、直感的な定義、使い勝手、
第二に、メンテナンスと拡張が容易(実際には直感的)
列挙タイプのデータの表示については,一般にプログラム内でこのような列挙を定義し,プログラムによって列挙に対応する
キー名、またはDescriptionAttributeタグ、またはAttributeをカスタマイズし、データバインド時に処理します.
列挙値に対応する記述情報またはキー名を表示します(これはプログラムの実行コストと計算コストを増加させます.個人的には拙見です!)
問題を見てみましょう.
注文表があり、単一のデータは注文の基礎情報を表し、注文の操作に対して、注文の状態を制限する必要があります.
たとえば、注文のステータスは次のとおりです.
1:処理しなければならない.この場合、倉庫人員が注文し、生存小包を作ることを許可し、梱包作業を行う.
2:配給待ちの場合、倉庫職員が配給書を印刷して、集荷作業を行うことができる.
3:配給中、この場合倉庫職員が注文品を選別することを許可する.
4:梱包を待つ.この場合、倉庫員は選別した品物を小包に梱包することができる.
5:重量を量って、梱包して完成して、倉庫の人員が小包に対して出荷する前の小包の重量を量って操作することを許可します.
6:出荷待ち、梱包済み、秤量完了、出荷待ち、
7:出荷済み、出荷済み、小包の物流情報を監視する
8:受領済み、ユーザーは小包を受領した(注文の最後の操作、注文の完了を示す).
私は今、文をクエリーして、直接表示し、メソッドを呼び出さずに対応する列挙のキーや説明を表示します.
私は以下のようにしました!
このようにすると、個人的にはいくつかのメリットがあると思います.
第一に、列挙はより直感的で、メンテナンスが便利で、
第二に、クエリーはチェーンテーブルのクエリーを表示します.要プログラム計算表示の場合、コストはより小さくなります.特にCPU.
スクリプトファイルはすでにアップロードされており、興味のある方は添付ファイルをダウンロードして表示できます.
个人の拙见、各位の友达を歓迎して、みんなは不足なところを指摘することを批判します!!
第一に、直感的な定義、使い勝手、
第二に、メンテナンスと拡張が容易(実際には直感的)
列挙タイプのデータの表示については,一般にプログラム内でこのような列挙を定義し,プログラムによって列挙に対応する
キー名、またはDescriptionAttributeタグ、またはAttributeをカスタマイズし、データバインド時に処理します.
列挙値に対応する記述情報またはキー名を表示します(これはプログラムの実行コストと計算コストを増加させます.個人的には拙見です!)
問題を見てみましょう.
注文表があり、単一のデータは注文の基礎情報を表し、注文の操作に対して、注文の状態を制限する必要があります.
たとえば、注文のステータスは次のとおりです.
1:処理しなければならない.この場合、倉庫人員が注文し、生存小包を作ることを許可し、梱包作業を行う.
2:配給待ちの場合、倉庫職員が配給書を印刷して、集荷作業を行うことができる.
3:配給中、この場合倉庫職員が注文品を選別することを許可する.
4:梱包を待つ.この場合、倉庫員は選別した品物を小包に梱包することができる.
5:重量を量って、梱包して完成して、倉庫の人員が小包に対して出荷する前の小包の重量を量って操作することを許可します.
6:出荷待ち、梱包済み、秤量完了、出荷待ち、
7:出荷済み、出荷済み、小包の物流情報を監視する
8:受領済み、ユーザーは小包を受領した(注文の最後の操作、注文の完了を示す).
私は今、文をクエリーして、直接表示し、メソッドを呼び出さずに対応する列挙のキーや説明を表示します.
私は以下のようにしました!
USE tempdb
GO
--
CREATE TABLE Sys_Order(
ID BIGINT IDENTITY(10000,1) PRIMARY KEY,
[Status] INT NOT NULL,
CreateDate Datetime NOT NULL DEFAULT(GETDATE())
)
GO
--
CREATE TABLE Basic_Enum_Type(
ID INT IDENTITY(1,1) PRIMARY KEY,
Name NVARCHAR(20) NOT NULL,
[LangID] INT NOT NULL, -- ID
[Desc] NCHAR(150) NULL
)
GO
--
CREATE TABLE Basic_Enum_Dict(
ID INT IDENTITY(1,1) PRIMARY KEY,
[Key] BIGINT NOT NULL,
TypeId INT NOT NULL, -- , Basic_Enum_Type ID
Name NVARCHAR(20) NOT NULL,
[Desc] NCHAR(150) NULL
)
GO
ALTER TABLE Basic_Enum_Dict ADD CONSTRAINT C_Unique_Key UNIQUE([Key])
GO
-- 。
INSERT INTO Basic_Enum_Type(Name,[LangID],[Desc]) VALUES(' ',1,'')
INSERT INTO
Basic_Enum_Dict([Key],TypeId,Name,[Desc])
SELECT 1,1,' ',' , , 、' UNION ALL
SELECT 2,1,' ',' , 、' UNION ALL
SELECT 3,1,' ',' 、' UNION ALL
SELECT 4,1,' ',' , , 、' UNION ALL
SELECT 5,1,' ',' 、' UNION ALL
SELECT 6,1,' ',' , , 、、' UNION ALL
SELECT 7,1,' ',' , 、' UNION ALL
SELECT 8,1,' ',' ( , 。)、'
INSERT INTO
Sys_Order([Status],CreateDate)
SELECT 1,GETDATE() UNION ALL
SELECT 1,GETDATE() UNION ALL
SELECT 1,GETDATE() UNION ALL
SELECT 1,GETDATE() UNION ALL
SELECT 1,GETDATE() UNION ALL
SELECT 1,GETDATE()
GO
-- , 。 、 SQL 。
SELECT
_so.ID AS OrderID,
ISNULL(_bed.Name,' ') AS StatusText
FROM Sys_Order _so WITH(NOLOCK) LEFT JOIN Basic_Enum_Dict _bed
ON _bed.TypeID=1 AND _so.Status=_bed.[Key]
このようにすると、個人的にはいくつかのメリットがあると思います.
第一に、列挙はより直感的で、メンテナンスが便利で、
第二に、クエリーはチェーンテーブルのクエリーを表示します.要プログラム計算表示の場合、コストはより小さくなります.特にCPU.
スクリプトファイルはすでにアップロードされており、興味のある方は添付ファイルをダウンロードして表示できます.
个人の拙见、各位の友达を歓迎して、みんなは不足なところを指摘することを批判します!!