ইকমার্স অর্ডার সারণী। দামগুলি সংরক্ষণ করুন, বা একটি নিরীক্ষণ / ইতিহাসের সারণীটি ব্যবহার করবেন?

Question

আমি আমার প্রথম ইকমার্স স্কিমা ডিজাইন করছি। আমি কিছুক্ষণের জন্য বিষয়টি পড়ছিলাম order_line_itemএবং একটি এবং এ এর মধ্যে সম্পর্ক সম্পর্কে কিছুটা বিভ্রান্ত হয়ে পড়েছিproduct

একটি productক্রয় করা যেতে পারে। এটির বিভিন্ন বিবরণ রয়েছে তবে সবচেয়ে গুরুত্বপূর্ণ এটি unit_price।

একজনের order_line_itemকাছে product_idক্রয়কৃত, quantityক্রয়কৃত এবং unit_priceগ্রাহক যখন পণ্যটি কিনেছিল ঠিক সেই সময়ে একটি বিদেশী কী রয়েছে ।

আমি যা পড়েছি অধিকাংশই বলছেন যে unit_priceউপর order_line_itemস্পষ্টভাবে যোগ করা (অর্থাত মাধ্যমে রেফারেন্সড না product_id)। অর্থে প্রতিবেদন, ট্র্যাকিং, অখণ্ডতা ইত্যাদি জগাখিচির করে ভবিষ্যতে স্টোরের দামটি পরিবর্তিত হতে পারে বলেই বোঝা যায় akes

আমি যে জিনিসটি বুঝতে পারি না তা কেন সরাসরি মূল্যটিকে সংরক্ষণ unit_priceকরে order_line_item?

একটি অডিট / ইতিহাসের সারণী তৈরি করা কি ভাল হবে না যা একটির unit_priceপরিবর্তনের দলিল করে product?

যখন একটি order_line_itemতৈরি করা হয়, product_auditসারণীর বিদেশী কী যুক্ত করা হয় এবং সেখান থেকে দাম পুনরুদ্ধার করা যেতে পারে reference

আমার কাছে এই পদ্ধতির (ডেটারের কম সদৃশকরণ, মূল্য পরিবর্তনের ইতিহাস ইত্যাদি) ব্যবহার করার ক্ষেত্রে অনেক ইতিবাচক বলে মনে হচ্ছে, তবে কেন এটি আরও ঘন ঘন ব্যবহার করা হয় না? আমি কোনও ই-কমার্স স্কিমাটির উদাহরণ দেখতে পাইনি যা এই পদ্ধতির ব্যবহার করে, আমি কি কিছু মিস করছি?

উদয়: মনে হচ্ছে আমার প্রশ্নটি ধীরে ধীরে পরিবর্তনশীল মাত্রা সম্পর্কিত । ধীরে ধীরে পরিবর্তনশীল মাত্রা ডেটা গুদাম এবং ওএলএপিগুলির সাথে সম্পর্কিত হলেও আমি এখনও বিভ্রান্ত। তাহলে কি ধীরে ধীরে পরিবর্তনশীল মাত্রা প্রকারগুলি আমার প্রধান ব্যবসায়িক লেনদেন প্রক্রিয়া ডাটাবেসের (ওয়ালটিপি) প্রয়োগ করা যাবে? আমি ভাবছি যদি আমি প্রচুর ধারণা মিশ্রিত করি তবে কিছু দিকনির্দেশনার প্রশংসা করব।

Comments

আমি আসলে উভয়ই করব: অর্ডার_লাইনে বিক্রয় মূল্য সংরক্ষণ করুন এবং পণ্যের দামের ইতিহাস সংরক্ষণ করুন। কারণ উভয়ই বিভিন্ন উদ্দেশ্যে পরিবেশন করে। বিক্রয় মূল্য সংরক্ষণ নির্দেশে প্রশ্নের করতে হবে অনেক সহজ এবং দ্রুত। অন্যদিকে আপনি বিক্রি না হওয়া পণ্যগুলির জন্য এমনকি পুরানো দামগুলি পুনরুদ্ধার করতে চাইতে পারেন।

— a_horse_with_no_name

