একটি বিজ্ঞপ্তি সিস্টেম বোঝা


15

আমি এসই এবং অন্য কোথাও কীভাবে একটি নোটিফিকেশন সিস্টেম তৈরি করব তা আমি সন্ধান করেছি এবং সমাধানের দিকে নিজেকে টানতে পেরেছি যা এখানে গ্রহণযোগ্য উত্তর: /programming/ এই কাঠামো:

╔═════════════╗      ╔═══════════════════╗      ╔════════════════════╗
notification       notification_object      notification_change 
╟─────────────╢      ╟───────────────────╢      ╟────────────────────╢
ID           ║—1:n—→║ID                 ║—1:n—→║ID                  
userID             notificationID           notificationObjectID
╚═════════════╝      object                   verb                
                     ╚═══════════════════╝      actor               
                                                ╚════════════════════╝

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

আমি প্রথমে ভেবেছিলাম যে আমি এই পদ্ধতির বিষয়টি বুঝতে পেরেছি, তবে আমি যখন এটি বাস্তবায়নের জন্য প্রস্তুত হতে শুরু করেছি তখন বুঝতে পেরেছিলাম যে স্পষ্টতই আমি এটি বিশেষভাবে ভালভাবে বুঝতে পারি না। উত্তরের সর্বশেষ কয়েকটি মন্তব্য হ'ল অন্যান্য ব্যবহারকারীদের প্রশ্ন যা সমাধানটি বুঝতে অসুবিধা হয়েছে।

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

প্রশ্নাবলি

যদি আমি এটা সঠিক বুঝতে, notificationObjectID করার জন্য একটি বিদেশী কী ইশারা হয় notification_object টেবিল ও notificationID নির্দেশিত একটি বিদেশী চাবিকাঠি প্রজ্ঞাপন টেবিল। দেখে মনে হচ্ছে অবজেক্টটি কোনও বিদেশী কী হওয়া উচিত যা বিজ্ঞপ্তিটি (যেমন কোনও নির্দিষ্ট ইভেন্ট বা পোস্ট) এর ডাটাবেস এন্ট্রিটির আইডি উল্লেখ করে, তবে আমাদের আইডিটি কোন টেবিলের সাথে সম্পর্কিত তা বোঝানোর জন্য আমাদের আর কোনও ক্ষেত্রের প্রয়োজন নেই?

লেখক লিখেছেন

নোটিফিকেশন_অবজেক্ট.অবজেক্ট স্ট্রিং "মৈত্রী" এর মতো পরিবর্তনের ধরণ চিহ্নিত করে, তার অতিরিক্ত ডেটা নিয়ে আমি যেটির সাথে কথা বলি পরিবর্তিত অবজেক্টের প্রকৃত রেফারেন্সটি নোটিফিকেশন_নোবিফিকেশনঅবজেক্টআইডি তে থাকে

যা আমার কাছে বোধগম্য নয়। অবজেক্টটি একটি স্ট্রিং (এনাম?) এবং নোটিফিকেশনঅবজেক্টআইডি একটি বিদেশী কী যা নোটিফিকেশনটি অবজেক্টের বিষয়ে উল্লেখ করে? তারপরে কীভাবে মাঝারি এবং ডান টেবিলগুলি সংযুক্ত রয়েছে?

দেখে মনে হয় যে মাঝের টেবিলটি নোটিফিকেশনটি কোন বস্তুর (বা বস্তুর প্রকারের) বিষয়ে নির্দিষ্ট করে, যেমন কোনও ইভেন্ট বা পোস্ট। তারপরে আমাদের বিজ্ঞপ্তি_দলে অনেকগুলি প্রবেশ থাকতে পারে যা একই অবজেক্টের ধরণের দিকে নির্দেশ করে, যা আমাদের বিজ্ঞপ্তিগুলি বান্ডিল করতে দেয় ("এক্স এর দেয়ালে পোস্ট করা" 25 ব্যবহারকারীদের মতো) - সুতরাং মধ্যম এবং ডান টেবিলগুলির মধ্যে 1: n সম্পর্ক।

তবে বাম এবং মাঝের টেবিলগুলির মধ্যে কেন 1: n সম্পর্ক রয়েছে? আমরা কি "স্যামের দেওয়ালে পোস্ট করা" 25 জন ব্যবহারকারী "এবং" মেরি তার "ফ্রাইডে পিকনিক" ইভেন্টটি একই বিজ্ঞপ্তি আইডিটি আপডেট করতে যাচ্ছি? একই ব্যবহারকারীর জন্য সমস্ত বিজ্ঞপ্তিগুলির যদি একই বিজ্ঞপ্তি আইডি থাকে, তবে আমাদের এমনকি কেন টেবিলটির প্রয়োজন হবে? বাকি?

