বিভিন্ন টেবিল থেকে ডেটা একের মধ্যে সংগ্রহ করা কি খারাপ অভ্যাস?


12

পটভূমি

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

সমস্যাটি

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

আমার "সমাধান"

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

টেবিলটি পাতলা এবং লম্বা হবে, কেবলমাত্র প্রয়োজনীয় ডেটা সংরক্ষণ করে, এরকম কিছু:

CREATE TABLE dbo.HCM_Event_Log (
    id INT IDENTITY,
    type_id INT NULL,
    orig_id VARCHAR(36) NULL,
    patient_id UNIQUEIDENTIFIER NOT NULL,
    visit_id UNIQUEIDENTIFIER NULL,
    lookup_id VARCHAR(50) NULL,
    status VARCHAR(15) NULL,
    ordered_datetime DATETIME NULL,
    completed_datetime DATETIME NULL,
    CONSTRAINT PK_HCM_Event_Log PRIMARY KEY CLUSTERED (id)
)

তারপরে টাইপ_আইডি এবং আইটেম গ্রুপিংয়ের মতো জিনিসের জন্য আমার কাছে বিভিন্ন সম্পর্কিত টেবিল থাকবে।

আমি এই ধারণাটিকে দ্বিতীয় ভাবাতে শুরু করছি কারণ এই টেবিলগুলির বেশ কয়েকটি বেশ কিছুটা লেখা হয়েছে, এসপি এবং প্রতিবেদনগুলি আমি লিখতে চাইছি পাশাপাশি ডেটাও অনেকটা রেফারেন্স করবে। সুতরাং আমি উদ্বিগ্ন যে এই টেবিলটি এত বেশি I / O দিয়ে একটি রেকর্ড লকিং এবং পারফরম্যান্স দুঃস্বপ্নে পরিণত হবে।

আমার প্রশ্ন

একটি খারাপ বা একটি ভাল ধারণা? আমি বুঝতে পারি যে এসকিউএল সার্ভারে (২০০৮ r2 স্ট্যান্ডার্ড সংস্করণ বিটিডাব্লু) এবং "কখনও কখনও" নিয়মে প্রতিটি পরিস্থিতি আলাদা but তবে আমি সত্যিই কেবল সাধারণ পরামর্শ খুঁজছি।

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


1
আপনি কি পরিকল্পিত আউটজেস কার্যকর করতে পারেন? যদি এই আপডেটগুলির মধ্যে একটি নাও একটি ট্রিগার মুছে ফেলতে পারে এবং আপনি আপনার সমষ্টিগুলি আপডেট করবেন না সম্ভবত খারাপ ডেটার দিকে নিয়ে যাবে।
এরিক

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

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

দেরিতে জবাব দেওয়ার জন্য দুঃখিত, প্রতিক্রিয়াটির জন্য ধন্যবাদ। @ এরিক - হ্যাঁ, আমরা আপডেটের পরিকল্পনা করেছি এবং আমি চালাচ্ছি এমন চেকলিস্ট স্ক্রিপ্টগুলির একটি সিরিজের মাধ্যমে আমার পূর্বের সমস্ত পরিবর্তনগুলি এখনও স্থিত রয়েছে তা নিশ্চিত করতে আমি পরীক্ষা করে দেখি, সেখানে কোনও আশ্চর্য হওয়ার দরকার নেই এবং আমি এর জন্য ক্রিপ্ট স্ক্রিপ্টগুলি রাখব সমস্ত ট্রিগার।
jreed121

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

উত্তর:


8

যদি আমি আপনাকে সঠিকভাবে বুঝতে পারি,

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

আমি এটির মতো এটির কাছে যাব:

  • আমার নিজস্ব পৃথক ডাটাবেস সেট আপ করুন, যার আমার সম্পূর্ণ নিয়ন্ত্রণ রয়েছে।
  • একটি সিঙ্ক প্রক্রিয়া সেট আপ করুন যা তৃতীয় পক্ষের ডাটাবেস থেকে প্রাসঙ্গিক টেবিল এবং কলামগুলি থেকে ডেটা এবং খনিতে সন্নিবেশ / আপডেটগুলি পড়ে।
  • আমার ডাটাবেসের স্থিতিশীল কাঠামোর ভিত্তিতে আমার জটিল প্রতিবেদনগুলি বিকাশ করুন।

এই ক্ষেত্রে আপনি তৃতীয় পক্ষের সিস্টেমকে প্রভাবিত না করে আপনার প্রতিবেদনের পারফরম্যান্স উন্নত করতে আপনার ডাটাবেসের কাঠামো এবং সূচকগুলি সূক্ষ্ম-সুর করতে পারেন। মূল ডেটা কাঠামো নাটকীয়ভাবে পরিবর্তিত না হলে তৃতীয় পক্ষের ডাটাবেস পরিবর্তিত হলে আপনার প্রতিবেদনের জন্য আপনার প্রশ্নের যুক্তি পরিবর্তন হবে না। আপনাকে কেবল সিঙ্ক প্রক্রিয়াটি সামঞ্জস্য করতে হবে।

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

