কেন কোনও বিকাশকারীকে একটি ডিবিতে সরাসরি সংযোগের পরিবর্তে ওয়েব পরিষেবা ব্যবহার করা উচিত? [বন্ধ]


94

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

এখানে আমি যা নিয়ে এসেছি তা এখানে। আর কি?

  1. ডাব্লুসিএফ ওয়েব পরিষেবাগুলি সঠিকভাবে কনফিগার করা থাকলে আরও সুরক্ষিত হতে পারে।
  2. কেবলমাত্র ডিবিতে পরিবর্তনগুলি পরিষেবা পর্যায়ে করা উচিত (কনফিগার ফাইল বা পুনরায় সংযোগ পরিষেবা)।
  3. একবার সেটআপ এবং হোস্ট করা হয়ে গেলে, ওয়েব পরিষেবাগুলি গ্রাস করা সহজ।

উত্তর:


120
  1. সুরক্ষা। আপনি ওয়েব সার্ভার / অ্যাপ ব্যবহারকারী ছাড়া কারও কাছে ডিবি অ্যাক্সেস দিচ্ছেন না।

    আপনার অতিরিক্ত সংখ্যক ব্যবহারকারী থাকলে এটি অতিরিক্ত গুরুত্বপূর্ণ। আপনি ডিবি পক্ষের ব্যবহারকারী / ভূমিকা রক্ষণাবেক্ষণের ব্যথা এড়াতে পারেন।

  2. ডিবি লোড হ্রাস। ওয়েব পরিষেবা ডিবি থেকে পুনরুদ্ধার করা ডেটা ক্যাশে করতে পারে।

  3. ডাটাবেস সংযোগ পুলিং (টুপি / টিপ @ ডগস)।

    একটি ওয়েব পরিষেবা স্থায়ীভাবে খোলা ডিবি সংযোগগুলির একটি ছোট পুল ব্যবহার করতে পারে। বিভিন্ন উপায়ে সহায়তা করে:

    • ডিবি সংযোগ পুলটি ডাটাবেস সার্ভারের পক্ষে সীমাবদ্ধ।

    • একটি নতুন ডিবি সংযোগ খোলার জন্য খুব ব্যয়বহুল (বিশেষত ডাটাবেস সার্ভারে)।

  4. ফল্ট সহনশীলতার ক্ষমতা - পরিষেবা ভোক্তাদের দ্বারা প্রয়োগ ব্যর্থ ওভারের বিবরণ ছাড়াই পরিষেবাটি প্রাথমিক / ডিআর ডেটা উত্সগুলির মধ্যে স্যুইচ করতে পারে।

  5. পরিমাপযোগ্যতা - পরিষেবাটি গ্রাহকরা কর্তৃক গৃহীত সম্পদ বাছাইয়ের বিশদ না রেখে বিভিন্ন সমান্তরাল ডেটা উত্সগুলির মধ্যে পরিষেবাগুলি অনুরোধ ছড়িয়ে দিতে পারে।

  6. এনক্যাপসুলেশন। পরিষেবা ব্যবহারকারীদের প্রভাবিত না করে আপনি অন্তর্নিহিত ডিবি বাস্তবায়ন পরিবর্তন করতে পারেন।

  7. ডেটা বৃদ্ধি মূলত এগুলির যে কোনওটি কার্যকর হতে পারে তবে এগুলির মধ্যে কোনও একটি ডাটাবেজে একটি বড় লোড এবং প্রায়শই একটি ডিবিতে প্রয়োগ করা খুব কঠিন hard

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

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

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

এই পৃষ্ঠায় একটি ভাল তালিকাও পাওয়া যাবে : 'এনক্যাপসুলেটিং ডেটাবেস অ্যাক্সেস: একটি চৌকস "সেরা" অনুশীলন "

কেবল স্ফটিক পরিষ্কার হতে - এর মধ্যে কিছু সমস্যা সমস্ত পরিস্থিতিতে প্রযোজ্য নয়। কিছু লোক বহনযোগ্যতার বিষয়ে চিন্তা করে না। কিছু লোকের ডিবি সুরক্ষা নিয়ে চিন্তা করার দরকার নেই। কিছু লোকের ডিবি স্কেলেবিলিটি নিয়ে চিন্তা করার দরকার নেই।


26
দুঃখিত, একমত না ১. সুতরাং আপনি কোনও একক অধ্যক্ষের পরিবর্তে একটি গোষ্ঠীতে ডিবিকে অ্যাক্সেস দিন। ২. যে কোনও অ্যাপ ডেটা ক্যাশে করতে পারে। একাধিক ব্যবহারকারীকে যে ধরণের ডেটা ক্যাশে করা যেতে পারে তা হ'ল সাধারণত কোনও ক্ষেত্রেই কম পরিমাণে ডেটা হবে। ৩. এফটি কোনও ক্ষেত্রেই ডাটাবেস দ্বারা পরিচালনা করা উচিত। ৪. এটি বক্স বৈশিষ্ট্যটির বাইরে নয়, এবং এটি প্রোগ্রাম করতে হবে। ৫. আপনার ডেটা অ্যাক্সেস স্তরটি এনক্যাপসুলেশন করা উচিত। 6. একই জিনিস। Re. সত্যই? জেডিবিসি কোন ক্লায়েন্টে চলে না? 8. ভাল পয়েন্ট, যখন এটি গুরুত্বপূর্ণ, যা বিরল। ৯. ক্যোয়ারী বনাম এসপি প্রশ্নের অংশ ছিল না।
জন স্যান্ডার্স