অবশ্যই অর্ডার ক্যোয়ারীগুলি সহজ করে দেওয়া প্রতিবার চূড়ান্ত মূল্য সাশ্রয়ের পিছনে একমাত্র চালক হতে পারে না। এটি সর্বোপরি একটি সম্পর্কিত ডেটাবেস - ক্যোয়ারীগুলি এত বেশি শক্ত হবে না।

— গাজ_এডেজ

অর্ডার লাইনে বিক্রয় মূল্য সংরক্ষণ করা "অ-সম্পর্কযুক্ত" নয় (এবং আমি এটিকে সাধারণীকরণ হিসাবে মনে করি পাশাপাশি বিক্রয়মূল্যগুলি আমার মতে অর্ডার লাইনের প্রত্যক্ষ বৈশিষ্ট্য)। একটি রিলেশনাল ডাটাবেস ব্যবহার করার শিল্প সীমাটি জানার বিষয়ে। আপনি যদি 100 টি পণ্য এবং দিনে 5 টি অর্ডার দিয়ে একটি দোকান চালাচ্ছেন তবে পুরানো দামগুলি সংরক্ষণ এবং পুনরুদ্ধার করা কোনও সমস্যা নয়। আপনি, এবং প্রতি মিনিটে অর্ডারের hundres বিক্রেতা পণ্য লক্ষ লক্ষ হাজার হাজার সঙ্গে একটি বাজারে চালান তবে অনুসন্ধান যে ইতিহাস হবে একটি সমস্যা হতে।

— a_horse_with_no_name

আপনি ইতিহাসের দাম কোথায় রাখবেন? আমি যা পড়ছি তা থেকে আমার দুটি ডাটাবেস দরকার। ওএলএপির জন্য ওলটিপির একটি। ইতিহাস কি ওলাপে যায়?

— গাজ_এডেজ

Answer 1

যেমন আপনি সনাক্ত করেছেন, অর্ডারে দাম সংরক্ষণ করা প্রযুক্তিগত বাস্তবায়নকে আরও সহজ করে তোলে। এটি ব্যবসায়ের কারণ হতে পারে এমন বেশ কয়েকটি ব্যবসায়ের কারণ রয়েছে।

ওয়েব লেনদেনের পাশাপাশি, অনেক ব্যবসায় অন্যান্য চ্যানেলের মাধ্যমে বিক্রয়কে সমর্থন করে, যেমন:

• ফোন ধরে
• বিক্রয়কর্মীরা "রাস্তায়"
• শারীরিক অবস্থানে (যেমন দোকান, অফিস)

এই ক্ষেত্রে লেনদেন হওয়ার পরে কিছু সময় সিস্টেমে অর্ডার প্রবেশ করা যেতে পারে। এই পরিস্থিতিতে কোন historicalতিহাসিক মূল্যের রেকর্ডটি ব্যবহার করা উচিত তা সঠিকভাবে সনাক্ত করা অসম্ভব কঠিন - ইউনিটের দাম সরাসরি অর্ডারে সঞ্চয় করা একমাত্র সম্ভাব্য বিকল্প।

একাধিক চ্যানেল প্রায়শই অন্য চ্যালেঞ্জ নিয়ে আসে - একই পণ্যের জন্য আলাদা দাম। ফোনের অর্ডারের জন্য সারচার্জগুলি সাধারণ - এবং কিছু গ্রাহক নিজেরাই ছাড়ের বিনিময় করতে পারেন। আপনি আপনার পণ্য স্কিমাতে সমস্ত চ্যানেলের জন্য সমস্ত সম্ভাব্য দাম উপস্থাপন করতে সক্ষম হতে পারেন, তবে এটি আপনার অর্ডার সারণীতে অন্তর্ভুক্ত করা জটিল হয়ে উঠবে very

যে কোনও জায়গাতেই আলোচনার অনুমতি দেওয়া হয়েছে দামের ইতিহাসের সাথে সম্মত অর্ডার মূল্যের সাথে দামের ইতিহাসের লিঙ্ক করা খুব কঠিন হয়ে পড়েছে (যদি না এজেন্টদের মধ্যে খুব সংকীর্ণ আলোচনার সীমা থাকে)। আপনাকে নিজেরাই অর্ডারে দাম সঞ্চয় করতে হবে।