সুতরাং, মূল বিষয়টি হ'ল - আপনার সিস্টেমের সেই অংশটি পৃথক করুন এবং এটি সীমিত করুন যা তৃতীয় পক্ষের সিস্টেমের অভ্যন্তরের উপর নির্ভর করে।

হালনাগাদ

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

আপনি ইতিমধ্যে মূল সারণিতে পরিবর্তনগুলি ক্যাপচার করতে ট্রিগার লিখতে এবং এই পরিবর্তনগুলি একটি জেনেরিক টেবিলে লেখার ইচ্ছা নিয়েছেন। সুতরাং, আপনার ইচ্ছা অনুসারে পরিবর্তনগুলি ক্যাপচার করুন, তবে সেগুলি একটিমাত্র নয়, যথাযথভাবে সাধারণ টেবিলগুলিতে লিখুন।

সুতরাং, এটি চরম ক্ষেত্রে - তৃতীয় পক্ষের ডেটা স্ট্রাকচারকে আপনার অভ্যন্তরীণ ডেটা স্ট্রাকচারে রূপান্তর করা INSERT/UPDATE/DELETEতৃতীয় পক্ষের টেবিলগুলিতে আগুন লাগিয়ে দেয় in এটা কৃপণ হতে পারে। ট্রিগারগুলির কোড উভয় সিস্টেমের অভ্যন্তরীণ কাঠামোর উপর নির্ভর করবে। যদি রূপান্তর অ-তুচ্ছ হয় তবে এটি INSERT/UPDATE/DELETEতাদের ব্যর্থতার বিন্দুতে মূল বিলম্ব করতে পারে । আপনার ট্রিগারে যদি কোনও বাগ থাকে তবে এটি তাদের ব্যর্থতার দিক থেকে মূল লেনদেনকে প্রভাবিত করতে পারে। যদি তৃতীয় পক্ষের সিস্টেম পরিবর্তন হয় এটি আপনার ট্রিগারটি ভেঙে দিতে পারে, যার ফলে তৃতীয় পক্ষের সিস্টেমের লেনদেন ব্যর্থ হতে পারে।

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

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


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

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

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

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

3

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

অন্যরা যেমন উল্লেখ করেছে, ট্রিগারগুলি ব্যবহার করবেন না, ব্যাচে সিঙ্ক করুন।

প্রচুর যোগদানের বিষয়ে চিন্তা করবেন না, যখন ডেটা স্বাভাবিক করা হয় এবং সঠিকভাবে ইনডেক্স করা হয় এগুলি কোনও উল্লেখযোগ্য ব্যয় বা পরিচালনার বোঝা যুক্ত করে না।

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


3

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

ইতিবাচক দিক থেকে:

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

কনস আছে, যদিও:

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

2

আমার পরিকল্পনাটি ছিল এই সমস্ত রেকর্ডটি একটি "ক্যাচ-অল" টেবিলটিতে লেখার, এবং এই সামগ্রিক সারণীতে রেকর্ড বজায় রাখতে মূল টেবিলগুলিতে ট্রিগারগুলি লিখতে হবে।

ট্রিগারগুলির এতগুলি সমস্যা রয়েছে যা আপনার এড়ানো উচিত:

  • ট্রিগারটিতে একটি ত্রুটি আসল লেনদেন বাতিল করতে পারে
  • ট্রিগারগুলি যেগুলি মাল্টি-সারি ক্রিয়াকলাপগুলি সঠিকভাবে পরিচালনা করে সেগুলি লেখা শক্ত
  • ট্রিগাররা ক্লায়েন্ট অ্যাপ্লিকেশনগুলিকে ফেরত রোউসেটটি সংশোধন করে বিভ্রান্ত করতে পারে (উদাহরণস্বরূপ, একটি ট্রিগার প্রভাবিত সারিগুলির সংখ্যাকে ওভাররাইড করে)
  • যখন একটি ট্রিগার অন্যটি ট্রিগার করে, ফলাফলগুলি অনুমান করা শক্ত

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


1. ট্রিগারগুলি সহজ হবে, তাই নিক্ষেপ করা ত্রুটিগুলি সর্বনিম্ন ন্যূনতম হবে। ২. ট্রিগার নিজেই একাধিক সারি হ্যান্ডেল করবে না (যেমন ট্রিগারটির সাথে টেবিলের এক সারি আপডেট হওয়া একাধিক সারি অন্য কোথাও আপডেট হতে পারে না), তবে একাধিক সারি উত্সটিতে একবারে সন্নিবেশ / আপডেট / মুছে ফেলা হতে পারে টেবিল - এই আপনি কি বলতে চাইছেন? ৩. এটি কি সামলাতে পারত না NOCOUNT? ৪. গন্তব্য টেবিলে কোনও ট্রিগার থাকবে না এবং আমি অন্যদের জন্যও এটি নিশ্চিত করতে পারি।
jreed121

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