作成中システムの現状について

作成中システムの現状について

作成中システムの現状について

ショップ運営が楽になるように色々と考えて構築している現在のプログラム。

DBのテーブル総数がとうとう200を超えました。

店舗運営ってそれだけ面倒な事を要求されてるわけですよね。

モールごとの記載方法に合わせたり、エビデンスのデータ揃えたり、廃盤品引き下げたり、画像のルールまで出てきました。

普段の発注/受注/梱包/出荷の業務に加えてですから少人数ではやりきれないわけです。

ネットショップ運営を楽にするためには

個人的には『しっかりしたDBの管理とDBと連動する出品システムの構築』と言うのが解答です。

その為、Excel時代から商品情報の管理を常に心がけてきました。

こういったツールをどこかの会社が作っていれば私が作る必要もなかったのですが、どこにもない。

ショップ運営者ならよくわかる通り【モールが頻繁にルール変えるから対応できない】がその原因だと推測しています。

出力カラムが増えたり減ったりするんですからね「やってられるか!」ってなりますよ。

変化に強い商品DBを構築するためには

テーブル数が200を超えた理由にもつながりますが、各情報を小分けにして保存する事だと思っています。

例えば、Amazonの様に商品サイズ(数字)だけを入れるカラムが出来た時、サイズをまとめて記載しているととても対応できません。なので、商品に絡む情報を解体して個別に格納する事がネットショップ向け商品DBの基本形体だと考えています。

そして出品する時に分解した情報をルールにのっとってまとめ上げる。

そうすればモール側がカラム構成の変更をしてきても対応できるDBを作り上げる事が出来ます。

細かすぎるDBは情報記載に時間が掛かる

先程のサイズの話で言えば、商品情報を分割して保存するより、まとめて保存した方が短時間で済みます。

メーカーから提供されるサイズ情報って大概まとまってますからね。そのままDBに投げ込んだ方が時間はかかりません。でも、【縦×横×高さ】ではなくて【縦X横X高さ】なんて表記で来ることもありますよね。こいつは手直ししなくてはいけません。そんなことを考えていると全て中身をチェックしたくなりますが、アイテム数が5000を超えるとcheckだけで1日終わったりします。

だったら、両方できるようにするか、(checkを飛ばせるように)最初から細かくするか考えなきゃいけません。

※今回のシステムでは両方できるようにしています。

まとめ

とにかく時間と労力がかかるショップ運営。

少しでも楽になるように頭を巡らせていきましょう。