এমনকি যদি আপনি কেবল ওয়েব লেনদেনকে সমর্থন করেন এবং তুলনামূলক সহজ দামের কাঠামো রাখেন, তবুও কাটিয়ে উঠতে একটি আকর্ষণীয় সমস্যা রয়েছে - বিমানের লেনদেনের ক্ষেত্রে দাম বৃদ্ধি কীভাবে পরিচালনা করা উচিত? ব্যবসায় কি জেদ করে যে গ্রাহককে অবশ্যই বাড়াতে হবে বা তারা মূল মূল্যটিকে সম্মান করে (যখন পণ্যটি ঘুড়িতে যুক্ত করা হয়েছিল)? এটি যদি পরবর্তী কারণটি হয় তবে প্রযুক্তিগত বাস্তবায়ন জটিল - আপনার সেশনটিতে দামের সংস্করণটি সঠিকভাবে বজায় রেখেছেন তা নিশ্চিত করার জন্য আপনাকে একটি উপায় খুঁজে বের করতে হবে।

অবশেষে, অনেক ব্যবসায় উচ্চ গতিশীল মূল্য ব্যবহার শুরু করে। প্রদত্ত পণ্যের জন্য একটি নির্ধারিত দাম নাও থাকতে পারে - এটি সর্বদা রানটাইম হিসাবে দিনের সময়, পণ্যটির চাহিদা ইত্যাদির কারণগুলির উপর ভিত্তি করে গণনা করা হয়। এই ক্ষেত্রে প্রথম দিকে পণ্যটির বিপরীতে দাম সংরক্ষণ করা যাবে না!

Answer 2

আমি দেখেছি এমন কিছু ব্যবহারিক পয়েন্ট যুক্ত করব।

1. পণ্য ক্ষণস্থায়ী হয়।

   তারা আজকে যা বোঝাতে পারে, তারা একবছর আগে যা বোঝায় তা একই রকম নাও হতে পারে। একই স্কু কোড (এবং সেইজন্য প্রোডাক্ট_আইডি) বিভিন্ন ধরণের / পণ্যটির ধরণের বিভিন্ন স্তরে উল্লেখ করতে পারে।

   প্রত্যেকে হাতে থাকা সমস্ত উদ্বেগকে বোঝে না; অতএব কোনও ব্যবহারকারী তার নিজের অজ্ঞতা থেকে নতুন করে তৈরির পরিবর্তে আসল পণ্যটির সংশ্লেষ পরিবর্তন করতে পারেন। অনেক সময়, কোনও ব্যবহারকারী চালু হওয়ার পরিকল্পনার কারণে এটি ঘটতে পারে (আরে! আমি কেবল 100 টি স্কু পেতে পারি, তবে পরিকল্পনাটি আপগ্রেড করার পরিবর্তে পুরানোগুলিকে কেন পরিবর্তন না রাখি) সুতরাং, আপনি দেখুন অনেকগুলি গাড়িতে , কোনও পণ্য চিরকাল একই জিনিসটিকে বোঝায় না ify

2. অর্ডার এবং শিপিংয়ের শর্তের ভিত্তিতে বিভিন্ন দাম

   ব্যবহারকারী হিসাবে ক্রিস উল্লেখ করেছেন, বিভিন্ন পরিস্থিতিতে বিভিন্ন পরিস্থিতিতে প্রযোজ্য হতে পারে।

   বেশিরভাগ গাড়িতে, আপনি কমপক্ষে 3 টি আলাদা ক্ষেত্র সঞ্চিত দেখতে পাবেন - ইউনিটের দাম, ছাড়ের পরিমাণ এবং ছাড়ের দাম। আরও উন্নতমানের ক্ষেত্রে, আপনি আরও 2 টি - ইউনিটের মূল্য শুল্ক সহ, ট্যাক্সের সাথে ছাড়ের দাম পাবেন। শিপিং পদ্ধতির চার্জ এবং অতিরিক্ত অর্থ প্রদানের পদ্ধতিতে চার্জ বর্ণনা করতে আপনি আরও কয়েকটি ক্ষেত্র সন্ধান করতে পারেন। রাজ্য, পণ্য, দেশ, শিপিং পদ্ধতি এবং এর উপর নির্ভর করে শুল্কের পার্সেন্টগুলি পৃথক হতে পারে এবং অন্য খরচগুলির শিরোনামগুলিও তাই করে। একইভাবে ভূগোল, প্রচার, বিক্রয়ের সময় এবং এর উপর নির্ভর করে ছাড়গুলি পৃথক হতে পারে। অতএব, এমন তথ্য রয়েছে যা কেবল অর্ডার স্তরে পাওয়া যায়, এবং এই সম্মিলিত তথ্যগুলি কেবলমাত্র পণ্য টেবিলে ডেটা থেকে উত্পন্ন করা যায় না।

