常連

**データ型や命名規則ではなく単なる英語表記に関する質問です。**
・カラム名でいつも悩むのですが、「投稿日時」と「更新日時」のカラム名はどういう名前にするものでしょうか？

**Google翻訳**
・それぞれ「post_time」「date_modified」となり、今一分かりにくいような気もするのですが…

**その他**
・好きに付ければ良いとは思うのですが、なるべく誰でも分かりやすいカラム名にしたいので、…

「投稿日時」と「更新日時」の英語表記は？

現在、ACCESSを用いて会社内での従業員管理を行おうとしております。
「組織テーブル」と「従業員テーブル」を関連づける際の考え方について御意見をお聞かせいただければと思います。

### 前提

「組織テーブル」と「従業員テーブル」を関連づける際に![イメージ説明](https://ddjkaamml8q8x.cloudfront.net/questions/2023-10-15/ca66701e-d980-44b4-ae0c-597a64668bb1.png)
のような構成を考えたのですが、これだと所属部署が消滅したりすると紐づいている従業員の行き場が無くなります。
組織変更や従業員の異動などに、柔軟に対応できる構成にしたいのです。

そこで、![イメージ説明](https://ddjkaamml8q8x.cloudfront.net/questions/2023-10-15/342298a0-0328-48a3-9029-ee54d1d7aa70.png)
のように中間テーブル？を置いて対応しようと思いました。

### 質問

1.　このような中間テーブルを置くような構成は一般的に用いられるのでしょうか？　
　　　もっとよいテーブル構成があったら教えてください。
　　

2.　このような中間テーブルを置くと、このテーブルでレコード数がかなりの数になります。
　　(単純計算で【「部署数」×「従業員数」×「変更数」】)
　（表現が難しいのですが）そういうもの、と割り切って考えるものなのでしょうか？

よろしくお願いします。

どのようにテーブルを設計するべきか

### 実現したいこと
（タイトルがわかりにくくてすみません）
Model_A と Document とモデルがあり、1対N のリレーションになってます。
```
SELECT * FROM DOCUMENTS;
 id | model_a_id | summary | deleted_at | created_at | updated_at 
----+------------+---------+------------+------------+------------

\d documents;
                                           Table "public.documents"
    Column     |              Type              | Collation | Nullable |                Default                
---------------+--------------------------------+-----------+----------+---------------------------------------
 id            | bigint                         |           | not null | nextval('documents_id_seq'::regclass)
 model_a_id    | bigint                         |           | not null | 
 summary       | character varying              |           |          | 
 deleted_at    | timestamp(6) without time zone |           |          | 
 created_at    | timestamp(6) without time zone |           | not null | 
 updated_at    | timestamp(6) without time zone |           | not null | 

```
（例としては、Model_A が一軒家のデータで、それに設計図やら申請書やらなど複数書類をDocument として紐付けることができる、みたいな感じ）

これを元に新たに、Model_B、Model _C の追加を考えてます。各モデルはカラムが違いすぎて、モデルを共通化できないことを前提とします。
（例としては、Model_B がマンション、Model_C が工場のデータだけど、設計図、申請書などの複数書類を紐づけるやり方は Model_A と同じでよい）

つまり、Document 側からは、複数のテーブル相手に1対N のリレーションで紐づけられるようなものです。

このような設計方法にセオリーみたいなのはありますか？

### 思いついたこと

一つの方法（※）は、documents テーブルにカラムを追加するやり方です。
```
SELECT * FROM DOCUMENTS;
 id | model_a_id | model_b_id | model_c_id | summary | deleted_at | created_at | updated_at 
----+------------+------------+------------+---------+------------+------------+------------
```
こんな感じです。model_a_id、model_b_id、model_c_id の not null 制約は外します
Model_*が増えるたびに、テーブルにカラムを追加してしていかなければならないので、現実的にはModel_*がどこまで増えるのかの、見通しを考える必要があります。
他方、現状の変更が楽そうな気がしてます。

つぎの方法は、中間テーブル（っぽいもの）をつくるやり方です。
N対N そのものではないのでまだ具体的な実現方法は考えてません。（Active Storage が参考になるかな？程度）

### 該当のソースコード
上記（※）について、Ruby on Rails の場合でどうすればいいのかわからないところ（？の部分）を掲載します

これが
```ruby
class Document < ApplicationRecord
  belongs_to :model_a
  has_one_attached :file
end

class ModelA < ApplicationRecord
  has_many :documents, dependent: :destroy
end
```
こう？
```ruby
class Document < ApplicationRecord
  belongs_to :model_a (?)
  belongs_to :model_b (?)
  belongs_to :model_c (?)
  has_one_attached :file
end

class ModelA < ApplicationRecord
  has_many :documents, dependent: :destroy
end
class ModelB < ApplicationRecord
  has_many :documents, dependent: :destroy
end
class ModelC < ApplicationRecord
  has_many :documents, dependent: :destroy
end
```

### その他

回答としては、この設計方法自体よくないから破棄しなさい、というのでも結構です。（その場合、その回答にたくさんグッドが集まれば、いかに自分の質問が道から外れてるかがわかるので）

1対Nのテーブルだけど、「1」が複数ある場合の設計方法

## テーマ、知りたいこと

エンジニア初学者への対応

## 背景、状況

エンジニアインターンでの体験です。

私は都内の小さなスタートアップ企業でエンジニアの有給インターンシップを行なっている大学3年生です。働き始めてかれこれ４ヶ月になります。所属学部は文学部史学科であるものの、私はエンジニア職に興味があったので、未経験・文系でも応募可能なインターンに複数応募し、今の企業に採用していただいた運びになります。

これまで私が行なってきた業務としては、いわゆる新人研修、テスター業務といった誰でもできるものでした。新人研修ではprogateを使った簡単な言語の勉強、簡単なAWSの使い方そして、情報リテラシーに関する注意喚起動画等を受講いたしました。テスター業務は既に開発済みのアプリやシステムを決められた手順で操作を行い、正常に挙動するかどうかを確かめる、といったものでした。

ここまでは、私が初心者であることを考慮して、できることから業務を振ってくれていたと実感しております。

しかし昨日急にうちの会社が進めているプロジェクトのデータベース設計業務を任されることになりました。これが有識者の上司と２人、二人三脚での業務とかであれば全く問題がないのですが、私ともう一人のインターン生（おそらく情報系の学部所属なので少なくとも私よりは理解度がある。）の二人がこの業務を担当することとなり、データベースのデの字も知らない私は、SQL、DB関連の参考書を４冊程渡され、次回の出勤日までにインプットしてくるように言われました。meetingにも参加し、どのような設計を行うか等の説明を受けたのですが、専門用語が飛び交い、はっきりいって何が何だかわからず、自分が向かう先も、果たして自分がこの業務を遂行できるのかさえも不安になってきました。

唯一の救いは、（私と業務を行う方とは別の）同じインターン生の中に知識が豊富な人間がいます。彼は自分の直接的な業務でこそないものの、僕の置かれている状況を鑑みてアドバイスをくれるので、彼がいることが唯一の救いです。

話が長くなってしまいましたが、エンジニアの業界ではこうしたアサインの手法（初心者をプロジェクトにアサインする）はよくあることなのでしょうか？自分で調べて自分で解決するのがエンジニア職の主流であることは百も承知なのですが、それにしてもなにが正解で何が不正解かがわからない初心者に対してこのような形で仕事を振るというのはどうなのでしょうか？

私個人としては、初学者の身であるため「来るもの拒まず」のスタンスではあります。なので今回のアサインに関しても嬉しくないことはないのですが、あまりにも急というか放任主義なので困惑している次第でございます。

ご回答お待ちしております。



エンジニア初学者への対応

### 実現したいこと

```sqlite3.exe
CREATE TABLE "user" (
	"user_id"	INTEGER,
	"user_name"	TEXT,
	"prefecture_id"	INTEGER,
	PRIMARY KEY("user_id" AUTOINCREMENT)
);

CREATE TABLE "prefecture" (
	"prefecture_id"	INTEGER,
	"prefecture"	TEXT UNIQUE,
	PRIMARY KEY("prefecture_id" AUTOINCREMENT)
);
```

このような2つのテーブルがあるとします。

この時
user_name='山田'
prefecture='東京都'
というデータを挿入したいです。
（追加するデータの形式はPowerShellのハッシュテーブルを想定しています）


### 試したこと
```sqlite3.exe
INSERT OR IGNORE INTO prefecture (prefecture) VALUES('東京都');

INSERT INTO user (user_name,prefecture_id)
VALUES ('山田',(SELECT prefecture_id 
FROM prefecture 
WHERE prefecture = '東京都'));
```
このようにしてまずprefectureテーブルに都道府県のデータがなければ追加して
その後prefecture_idを取得してそれをuserテーブルに書き込む、
これで目的の操作はできるのですが
これだとテーブルが分けられているデータの数だけ1つめのINSERTを実行しないといけませんし
2つめのINSERTもその分だけ複雑化してしまいます。

第一正規形のテーブルであれば
INSERT INTO user (user_name,prefecture)
VALUES ('山田','東京都');
これで簡単にデータが追加できますが
これぐらい簡単な方法で正規化されたDBにデータを追加する方法はありませんか？




### 補足情報（FW/ツールのバージョンなど）

Windows 10 64bit
sqlite3.exe version 3.41.1
PowerShell 7.3.4


SQLiteで正規化されたDBにデータを追加したい

### 前提

初投稿の初心者です。
技術向上を兼ねて趣味でゲームのキャラクターのデータを比較できるシステムを作ろうと思い、まずはデータベース作成を行っています。

その中の多対多のテーブルの設計でどうすればよいかわからないところがあり助言をいただきたいです。


### 問題のテーブル設計
例として各キャラは複数の装備枠があり、各装備枠には装備できるものが決まっています。
以下のように複数種類の装備の選択も可能です。

**キャラテーブル**
|キャラid|キャラ名|右手装備|左手装備|
|:--:|:--:|:--:|:--:|
|1|太郎|長剣or槍|盾|
|2|次郎|短剣|短剣|
|3|三郎|長剣or弓矢|盾|

**装備テーブル**
|装備id|装備名|
|:--:|:--:|
|1|長剣|
|2|短剣|
|3|弓矢|
|4|槍|
|5|盾|

この場合どのように２つのテーブルのリレーションを組めばよいでしょうか？
装備枠に対して１種類しか対応する装備がなければ中間テーブルを作ればいいかと思いましたが、装備枠に対応する装備が複数あるのでこれを解消する手が思いつきませんでした。

幸いにして複数の装備を選択できてもそのパターンは多くないので装備テーブルに以下のように追加するのも手でしょうか？

**装備テーブル改**
|装備id|装備名|
|:--:|:--:|
|1|長剣|
|…|…|
|5|槍|
|6|長剣or槍|
|7|長剣or弓矢|

現時点での構想としてはどのキャラがどの装備枠に何を装備できるかがわかればいいと思っています。

【データベース設計】多対多のテーブルのリレーション

データベース設計について質問です。

現在、Webシステムの基本設計段階で
「汎用区分マスタ」というテーブルを設計しています。

・多言語対応するために、一つの区分値に対して
 複数の言語での名称を登録する必要がある
・今回は日本語対応のみ
・現在は「マスタを更新しない、参照のみの区分」しか存在しない
・将来的にはカスタマイズでマスタメンテ画面を追加し、
 区分や区分値が更新対象になる可能性がある
という前提です。

開発環境は
言語：Java,JavaScript
DB：SQL Server
です。

過去に他の案件で使用していた同じ役割のテーブルを参考に
現在は下記のようなテーブル定義になっています。

分類コード	varchar(30) PK
区分値	varchar(30) PK
言語コード	varchar(3) PK
表示名	nvarchar(100) NOT NULL
表示順	smallint NOT NULL
備考	nvarchar(200)
予備項目1	nvarchar(200)
予備項目2	nvarchar(200)
予備項目3	nvarchar(200)
削除フラグ	bit
登録日時	datetime2
登録者ID	nvarchar(20)
登録APP	nvarchar(50)
更新日時	datetime2
更新者ID	nvarchar(20)
更新APP	nvarchar(50)

例えば、課税区分と国なら（一部抜粋）
分類コード	区分値	言語コード	表示名	表示順
KAZEI_KBN	1	JPN	内税	1
KAZEI_KBN	2	JPN	外税	2
KAZEI_KBN	3	JPN	非課税	3
KUNI_KBN	AD	JPN	アンドラ	16
KUNI_KBN	AE	JPN	アラブ首長国連邦	8
KUNI_KBN	AF	JPN	アフガニスタン	5
 ・
 ・
 ・

といったデータを格納します。

自分で調べてみたのですが

■メリット
・マスタメンテ画面が1つで済む
・分類コードの条件を変更すれば複数の機能や画面で表示名の取得SQLを使用できる
・個別のマスタを持つよりテーブル数が少なくなる
・新しい分類が増えてもテーブルを増やさなくて良い

■デメリット
・データの件数が多くなり、検索コストが上がる
・テーブルのレコードを見ないとどんな値を保持しているかわからない
・余裕を持って桁数の大きい項目や、予備カラムを用意している分データ容量が増える

というような内容しかわからず、個人的な感覚としては
「テーブルの数が増えても、個別のマスタを準備した方が良いのでは？」
と思うのですが、上手く説明できません。

なんとなく、個別マスタを持った方が良い条件は
・複数の画面でドロップダウンリストに表示する
・区分と名称以外の項目（上位分類など）がある
・専用の区分値更新処理（他システムからの連携、マスタメンテ画面など）がある
・区分値の有効期限がある（キーに期間の情報を持たせる）
かな？と思っているのですが
・それ以外の「主に区分値と名称の表示しか使用しない区分」は
 全て汎用区分マスタにつっこんでしまえば良いの？
・将来マスタメンテ画面が出来た場合を考えると
 できるだけ汎用区分マスタを使用した方が良いの？
・予備カラムって無駄じゃないの？
 どんなデータが入るかわからないから桁数を
 大きめに持っておくのってどうなの？
といった疑問が湧いてきます。

私にとって、初めてのデータベース設計で困っています。
区分値のマスタテーブルはどのように設計すればよいのでしょうか？

解説、経験談（設計・開発）もあればお願い致します。
このようなテーブル設計について参考になるサイトや書籍などがあれば
教えてください。
宜しくお願い致します。

[DB設計]汎用区分マスタについて

よくある形態のWebメディアを開発しており、
キャンペーンやメルマガの配信にメールアドレスを収集しております。
※メールアドレスで会員登録しています

データベースに保存する際、メールアドレスを暗号化するのは一般的なのでしょうか？
上司から「メールアドレスは個人情報だから暗号化して保存しないと」と言われたのですが、
これまで上場企業のシステムなど複数携わったことがありますが、
会員登録時にメールアドレスを暗号化して保存しているシステムに出会ったことがありません。

「暗号化しないよりはした方がいい」というのは分かりますが、
複合化や検索時のデメリットを考えると「本当に暗号化する必要性はあるのだろうか？」と思ってしまいます。

私のセキュリティ感覚に問題があるのか、今回がレアケースなのか、
皆さんのご経験などを踏まえてご教授頂けますと幸いです。
