自社業務システムDB設計メモ(仕入・発注編) - Life is Really Short, Have Your Life!!
これで一旦打ち止めです。 仕入れコピー お客様から発注が来て、それがＡというメーカーの注文のみだったとしましょう。直送可否に限らず、業務的には｢A社の納品伝票を仕入として入力｣と｢お客様に注文分の納品伝票を作成する｣という２つの業務が発生します。仕入入力の内容と納品の内容が全く同じならば、それをコピーして納品伝票を作成したいですよね！ また、仕入れの場合はメーカー伝票の伝票番号を入力して紐づけることが多いので、仕入れについては伝票番号は自動採番ではなく自由入力可能にして、一意制約もなしで。仕入IDは連番で。そんな感じで。売上伝票は連番でもオレオレルールの採番でも、ご自由に。 仕入れ単価がその時々でまちまち。同じ商品でも去年売れ残って持ち越したヤツ(キャリー品と言いますが)は安くなるし。仕入れ単価は商品に対して複数存在する。マジメに粗利を出す場合は、注文明細テーブルに仕入れ単価を入れ込む必要
自社業務システムDB設計メモ(出荷・在庫管理編) - Life is Really Short, Have Your Life!!
前回のエントリが意外とブクマされたので驚いてる。いつかこのメモたちは立派なER図になって各業務ごとにポイントを書いた素敵なPDFに姿を変えることになるでしょう。その時は資料を公開します。1万円で（え 在庫は商品のプロパティ？ そう思ってた時期が僕にもありました。最初は在庫はエンティティだという気持ちがあったのでテーブルを作ってたんですが、商品のステータスに変動して在庫を管理する必要がないので、商品テーブルと在庫テーブルを分ける意味がないという結論になりました。それが「うほ・・・」となったのが１年ほど前にお手伝いした出版流通業者さんのお仕事。同じ商品でも｢良品」と「不良」で在庫を別に分ける必要があり、かつ不良の商品が良品に戻ることがある。書籍は再販制度により、不良の商品を改装して良品扱いにすることが可能なので、良品と不良品を行ったり来たりする必要があるわけ。更に言えば改装中・断裁・献本みたい
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Exposing CQRS Through a RESTful API