3. উদ্বেগ বিচ্ছেদ

   প্রচুর কার্ট একটি উপায়ে প্রয়োগ করা হয়, যাতে বিভিন্ন দলের তথ্যের বিভিন্ন অংশের নিয়ন্ত্রণ থাকতে পারে। অর্ডার সিস্টেম পরিচালিত কারও কারও কাছে সর্বদা এটি জানতে হবে না যে সমস্ত পণ্য কী স্টকে রয়েছে, বিভিন্ন সময়ে কী কী দাম ছিল, প্রদত্ত স্কুর বিকল্প কী কী এবং আরও অনেক কিছু। অর্ডার ডেটা সহ পণ্য সম্পর্কিত ডেটা রাখার ফলে উদ্বেগের পৃথকীকরণ অর্জনে সহায়তা করা হয়। উন্নয়নের পর্যায়েও এটি সত্য হতে পারে, যদি বিভিন্ন দল সিস্টেমের বিভিন্ন অংশ পরিচালনা করে।

4. একাধিক সিস্টেমে আরও সহজ স্কেলাবিলিটি

   অনেক সময়, অর্ডার ম্যানেজমেন্ট সিস্টেম, রুল ইঞ্জিন, ক্যাটালগ ইঞ্জিন, কন্টেন্ট ম্যানেজমেন্ট সিস্টেম এগুলি সমস্ত নিজস্ব নিজস্ব পৃথক সিস্টেম হিসাবে নির্মিত / রক্ষণাবেক্ষণ করা হয়। এটি বিভিন্ন লোডের অবস্থার জন্য অনুকূলিতকরণ এবং সিস্টেমের প্রতিটিটির জন্য বিশেষ বুদ্ধি তৈরি করতে সহায়তা করে। তখন অন্য একটি সিস্টেম থেকে তথ্য অব্যবহারযোগ্য না হওয়ার কারণে একটি সিস্টেমকে মুক্তিপণ হিসাবে ধরে রাখা যায় না।

5. দ্রুত বিকাশ এবং চলমান সময়

   আমি এখানে "বিকাশের সময়" শব্দটি ব্যবহার করেছি, যদিও "ডিবাগিং সময়" ব্যবহার করা আরও উপযুক্ত হবে। যখনই কোনও নতুন বিকাশ ঘটছে, এটির জটিলতা যুক্ত না করে প্রয়োজনীয় ডেটা উপলব্ধ থাকলে তা দ্রুত হবে, কারণ এরপরে তুলনামূলকভাবে ছোট ডিবাগিং চক্র থাকবে।

   কল্পনা করুন যে আপনাকে অর্ধ বছর পূর্বে প্রদত্ত মাসের জন্য প্রতিদিনের ভিত্তিতে ছাড়ের জন্য অন ডিমান্ড প্রতিবেদন তৈরি করতে বলা হয়েছিল। আপনার যদি মূল মূল্য থাকে তবে অর্ডার, অর্ডার আইটেমের বিশদ সহ 1-2 টেবিলের ক্ষেত্রে ছাড় মূল্য, এটি বেশ সোজা এগিয়ে। তবে, আপনাকে অন্য টেবিলে থেকে দামগুলি আনতে হবে এবং তার পরে অন্য টেবিল থেকে প্রযোজ্য ছাড় এবং তারপরে বিশদটি বের করতে হবে, বিকাশ এবং চলমান সময় উভয়ই বেশি হবে।

একটি ভাল ডিজাইনের বর্তমানের জন্য যতটা করা উচিত ভবিষ্যতের জন্য ততটাই অনুকূল করার চেষ্টা করা উচিত।

Answer 3