7
1. পরিচালনার চেষ্টা করুন 5000 জুড়ে রেন্ডার রেন্ডার সহ ব্যবহারকারী। এত ভাল স্কেল না। ২. পুরোপুরি কোনও অ্যাপের উপর নির্ভর করে। আমাদের বর্তমান ক্ষেত্রে একটি ক্যোয়ারির ক্যাশে ফলাফলের একটি উদাহরণ রয়েছে যা উবার-অনুকূলিতকরণের ক্ষেত্রে চালাতে 20 মিনিট সময় নেয় এবং যা আমাদের কমপক্ষে বিভিন্ন অ্যাপ্লিকেশন থেকে দিনে 100s বার চালানো দরকার। ৩.এফটি স্তরগুলির একগুচ্ছ পরিচালনা করা হয়। "একটি ডাটাবেস দ্বারা পরিচালনা করা উচিত" এর অর্থ কী?
ডিভি কে

4
4. অবশ্যই এটি প্রোগ্রাম করা আছে। তবে এটি একবারে পরিষেবাতে বা বিভিন্ন প্ল্যাটফর্মের এক মিলিয়ন ক্লায়েন্ট অ্যাপ্লিকেশনগুলিতে বিভিন্ন দক্ষতার সাথে প্রোগ্রাম করা যেতে পারে। একটি বড় পার্থক্য আছে। লোড ভারসাম্য রক্ষার জন্য কনফিগারেশন পরিচালনার সমস্যাগুলি মনে করবেন না। ৫. একই যুক্তি। আপনার ডাল পুনরায় প্রয়োগের দরকার নেই। প্রকৃতপক্ষে, আপনি নিজের মনকে সহজ করার জন্য কেবল ওয়েব পরিষেবাটিকে একটি পোর্টেবল ডাল হিসাবে ভাবতে পারেন। We. আমরা প্রতিটি ক্লায়েন্ট ডিবি সংযোগ খোলার চাই না। এত বড় কথা কি চাওয়া? আবার, আপনি 1-5 পয়েন্ট ভুলে যাচ্ছেন।
ডিভি কে

4
৮.> ১ ক্লায়েন্ট আর্কিটেকচারটি প্রায়শই ঘটে। সত্যিকারের বিষয় আমি জীবনে কখনও এমন প্রকল্পে কাজ করি নি, তবে আমি আর্থিক জগতকে কেন্দ্র করেই রয়েছি। 9. এটা ছিল না। আমি মূলত শয়তানের উকিল খেলছিলাম।
ডিভি কে

4
আমি এই উত্তরটি পছন্দ করি, তবে আমি মনে করি আপনি একটি সর্বাধিক গুরুত্বপূর্ণ বিষয়টিকে এড়িয়ে গেছেন: সংযোগ পুলিং। আপনার যদি ১,০০,০০০ ক্লায়েন্ট থাকে তবে আপনার কাছে হয় ১,০০,০০০ উন্মুক্ত সংযোগ থাকবে, বা লক্ষ লক্ষ সংযোগ ক্রমাগত খোলা এবং বন্ধ থাকবে। কম্পিউটার সংগঠন সম্পর্কে প্রাথমিক অন্তর্নিহিততা আমাদের জানায় যে কয়েক মিলিয়ন দীর্ঘকালীন সংযোগের একটি সুসংগত পুলটি মিলিয়ন দীর্ঘজীবী বা লক্ষ লক্ষ স্বল্পকালীন সংযোগ থাকার চেয়ে জ্যোতির্বিজ্ঞানের চেয়ে বেশি দক্ষ। এই ধারণাটি ব্যাখ্যা করার জন্য হিকারিসিপি একটি দুর্দান্ত কাজ করেছে: github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
কুকুর

15

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

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

অগত্যা এক্সএমএল কেন? সাধারণ ফ্ল্যাট ডেটা ইত্যাদির জন্য
জেএসএন

এটি "কোনও অকারণে নয়"। যেমনটি উল্লেখ করা হয়েছে, আপনার প্রয়োজনীয়তা এবং ভবিষ্যতের বিকাশের জন্য আকাঙ্ক্ষার উপর নির্ভর করে এটি আপনার প্রকল্পের জন্য প্রয়োজনীয় হতে পারে।
ক্রিস স্টুয়ার্ট

