Accessの商品マスタをPHP・MySQLへ移した――まだ「引っ越し段階」の食品表示DB

現在動いている商品情報データベースは、最初から理想的な設計で作ったものではありません。

関連情報：商品マスタ・一括表示・製品規格書を一つのデータへ――取引先別書式との向き合い方

Accessで管理していた項目と操作を、まずPHPとMySQLへ移しました。業務を止めず、ブラウザから閲覧・編集できる状態にすることを優先したためです。

関連情報：なぜブラウザベースにこだわるのか――工場のPC・タブレット・OS依存を減らす設計

現在の商品マスタにある主な項目

• 供給者・ファイル名
• 商品名・商品ジャンル
• 原材料リスト
• 内容量・賞味期限・保存方法
• 製造者・住所・電話番号
• JANコード
• リサイクル表示
• 栄養成分・アレルゲン
• Brother用ラベルテンプレート名
• 注文ID・ロット番号・フォーム名

一覧、検索、編集、複製、削除、CSV出力、JANコード生成などを持たせています。

一枚表の便利さと限界

一つの表に必要な項目が並んでいるため、一覧性はあります。しかし、原材料や包装資材を文字列として持つだけでは、次の処理が難しくなります。

• 原材料の変更が複数商品へ与える影響を調べる
• 複合原材料を展開する
• 添加物を表示ルールに従って並べる
• アレルゲンを原料から集約する
• 同じ包装資材を使う商品を検索する
• 規格書の版を管理する

つまり、現在のWeb版はAccessを離れることには成功しましたが、商品情報モデルの再設計はこれからです。

先に引っ越したことにも意味がある

全面的に設計し直してから移行しようとすると、開発規模が大きくなり、現場業務を行いながらでは完成しません。

そこで、段階を分けました。

1. Accessの項目と基本操作をWebへ移す
2. 商品情報を一か所から閲覧できるようにする
3. 印刷履歴やJANなど周辺機能をつなぐ
4. 原材料・表示・規格書を別テーブルへ分解する
5. 誰でも使える作成画面へ置き換える

「引っ越し段階」と書くのは、完成度を低く見せるためではありません。実際の業務を止めず、長年の仕組みを少しずつ置き換える現実的な方法だったからです。

この連載の記事

1. 第1回：ツールから選ぶと沼にはまる――小規模食品メーカーがAccessからブラウザDBへ進んだ理由
2. 第2回：食品表示と規格書をExcel・Accessで管理する限界――転記が増え続ける理由
3. 第3回：kintone・FileMaker・Exment・規格書サービスを検討して分かった――構想から逆算するツール選び
4. 第4回：なぜブラウザベースにこだわるのか――工場のPC・タブレット・OS依存を減らす設計
5. 第5回：Accessの商品マスタをPHP・MySQLへ移した――まだ「引っ越し段階」の食品表示DB
6. 第6回：在庫管理で検証したBrotherブラウザ印刷を、一括表示ラベルへ転用できるか
7. 第7回：何枚印刷したかを残す――ラベル履歴・ロット・商品情報を結ぶ設計
8. 第8回：一括表示を「私しか作れない」から「誰でも作れる」へ――食品表示DBの再設計
9. 第9回：商品マスタ・一括表示・製品規格書を一つのデータへ――取引先別書式との向き合い方
10. 第10回：AIで長年の構想が動き出した――食品現場と技術を横断して組み立てる小規模DX