এটি স্টোরেজে আরও বেশি ব্যয় করতে পারে, তবে আমি লেনদেনের সাথেই বিক্রয় সম্পর্কিত সমস্ত প্রাসঙ্গিক বিবরণ রাখতে পছন্দ করি, যাতে যে কোনও কারণেই যদি আমাদের নিরীক্ষার ট্রেইলটি ভেঙে যায় বা কোনও প্রশাসক সেফটিটি জায়গায় রেখে দেয় তবে তার বিবরণ বিক্রয় যেমন: ব্যবহৃত মুদ্রা, ইউনিট-মূল্য, পরিমাণ, কর প্রয়োগ করা হয়েছে এবং তারা কী মূল্য নিয়ে এসেছিল ইত্যাদি সমস্ত উপলব্ধ। আমি সাধারণত এটি এক্সএমএল হিসাবে সঞ্চয় করি তাই এটি বিক্রয় থেকে বিক্রয়ের ক্ষেত্রে নমনীয় হতে পারে।

---

সম্পাদনা: নীচে আমার ফলোআপ মন্তব্যে আমি উপরে সংক্ষেপে যা বলছিলাম তার উপরে এবং উপরের দিকে @a_horse_with_no_name যা স্পর্শ করেছেন তা লঙ্ঘন করার জন্য, লেনদেনের ডেটা অপ্রয়োজনীয়তা কেবল গুরুত্বপূর্ণ নয়, তবে এটি পর্যায়েও প্রয়োজনীয়।

আমি ধরে নিচ্ছি যে আপনি ওওপি ব্যবহার করে তৈরি করছেন এবং সুতরাং আপনার সম্ভবত কোনও লেনদেন অবজেক্ট এবং কোনও একটি অন্তর্ভুক্ত পণ্য অবজেক্ট এবং / অথবা কোনও দামের অবজেক্ট থাকা উচিত। আমার নিজের ব্যক্তিগত অভিজ্ঞতায় আমি আমার ইতিহাসে ভার্বোজ হতে পছন্দ করি, সঞ্চয়স্থান তুলনামূলকভাবে উত্সাহিত।

আমরা যা করেছি তা হ'ল একটি অবজেক্টের ইতিহাস তৈরি করা যা আপনি আপনার বিদ্যমান আরডিবিএমএস বা এনওএসকিউএল কী মান স্টোরের কিছু গন্ধ (বা আরও ভাল কোনও আরডিবিএমএস ব্যবহার করতে পারেন যা ননএসকিউএলকে হ্যান্ডলারকেট বা মেমক্যাশের মতো সংযোগের মতো অনুমতি দেয়), এবং আমরা বস্তুর ইতিহাস সংরক্ষণ করি সহজেই এবং দ্রুত উপলভ্য এক জায়গায় প্রতিটি বিশদ এবং দামের পরিবর্তনের সাথে way আপনি যদি গুরুতর হন তবে আপনি ডিএফএফ এর স্টোরেজ বাঁচাতে এবং কেবলমাত্র পরিবর্তনগুলি সামনে রেখে সঞ্চয় করতে ব্যবহার করতে পারেন, যদিও এটির নিজস্ব ক্যাভেট রয়েছে। এটি আপনার ইতিহাসের যত্ন নেওয়া উচিত এবং সিরিয়ালাইজড অবজেক্টগুলির সুবিধা হ'ল আপনার সিস্টেমটি তাদের সংরক্ষণ করা বস্তুগুলির হিসাবে এগুলি ফিরিয়ে আনতে সক্ষম হবে / উচিত। এটি ইতিহাসের যত্ন নেয়।

আমার পরামর্শের বিষয়ে, লেনদেনের সাথে লেনদেনের বিশদ যেমন কর, মুদ্রা ইত্যাদির বিবরণ সংরক্ষণ করার অর্থ এই বিবরণগুলির জন্য অন্য কোথাও দেখার দরকার নেই, আপনার লেনদেনের বিষয়টি তার বৈশিষ্ট্য সম্পর্কে সচেতন হবে এবং আপনি যে মতামত উপস্থাপনের যত্ন নিতে পারেন আপনি উপযুক্ত হিসাবে দেখতে পৃথকীকরণের ডেটা। আপনি স্ন্যাপশটে দ্রুত অ্যাক্সেস পান এবং অপ্রয়োজনীয় এবং যাচাইযোগ্য রেকর্ডগুলির অতিরিক্ত সুবিধা পেয়ে থাকে।

এটা মূল্য, আমার বিশ্বাস!

Comments

