お世話になります。
sqlアンチパターンの１つであるジェイウォークですが、
チェックボックスの値の格納なんかに私は結構使います。
検索条件に含まれない(mysqlなら専用の関数があります,インデックスは付けられないですが)、他テーブルと紐付いていない、対象フィールドの仕様変更の可能性が低い、という条件下で採用します。
あえて使うのは単純にテーブル構成を把握し易い、カンマ区切りで格納するとプログラム側で配列で扱いやすいなどです。特に別フィールドにしないのは配列で扱いやすくするためです。
mysqlには独自のデータ型でset型というジェイウォーク専用データ型まであります！
ジェイウォークを採用している方いますでしょうか。
逆にジェイウォークはやっぱり駄目だという方は理由を教えていただきたいです。
抽象的な質問ですが
よろしくお願いいたします
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+2
個人的意見になりますが、基本的には使いません。
使う条件
・システムの規模が小さい
・検索条件に含まれない（今後も絶対含まれない）
・他のテーブルの情報に絶対紐づかない（絶対！！）
・障害発生時に、調査対象になりえない、または、データ構成上１レコードに特定される調査になる
・そのカラムに値が設定されていなくても、プログラムが動く（デフォルト値など）
・業務プログラムなどのシステムの根幹には、関係ない（個人ごとに背景色変えたいとか）
・特定の機能のみ（画面だったら１画面限定とか、複数画面で使用しない）
・その項目の保存順が、処理に影響ないこと
・数値である、または、固定の文字列であること
使わない理由
・検索できない、または、しずらい
・値に何が設定されているかわからない（多次元配列だったら最悪）
・DB定義で回避できる（把握し安さより、その後の改修に与える影響がでかい）
・配列として扱いたいなら、group by等を使えば、SQL上で解決可能
・その後の基盤更改時などに影響がでかい（データの移行等がやりずらい）
個人的意見なので、ご指摘等あればよろしくお願いします。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+2
たまに使用します。
データ量が半端ない場合、正規化で別テーブルにすることで増加するサイズも半端なく増えます。
あくまで照会系として参照しかしないテーブルであれば、配列として折りたたんでおきます。
その他として、意図したジェイウォークということではなく、全文検索はデータをジェイウォークとして捉えて処理しているものです。
postgresは配列に対してインデックスを作成でき、配列に対する演算子も提供されるので、joinする項目としても扱うことができます。
デメリットとして考えられるのはやはり更新が絡む場合には、処理が複雑になるということでしょうか。
プログラム側で配列として扱いたいということなら、折衷案としてデータは正規化した状態で、抽出時に配列にする(MySQLであれば、GROUP_CONCAT()、postgresならarray_agg()）というのも１案ではないでしょうか。
個人的にはデータを配列で扱う事には色々な工夫の余地があると思っています。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+2
私も使わないほうがいいと思っています。
テーブル構成を把握し易い
自分が設計しているか最初から参画しているから把握しているだけで、
他人が設計したものや途中から参画した場合には把握しにくいです。
プログラム側で配列で扱いやすい
javaでやると概ね文字列になるので、おそらく扱い辛いです。
set型は例えばチェックボックスの複数選択に対応するもので、
特異にジェイウォークを推奨するものではありません。
あえて使う理由があるならば、
引継ぎした既存システムがそういう思想で作られていることが分かったら使うかもしれません。
開発目線ではなく、
運用目線で考えてもらうと使わないほうがいいと思えるかもしれません。
例えば、「1,0,3,0,0」の4番目の「0」がシステムバグで本当は「5」だった場合にパッチがすごく面倒です。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう！
- ただいまの回答率 88.10%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる
2018/01/11 14:19 編集
参照のみならアリでしょうか。
例えば、画面表示用のチェックボックスの値を格納するテーブルを作成したとして、
項目名 | 値
permission | r,w,x
みたいな形にする。
2018/01/11 15:01
チェックボックスなどの入力項目を表示する場合、
参照用であっても、登録する処理が存在すると思うので、控えた方が良いと思います。
参照用とするというのは、その時点で値が確定して、不変の値になる場合です。
permissionを例に挙げていますが、この場合も、DB上はlinuxのパーミッションのように1,2,4を足した値を格納するようにするのが良いと思います。
2018/01/11 15:27