একটি পারফরম্যান্স প্রশ্ন - বলুন জন মেরির পিকনিক ইভেন্টে একটি মন্তব্য পোস্ট করেছেন। দেখে মনে হচ্ছে যে আমরা নোটিফিকেশন_ইঞ্জিং এন্ট্রি তৈরি করার আগে মেরি পিকনিকের জন্য একটি নোটিফিকেশন_বজেক্ট ইতিমধ্যে উপস্থিত রয়েছে কিনা তা দেখার জন্য আমাদের একটি নজরদারি করতে হবে । এটি কি নেতিবাচকভাবে পারফরম্যান্সকে প্রভাবিত করবে, না এটি একটি ইস্যু নয়? পূর্ববর্তী অনুচ্ছেদ কাছ থেকে প্রশ্ন অব্যাহত, কিভাবে আমরা জানতে চাই যা প্রজ্ঞাপন এন্ট্রি নির্দেশ notification_object কিভাবে?

উত্তর:


8

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

আমি লেখার সময় মনে করি:

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

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

বিজ্ঞপ্তি "আপনার 3 বন্ধু অনুরোধ যুক্ত হয়েছে" আলাদাভাবে সংরক্ষণ করা যেতে পারে।

আপনি যদি একবারে তাদের একটি করে দেখাতে চান - আপনার কাছে 3 টি বিজ্ঞপ্তি, 3 টি বিজ্ঞপ্তি অবজেক্টস (ফ্রেন্ড_রেইকোয়েস্ট) এবং নোটিফিকেশন-এ 3 টি এন্ট্রি থাকবে যা নির্দিষ্ট বন্ধু ব্যবহারকারীর সাথে লিঙ্ক রয়েছে।

আপনি যদি একটি বিজ্ঞপ্তি দেখাতে চান - আপনার কাছে 1 টি বিজ্ঞপ্তি, 1 / আরও অবজেক্ট এবং 3 / আরও ক্রিয়া থাকবে। সুতরাং এই জটিল ক্ষেত্রে যেমন A আপনার কাছে ব্যবহারকারী এ, ব্যবহারকারী বি, ব্যবহারকারী সি 3 এর কাছ থেকে 3 বন্ধু অনুরোধ রয়েছে - আপনি প্রতিটি ব্যবহারকারীর জন্য বিজ্ঞপ্তিঅবজেক্টআইডি ব্যবহার করেন এবং আপনার বিজ্ঞপ্তি পাঠ্যে বেশ কয়েকটি লিঙ্ক রয়েছে।

আপনার 1 বা 3 বন্ধু_রেক্স অবজেক্ট ব্যবহার করা উচিত? এটা নির্ভর করে

  1. বস্তুটি কী এবং ক্রিয়াটি কী। «নিবন্ধটি কি পছন্দ / মন্তব্য করেছে»? অথবা এটি কি «লাইক / কমেন্ট যুক্ত হয়েছে» এবং অবজেক্টের হায়ারার্কি কেবল প্রদর্শনের সময় লিঙ্ক হয়ে যায়? এখানে ফেসবুকটি «ছবির মন্তব্যে ishing ব্যবহারকারীর উল্লেখের থেকে আলাদা করা হয়েছে - যা শব্দার্থগতভাবে খুব কাছাকাছি বলে মনে হচ্ছে - আপনার একই ছবি আছে, একই অভিনেতা কিন্তু বিভিন্ন বিজ্ঞপ্তি যা একসাথে একত্রীকরণ হতে পারে

এখানে চিত্র বর্ণনা লিখুন

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

অন্যদিকে, এমন কেস থাকতে পারে, যেখানে ইতিহাস থেকে কোনও কিছুই মুছে ফেলা হয় না এমন ক্রিয়াগুলির গোষ্ঠীকরণ করা কার্যকর হতে পারে।

আমি মনে করি লেখার সময় কেন, 1: n বাম এবং মাঝারি টেবিলগুলির মধ্যে সম্পর্ক তৈরি হয়েছিল - যাতে আপনি কেবল একই সত্ত্বার (মধ্য-ডান টেবিল) অভিনেতাদের দ্বারা নয় বরং বেশ কয়েকটি অবজেক্ট / সত্তা দ্বারাও বিজ্ঞপ্তিগুলি গ্রুপ করতে পারেন।

তবে নিশ্চিত, আপনি পুরো কেসটিকে সহজ করতে পারেন এবং বাম-মধ্যবর্তী সম্পর্কটিকে n: 1 এ রূপান্তর করে স্টোরেজ অনুকূলিত করতে পারেন, যাতে আপনার প্রতি ইভেন্টের জন্য প্রতি ব্যবহারকারী বিজ্ঞপ্তি তৈরি হয়।

যাতে এটি এটি আরও দেখতে হবে ..

╔═════════════╗      ╔═══════════════════╗      ╔════════════════════╗
notification       notification_object      notification_change 
╟─────────────╢      ╟───────────────────╢      ╟────────────────────╢
ID           ║←—n:1—║ID                 ║—1:n—→║ID                  
noteObjFK          entityType               noteObjFK           
viewerUserID       entityID                 actionOnEntity      
╚═════════════╝      ╚═══════════════════╝      actorUserID         
                                                ╚════════════════════╝

আশা করি এটি সাহায্য করেছে


দুর্দান্ত, এই পুরো উত্তরের জন্য ধন্যবাদ। আমি এর মধ্য দিয়ে যাব এবং আমার আরও কিছু প্রশ্ন থাকলে আপনাকে জানাতে পারি, তবে আমি মনে করি এটি বিষয়গুলিকে খুব ভালভাবে ব্যাখ্যা করে।
ব্যবহারকারী 45623
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.