এটি সত্যিই বলার অপেক্ষা রাখে না যে আপনি এটি ব্যবহার করেন না কারণ এটি মুছতে পারে। আপনি যে কোনও ডেটা ওভাররাইড করতে পারেন। যে কোনও কৌশলটির ব্যাকআপ রাখা উচিত

— Gaz_Edge

@ গাজ_এডজ এগুলি পারস্পরিক একচেটিয়া নয়, আপনি এখনও নিরীক্ষার ট্রেইলটি ব্যবহার করতে পারেন এবং লেনদেনের সাথে বিশদটি সংরক্ষণ করতে পারেন, এই ক্ষেত্রে অনর্থকতা ন্যায়সঙ্গত। ব্যর্থতার একক বিন্দুতে এই গুরুত্বপূর্ণ বিষয়টিকে নিজেকে ডেটা সহ কখনও ছাড়বেন না। আমাদের ক্ষেত্রে, আমি কেন্দ্রের অবজেক্ট স্টোরটিকে ইতিহাসের ব্যবস্থা হিসাবে ব্যবহার করি না বরং বস্তুর ধরণের প্রতি ইতিহাস তৈরি করার চেষ্টা করার পরিবর্তে (এই ক্ষেত্রে কোনও লেনদেন বা পণ্যের মতো)। আমি ইতিহাসে পুরো লেনদেনের উভয় জিনিসই থাকব তবে রেকর্ডে থাকা সমস্ত গুরুত্বপূর্ণ বিবরণ। ইতিহাসে পণ্য সামগ্রীর সম্পূর্ণরূপে বাদ দেয়।

— আউসিল করুন

আমি যদি আদেশে রিপোর্ট চালাতে চাই? কতটি পণ্য এক্স কেনা হয়েছে? বা y পরিমাণের উপর কত অর্ডার? এক্সএমএল হিসাবে সংরক্ষণ করার অর্থ আপনি ভুল না হলে আপনি ডেটা অনুসন্ধানের ক্ষমতা হারাবেন

— Gaz_Edge

@ গাজ_এডেজ সত্য নয়, আপনি যদি মাইএসকিউএল কথা বলছেন তবে আপনি পেয়েছেন SELECT ExtractValue(field_name, '/x/path/');যাতে নির্দিষ্ট মুদ্রায় সমস্ত লেনদেন বা নির্দিষ্ট ন্যূনতম শুল্কের মান বা যে কোনও কিছু, যেমন আপনি ফিল্টার করতে পারেন। বড় আকারের প্রতিবেদনগুলি বস্তুর ইতিহাস থেকে করা যেতে পারে। বৃহত্তর স্কেল রিপোর্টগুলির জন্য আপনি একটি elasticsearchসার্ভার / ইনস্ট্যান্স সেট আপ করতে পারেন যার বিগডাটা স্টাইল প্রতিবেদন রয়েছে এবং এটি সহজেই কয়েক মিলিয়ন ডক্স + এ স্কেল করে।

— ই

@ গাজ_এডিজ আমারও উল্লেখ করা উচিত, আপনি যে প্রতিবেদনগুলির বিষয়ে কথা বলছেন (মূল্যর চেয়ে বেশি ক্রয়, পণ্য বিক্রয় ইত্যাদি) সেগুলি সাধারণ প্রতিবেদন এবং সেগুলি দ্রুত প্রক্রিয়াকরণের জন্য লেনদেনের রেকর্ডের সাথে কলামার মান হিসাবে সংরক্ষণ করা উচিত। যে কোনও বিষয় গুরুত্বপূর্ণ তবে অগত্যা যেগুলি রিপোর্ট করা হয় তা এক্সএমএলে যেতে পারে। স্ন্যাপশট ডেটা কেবলমাত্র দুটি জিনিসের জন্য, ১. ধীরে ধীরে পরিবর্তনশীল মাত্রা ইস্যু এবং ২. গ্রাহক যখন অভিযোগ করেন তখন বৈধতা এবং তুলনা, এবং আপনাকে দ্রুত কে সঠিক তা দেখতে হবে। এটি প্রতিদিন ব্যবহারের জন্য নয়।

— ই

Answer 4

আমার ভোটটি হবে আপনার লাইন আইটেমে ইউনিটের দাম সঞ্চয় করা এবং আলাদা আলাদা টেবিলে আপনার পণ্যের মূল্য নির্ধারণের ইতিহাস ট্র্যাক করা। এটির জন্য আমার ন্যায়সঙ্গততা যুক্ত নমনীয়তার জন্য।