আমি ডাল সেবনে আমার ডাব্লুএস লিখি। আপনি কোন বন্দরটি ডাল প্রকাশের পরামর্শ দিচ্ছেন?
সামিস

@ সামাস এটি কোন ব্যাপার না।
জন স্যান্ডার্স

"কোনও ডাটাবেস সংযোগ নিরাপদ না হওয়ার কোনও কারণ নেই", ভাল, উদাহরণস্বরূপ উইন্ডোজ ক্লায়েন্ট এবং একটি ডাটাবেসের মধ্যে সংযোগটি সুরক্ষিত করা শক্ত। একটি নিরাপদ সংযোগ বাস্তবায়ন করা সত্যিই কঠিন!
NoChance

12
  • বাহ্যিক সিস্টেম এবং অ্যাপ্লিকেশনটির ডেটার মধ্যে অনুমোদিত ইন্টারঅ্যাকশনকে সংজ্ঞায়িত করে ওয়েব পরিষেবাগুলি একটি এআইপি গঠন করে।
  • ওয়েব পরিষেবাদি বাহ্যিক মিথস্ক্রিয়া থেকে ডাটাবেসটিকে ডিক্লুপ করে এবং বাইরের প্রভাবগুলির থেকে ডেটা স্তরটিকে স্বাধীনভাবে পরিচালিত করতে সক্ষম করে।
  • কেবলমাত্র ওয়েব পরিষেবাদি দ্বারা অ্যাক্সেসের মঞ্জুরি দেয় তা নিশ্চিত করে যে অ্যাপ্লিকেশন লজিক ডেটা অখণ্ডতা রক্ষা করে কার্যকর করার সুযোগ পায়।
  • ওয়েব পরিষেবাদি ব্যবহারকারীর নাম এবং পাসওয়ার্ড / টেবিল স্তরের সুবিধাগুলির প্রয়োজন এমন একটি ডাটাবেসের বিপরীতে সর্বাধিক উপযুক্ত প্রমাণীকরণ / অনুমোদনের ব্যবস্থা গ্রহণের অনুমতি দেয়।
  • ওয়েব পরিষেবাদি স্বয়ংক্রিয় পরিষেবা আবিষ্কার এবং ব্যবহারের জন্য কনফিগারেশন করার সুযোগ দেয় provide
  • অসুরক্ষিত নেটওয়ার্কগুলির মাধ্যমে ট্রানজিটের জন্য ওয়েব পরিষেবাদি ট্র্যাফিক এনক্রিপ্ট করা যেতে পারে। এমন কোনও সরাসরি ডিবি সংযোগ সমাধানগুলি জানেন না যে এটি সক্ষম করে ...?

এই পয়েন্টগুলির বেশিরভাগই কোনও আনুষ্ঠানিক API এর জন্য যায়, বিশেষত ওয়েব পরিষেবাদি নয়।


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

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

"শুধুমাত্র ওয়েব পরিষেবাদি দ্বারা অ্যাক্সেসের মঞ্জুরি দেয় তা নিশ্চিত করে যে অ্যাপ্লিকেশন যুক্তি ডেটা অখণ্ডতা রক্ষা করে কার্যকর করার সুযোগ পায়" " - আমি যুক্তি দেব যে ডেটা অখণ্ডতা শুধুমাত্র DBMS এর অংশ হওয়া উচিত।
জুতো

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

2

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

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


4
ওয়েব এপিআই ডাব্লুসিএফ / এসওএপি ব্লাট ইস্যুকে সম্বোধন করেছে। এটি এখন হালকা, ফিট, চটপটি লাইনের মতো; এটি আধ্যাত্মিকভাবে পরিবেশন করা প্রয়োজন কি।
সামিস

তত্ত্বগতভাবে, ওয়েব পরিষেবাদি ব্যবহার করে সঞ্চিত প্রকসকে কল করা ভুল নয়।
NoChance

2

1) ডেটাবেস বজায় রাখার মাথাব্যথা বিকাশকারীদের দিক থেকে হ্রাস করা হয় যাতে তারা কেবল বিকাশের দিকে ফোকাস করতে পারে।

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


1

সাধারণভাবে

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

আমি কেবল এএসপি.এনইটি ওয়েব অপির সাথে তাকাচ্ছি এবং ডেটা পরিষেবাগুলি তৈরি করার পরিকল্পনা করছি।

আমি সম্প্রতি সত্তা কাঠামো ব্যবহার করে .NET এমভিসি ওয়েব অ্যাপ্লিকেশনগুলিতে ফোকাস করছি।

  1. আপনি যদি ইতিমধ্যে এমভিসি ব্যবহার করেন তবে ওয়েব অপি এপিআই কন্ট্রোলারের সাথে এমভিসিও ব্যবহার করে যাতে পরিষেবাগুলি তৈরি করতে শেখার বক্ররেখা মোটামুটি ব্যথাহীন থাকে।

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

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

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

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

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

তাই ....

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

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

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