0

列を持つ「ユーザー」テーブルがあります。

USERNAME varchar(40)

「ユーザー」は、管理ユーザーまたは標準ユーザーのいずれかです。管理ユーザーには常に純粋な数字のユーザー名が含まれます。

次に、正規表現を使用して数値名を持つすべてのユーザーを引き出して管理ユーザーを取得し、その逆で非管理ユーザーを取得できます。

したがって、選択クエリで正規表現を使用してこの情報を取得することは問題ありませんか、代わりに追加の列を追加する必要があります:

MANAGEMENT TINYINT(1)

ユーザーが管理ユーザーかどうかを格納します。

ベストプラクティスとは何ですか?またその理由は何ですか?

4

2 に答える 2

3

フィールドでこの種の「隠された」意味に依存することは、実際にはあまり安全でも効率的でもありません。新しいフィールドを追加します。本当。そうしない合理的な理由はありません。

Falsehoods Programmers Believe About Namesに関するこの記事も読むことをお勧めします。

いくつかの例：

9: 人名はASCIIで書かれています。

15: 人の名前に数字が含まれていません。

24: 私のシステムは、中国からの名前を扱う必要はありません。

25: または日本。

26: または韓国。

あなたの正規表現はそれらすべてを処理できますか? 確かに？毎回？

于 2012-06-27T10:51:02.113 に答える
2

It is generally preferable to design the schema to be normalized. This includes not having multiple columns that would store the same information. However, the username and being a management user are definitely distict information and you need both.

You can use the BIT type for the new column.

In case you want to enforce particular formats of user name, the standard database solution would be to define a check constraint as follows:

ALTER TABLE YourTable ADD CONSTRAINT YourConstraint CHECK ( is_management_user = 0 OR ...)

(where the ... would include REGEXP_LIKE on Oracle, cast to an integer in TSQL or something like that).

However, MySql does not enforce check constraints and you have to emulate them using triggers if you consider the form of the USERNAME somehow important for security or operation of your application - which, I would hope, it really isn't.

于 2012-06-27T10:41:50.730 に答える