এমনকি যদি আপনার দামের কাঠামোটি কঠোর এবং ভালভাবে সংজ্ঞায়িত হয় এবং উপরে বর্ণিত @ ক্রিস স্যাকসন তার পরিবর্তনের জন্য অনুমতি না দেয় তবে আপনি কি আরামদায়ক হন যে এটি সর্বদা সেভাবেই থাকবে? আপনি যদি আত্মবিশ্বাসী হন তবে কেন নিজেকে এক কোণায় রঙ করুন? আমি মনে করি এটি লাইন আইটেমের বিবরণে সঞ্চয় করা ভাল ধারণা হবে কারণ আমি এটিকে আলাদা রাখার জন্য বাধ্যতামূলক কারণটি ভাবতে পারি না।

আপনার মূল্যবৃদ্ধির ইতিহাস সংরক্ষণ করার জন্য, আলাদাভাবে সংরক্ষণ করার নির্দিষ্ট মূল্য রয়েছে কারণ কোনও আইটেমের দামে পরিবর্তন হতে পারে এবং কেউ এটি কিনেছিল না। কোনও দাম পরিবর্তন কার্যকর ছিল না তা জানার জন্য এটি অবশ্যই দরকারী তথ্য। আপনি যেমনটি উল্লেখ করেছেন, এটি কোনও ডেটা গুদামের দৃশ্যে ধরণের ধীরে ধীরে পরিবর্তনশীল মাত্রার ধ্রুপদী ব্যবহারের কেস। সাধারণত আপনার পণ্যের সারণিতে যে কোনও দামের পরিবর্তন ধরা পড়বে এবং পরিবর্তনটি কখন সংঘটিত হবে তা নির্দেশ করার জন্য আপডেট দাম এবং একটি সময় স্ট্যাম্প সহ একটি নতুন সারি যুক্ত করা হবে। পূর্ববর্তী সারিতে এটির শেষের তারিখটি আপডেট করা হবে এটি নির্দেশ করার জন্য যে এটি আর কার্যকর দাম নয়। সুতরাং একটি পদ্ধতির একটি ডেটা গুদামে এই ধরণের পরিবর্তন ট্র্যাক করা হবে।

তবে, আপনি যদি নিজের ওলটিপি ইকমার্স ডাটাবেস ডিজাইনের পাশাপাশি একই সাথে ডেটা গুদাম স্কিমা এবং ইটিএল প্রক্রিয়া ডিজাইনের সাথে নিজেকে চিন্তিত করতে না চান তবে অবশ্যই এই ইতিহাসটি আমাদের ইকমার্স ডাটাবেসে ধারণ করা যেতে পারে। আপনি যেমন পৃথক product_audit সারণী তৈরির সাথে বর্ণনা করেছিলেন যেমন পণ্য সারণিটি বন্ধ থাকে এবং কোনও পণ্যের সেই সংস্করণটি কার্যকর হয় তখন তার শুরু ও শেষের তারিখ থাকে। কোন পণ্যটি বর্তমানে সক্রিয় তা নির্দেশ করার জন্য এটি সারণীতে শুরু এবং শেষের তারিখগুলি যুক্ত করে নিজেই পণ্য টেবিলে করা যেতে পারে। তবে, আপনার সংস্থাটি যে পণ্যগুলি এবং সংখ্যা বা মূল্য পরিবর্তনের মধ্য দিয়ে চলেছে তার উপর নির্ভর করে এটি আপনার পণ্য সারণীটিকে লক্ষ্যমাত্রার চেয়ে অনেক বড় করে তুলতে পারে এবং পরবর্তী সময়ে ক্যোয়ারি পারফরম্যান্স সমস্যার কারণ হতে পারে।

শেষ অবধি, লাইন আইটেমটিতে প্রকৃত ইউনিটের দাম থেকে আপনার মূল্যবৃত্তের ইতিহাসকে পৃথক করা নিশ্চিতভাবেই অন্য কিছু বিশ্লেষণমূলক সুযোগ দেখতে পারে যে কোনও পণ্য যখন সেই সময় তালিকাভুক্ত দামের উপরে বা নীচে ছিল এমন সময়ে বিক্রি হয়েছিল।

