常連

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

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

データベース設計について質問です。

現在、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設計]汎用区分マスタについて

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

よろしくお願いします。

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

いつも本当に助かっています。
テーブルの設計についてご意見をお聞かせください。

仕事でデータロガーのシステムというものを実装しました。
そのシステムは外部の機械から何らかのデータを受けとり、保存していくだけの単純なものですが、受け取るデータ構造を可変としています。

---

例：
- 機械Ａは 気温、湿度、気圧
- 機械Ｂは 電圧、電流
- これらのデータが各機械から１０秒毎に（23℃, 30%, 1000hPa というように）送信されるので受信し保存する。


条件：
- 機械毎のデータ定義を画面から設定する。
(何カラムあり、どのカラムが何のデータで、型は何で、有効桁数が何桁で、単位は何か、等）
- 各カラムのデータ型は真偽値、整数値、小数値、文字列がある。
- 機械Ａも機械Ｂも数千台程度接続されている。今後機械Ｃも追加される
- データを元に各機械毎のグラフを描画したり全体で集計したりする。閾値判定も行う。
- データ蓄積後、定義の変更はある程度許容する。（列の追加や単位の変更など）

---

これらを実現するためのテーブル構造の案として、下段に記載した幾つかの案などがあるかと思います。
実はもうこのシステムは「案１」で開発が終了し、問題なく稼働しています。
上記は例ですが、実際に数億レコードのデータが蓄積されています。
ただ、設計実装が私一人で周りに頼れる人もなく、設計に不安があるため、皆様のご意見をお聞かせください。

**質問１．情報が少なくて恐縮ですが、「案１」を採用したのは正解だと思いますか？
質問２．現実的な案として下段以外のものはありますか？
質問３．下段の案の中で、上記条件に対して「ありえない」と考えるものはありますか？
質問４．一般的にこういったもののデザインパターンはありますか？
質問５．他、経験談や参考情報などありましたらご教示ください。**


実際に問題なく稼働しているのだからいいじゃん、という部分もあるかと思いますが、後学のためよろしくお願いいたします。
※できるだけ広くご意見を頂きたいので少し長めに質問をオープンしておくかもしれません。

CentOS7.2, MariaDB10.0, Java8

---

### 案

**１．ID, 機械ID, キー(VARCHAR), 値(VARCHAR), 日時 のカラムを持つテーブルを用意する。**
  ※一旦値をVARCHARで保存し(小数値1.23ならそのままテキストで)、読み出し時に各定義の型に合わせて解釈します。
  ※１カラム（例えば気温）だけで１レコード消費します。
  ※閾値判定時、VARCHARカラムに対して平気で 「値 > 1.23」 のようなことをやります。
  ※１回の送信データを示す集計基準は機械IDと日時です。
  ※この案を採用しました。


**２．「定義ごとに柔軟にテーブルを作る」システムを作る。**
  ※プログラムが CREATE TABLE 文を発行します。
  ※なんだか気持ち悪いという理由と、システムが複雑化しそうという理由で却下しました。
  ※データ量は最も少なくなり運用も楽そうなため、今はこちらの方がよかったかも、と思っています。


**３．ID, 機械ID, c1, c2, c3, c4..., 日時 のようにカラムを予めたくさん用意し、カラムとデータの対応テーブルを別途用意する。**
  ※ダサく感じたので却下しました。なしではなかったなと思っています。


**４．ID, 機械ID, データ(VARCHAR), 日時のカラムを用意し、データにXML, JSON, ハッシュオブジェクトシリアライズなどで保存する。**
  ※集計と運用が厳しくなるかと思い却下しました。


**５．RDBを用いない。**
  ※RDB以外を知らないことと、集計が厳しくなると思い、却下しました。

可変データ構造をRDBに保存する方法について

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

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

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

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


メールアドレスの暗号化は必要でしょうか？

任意の順番をもったデータがあり、後からそのデータの順番を変えた場合にどのようにデータを更新すれば良いのか知恵をお貸しください。具体的には以下のような例です。

- 初期データが以下とする。

|No|名前|年齢|
|:--|:--:|--:|
|1|John|20|
|2|Bob|19|
|3|James|21|
|4|Jack|20|


- No.2のBobとNo.3のJamesの間にNickを追加し、Nickを新たなNo.3としJames以降はひとつずつNo.を増やす。

|No|名前|年齢|
|:--|:--:|--:|
|1|John|20|
|2|Bob|19|
|3|Nick|22|
|4|James|21|
|5|Jack|20|

この場合for loopなどで一つずつJames以降の値を更新する仕組みにしてしまうと、データが大量になった場合に処理量が増えてしまいます。この他にも、例えば並んだデータの順番を入れ替える上下ボタンのようなものを実装したいのですが、それも同じく時間がかかってしまう気がしています。

|No|名前|年齢|
|:--|:--:|--:|
|1|John|20|
|2|Bob|19|
|3|Nick|22|
|4|James|21|
|5|Jack|20|


- BobとNickの入れ替えボタンを押す。

|No|名前|年齢|
|:--|:--:|--:|
|1|John|20|
|2|Nick|22|
|3|Bob|19|
|4|James|21|
|5|Jack|20|


- NickとBobが入れ替わりNoが合わせて入れ替わる。

別途IDを用意して順番を管理するDBを作ることも考えたのですが結局同じことになる気がしていて悩んでおります。よろしくお願いいたします。

DB設計 順番を持ったデータの順序を更新する際の処理方法について

### 質問したいこと

私は今、データベースの勉強をしています。
ネットや書籍を中心に情報を収集しております。RDBや、DBS、SQLなど、様々な知識を学ぶことはできるのですが、１つ私の中で大きな疑問があり、その疑問については、どの媒体も説明していないように感じたので、ここで質問させていただきます。

その疑問は、「そもそも、データベースは物理的に、どのようなPCパーツ？（部品）で組み立てられていて、データはどのような手順でどこに保存されるのか」という内容です。

保存されたデータをどのように呼び出すか、データベースをどのように管理するか、などと言った知識については本当に多くの説明がありますが、例えば私が、ローカルの環境でmysqlを立ち上げ、dogsというテーブルを作成し、{name: ポチ, age: 3, owner: 佐藤さん}のようなデータを保存した場合には、何がどう動いて、この文字情報はどのように変換され、最終的にどのような部品にどう格納される？のか、といった根本的な流れに対する説明は無いように感じます。
（ローカルの環境ではなく、例えばAWSにEC2アカウントを作成し、RDSを使用した場合、RDSに上記のdogsテーブルとデータを登録した場合はローカルとどう動きが異なるのかも気になります）

恐れ入りますが、この私の疑問にご回答いただけますと幸いです。また、もし可能であれば、私はこのような「そもそも」の疑問をいつももってしまうので、このような疑問に対する回答が掲載されている書籍、サイトなどをご教示いただけると幸いです！
何卒よろしくお願いします。

そもそもデータベースって何で出来ていて、どこの何にどう保存されるのでしょうか。。

##質問内容
管理システムを作成しているのですが、マスタのサブフォームのRequery後のレコードの位置を戻したいです。

##概要
マスタにサブフォームがあり、それが帳票になっています。
マスタのフッターにある新規登録ボタンを押すと、新規にデータを登録するフォームが開きます。
そのフォームで入力後、登録ボタンを押すと、マスタのサブフォームに追加されます。
この時にRequeryをしているためか、サブフォームの先頭のレコードに移動してしまうため、この時にレコードを新規登録する前の状態にしたいです。

例えば、サブフォーム内で一番下までスクロールした状態で、新規登録をした場合、サブフォームに新しく追加され、なお一番下までスクロールしてある状態にしたいです。

現状は、新規登録フォームで登録を押したときに
```VBA
Forms!F_CustomerMaster!Sub_CustomerMaster.Requery
```
のような文を加えてあります。

この手の問題は調べると関連した記事が多く出るのですが、いまいち理解できなかったためコチラで直接質問させていただきました。

##補足
(とある方の考え方を引用)
Requeryすると先頭のレコードへ移動してしまうので
Requeryする前のレコードの番号を取得して
Requery後にそのレコード番号へ移動　

といった感じが私としては、イメージがつきやすかったです。

##追記
hatenaさんが提示してくださった感じで、追加後はサブフォームの帳票の方では、今追加したレコードをカレント？フォーカス？してある状況を作りたいです。

現状の登録フォームの登録コマンドボタンの処理です。
```VBA
'----------------------------
'登録・編集ボタン使用時
'----------------------------

Private Sub Button_Add_Click()
  
    Me.Requery
    
    '背景色（白）    
    Me.Text_CustomerName.BackColor = 16777215
    Me.Text_Address.BackColor = 16777215
    
    '未入力エラー処理　背景色（赤）    
    If IsNull(Me.Text_CustomerName) Or IsNull(Me.Text_Address) Then  '顧客名    
        If IsNull(Me.Text_CustomerName) Then        
            Me.Text_CustomerName.BackColor = 12695295            
        End If        
        If IsNull(Me.Text_Address) Then  '住所        
            Me.Text_Address.BackColor = 12695295            
        End If       
        MsgBox "未入力の項目があります", vbOKOnly + vbExclamation, "未入力エラー"
        Exit Sub
    End If
        
    '追加・編集処理分岐

    Select Case Me.OpenArgs
    
        '追加モード        
        Case "追加"       
            Call add_tables
            Call del_tables            
            MsgBox "追加しました", vbOKOnly + vbInformation, "確認"
            
            'マスタの更新            
            Dim a As String           
            a = IsNull(Me.Text_CustomerCode)          
            With Forms!F_CustomerMaster!Sub_CustomerMaster.Form
                .Requery
                .Recordset.FindFirst "F_CustomerCode = '" & 100 & "'"
            End With
            
            
            'レコード数をカウントする
            TOTAL = DCount("F_CustomerCode", "T_Customer", "F_DeleteFlag = False")
            Forms!F_CustomerMaster.Text_Num = TOTAL + "件"
            
            '採番値を+1する           
            CurrentDb.Execute "UPDATE T_Num SET F_MgtCode = F_MgtCode +1 WHERE F_TableName = 'Customer'"                        
            wFormat = DLookup("F_Format", "T_Num", "F_TableName = 'Customer'")
            wMgtCode = DLookup("F_MgtCode", "T_Num", "F_TableName = 'Customer'")            
            Text_CustomerCode = Format(wMgtCode, wFormat)
                        
        '編集モード        
        Case "編集"            
            wEdit = MsgBox("編集してもよろしいですか？", vbYesNo + vbQuestion, "確認")        
            If wEdit = vbYes Then                
                Call edit_tables           
                MsgBox "編集しました", vbOKCancel + vbInformation, "確認"                
                Exit Sub            
            Else    
                Exit Sub
            End If   
        End Select
End Sub
```
↓こちらのサイトを参考にしてみましたが、
サブフォームだけで、レコード削除したときはこちらでできたのですが、
今回の場合はうまく使えなくて・・・
[参考にしてみた記事](https://hosopro.blogspot.com/2017/10/access-form-requery-record-keep.html)