Comments

উত্তরের জন্য ধন্যবাদ. আমি মনে করি যে কৌশলটি আমি নিয়ে যাচ্ছি তা হ'ল বইটির জন্য ওলটিপি ডিজাইন করা। আমি রিপোর্ট করার জন্য ডেটা গুদাম থাকার ধারণার মতো করি। যদিও এটি কিছু অতিরিক্ত কাজ যুক্ত করে (একটি নতুন স্কিমা তৈরি করছে) স্কিমাটি ওএলএপ অনুসারে তৈরি করা যেতে পারে। যেখানে আমি একটি বৃত্তাকার গর্তে একটি বর্গক্ষেত্রের পেগ ফিট করার চেষ্টা করছি এমন দৃশ্য এড়ানো বাছাই করুন।

— গাজ_এডেজ

@ গাজ_এডেজ: আমার নতুন প্রকল্পের জন্য সিদ্ধান্ত নেওয়ার ক্ষেত্রেও আমি একইরকম পরিস্থিতিতে আছি? আপনি দয়া করে এক বছর পিছনে কী নকশার পদ্ধতির গ্রহণ করেছিলেন সে সম্পর্কে আপনার চিন্তাভাবনাগুলি ভাগ করে নিতে যত্ন নিতে পারেন? এটা কি ভাল কাজ করেছে?

— কোডার নিরঙ্কুশ

@ কোডার অ্যাসবুলেট আমার মূল সমাধানটি খুব 'ডাটাবেস' ভিত্তিক ছিল। আমার অ্যাপ্লিকেশনটি এখন পরিষেবা ওরিয়েন্টেট আর্কিটেকচারকে কেন্দ্র করে। আমার কাছে এখন একসাথে শক্তভাবে জোড়া লাগানোর চেয়ে অনেকগুলি ছোট ডিক্লোলড ডেটাবেস স্কিমার রয়েছে। একটি বৃহত্তর স্কিমা জুড়ে 3N প্রয়োজন এখন চলে গেছে। সুতরাং আমি এখন কেবল অর্ডার থেকে ইউনিট দাম যুক্ত। Historicতিহাসিক পণ্যের দামের পরিবর্তনগুলি রাখা এখন নিখোঁজ হয়ে গেছে কারণ এটি কোনও ব্যবসায়ের প্রয়োজন ছিল না। আশা করি এইটি কাজ করবে.

— Gaz_Edge

Answer 5

অর্ডার সম্পর্কিত তথ্য (প্রসঙ্গে) একসাথে রাখার প্রাথমিক ধারণার সাথে আমি সম্পূর্ণ সম্মত। কেবলমাত্র একটি গৌণ পক্ষের নোট যে আপনি যখন নিজের অ্যাপ্লিকেশনটি খুব বেশি ডাটাবেস কেন্দ্রিক ডিজাইন করছেন এবং সমস্ত কিছু বড় ফ্যাট ডিবিতে ঘোরাফেরা করেন তখনই এমন পরিস্থিতি তৈরি হবে। যদি আপনি কোনও ভিন্ন কোণ থেকে সমস্যা ডোমেনটি দেখে আপনার দৃষ্টিভঙ্গি স্যুইচ করেন তবে আপনি স্পষ্টভাবে দেখতে পাবেন যে অর্ডারটি আপনার অ্যাপ্লিকেশনটির জীবনকালীন একটি খুব বিশেষ ইভেন্টের ক্যাপচারযুক্ত স্ন্যাপশট। আপনি যখন প্রসঙ্গের ভিত্তিতে সমস্যাগুলি পরিচালনা করেন তখন ডাটাবেসের সমস্যাগুলি গৌণ ও জটিল হয়ে উঠবে যা প্রত্যেকে অনুসন্ধান করা এবং প্রতিবেদন তৈরির বিষয়ে ভীত, ডোমেন মডেলটিতে নির্বিঘ্নে পরিচালনা করা হবে।

Comments

কিছু ছোট উদাহরণ আপনার উত্তর বুঝতে আরও সহজ করে তুলবে। বিশেষত 'অর্ডার আপনার অ্যাপ্লিকেশনটির জীবনচক্রের একটি খুব বিশেষ ইভেন্টের ক্যাপচারিত স্ন্যাপশট' এর মতো বাক্য।

— dezso