ডাটাবেস সম্পর্কিত পদ্ধতি ডিজাইনিং, যা ফেরত দেওয়া ভাল: সত্য / মিথ্যা বা সারি প্রভাবিত?

10

আমার কিছু পদ্ধতি রয়েছে যা একটি ডাটাবেসে কিছু ডেটা পরিবর্তন করে (সন্নিবেশ করান, আপডেট করুন এবং মুছুন) সম্পাদন করে। ORM আমি পদ্ধতি যারা টাইপ বিনিময়ে সারি আক্রান্ত int- এ মান ব্যবহার করছি। অপারেশনের সাফল্য / ব্যর্থতার অবস্থা নির্দেশ করতে, "আমার পদ্ধতি" এর জন্য আমি কী ফিরিয়ে দেব?

যে কোডটি প্রত্যাবর্তন করছে তা বিবেচনা করুন int:

A.1

public int myLowerLevelMethod(int id) {
    ...
    int affectedRows = myOrm.deleteById(id)
    ...

    return affectedRows;
}

তারপরে ব্যবহার:

A.2

public void myOtherMethod() {
    ...
    int affectedRows = myLowerLevelMethod(id)

    if(affectedRows > 0) {
        // Success
    } else {
        // Fail
    }
}

বুলিয়ান ব্যবহারের সাথে তুলনা করুন:

B.1

public boolean myLowerLevelMethod(int id) {
    ...
    int affectedRows = myOrm.deleteById(id)
    ...

    return affectedRows > 0;
}

তারপরে ব্যবহার:

B.2

public void myOtherMethod() {
    ...
    boolean isSuccess = myLowerLevelMethod(id)

    if(isSuccess) {
        // Success
    } else {
        // Fail
    }
}

কোনটি (এ বা বি) ভাল? বা প্রত্যেকের পক্ষে / বিপরীতে?

design error-handling methods

— হোয়াং ট্রান
সূত্র

আপনার "এ .2" তে যদি শূন্য সারিগুলি প্রভাবিত হয় তবে শূন্য সারিগুলিকে প্রভাবিত করার প্রয়োজন হলে ব্যর্থতা কেন? অন্য কথায় যদি কোনও ডাটাবেস ত্রুটি না থাকে তবে এটি ব্যর্থতা কেন?

— জয়দী

5

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

— সেফালোপড

আপনি কি শূন্য সারিগুলির একটি অপসারণ অপ্রত্যাশিত বিবেচনা করছেন? সেক্ষেত্রে নিক্ষেপ।

— usr ডিরেক্টরির

@ অ্যারিয়ান আমি মনে করি এটিই আমার কাছে আসল প্রশ্ন। আমি মনে করি আমি বি নির্বাচন করেছি, কারণ এ এর সাথে, আমার কোডে কিছু জায়গায় 0 এবং অন্যদের জন্য 1-র পরীক্ষা করা রয়েছে

— হোয়াং ট্রান

18

আর একটি বিকল্প হল মৌলিক ধরণের পরিবর্তে ফলাফল অবজেক্ট return উদাহরণ স্বরূপ:

OperationResult deleteResult = myOrm.deleteById(id);

if (deleteResult.isSuccess()) {
    // ....
}

এটির সাহায্যে যদি কোনও কারণে আপনাকে প্রভাবিত সারিগুলির সংখ্যা ফেরত দিতে হয় তবে আপনি কেবল অপারেশনসাল্টে একটি পদ্ধতি যুক্ত করতে পারেন:

if (deleteResult.isSuccess()) {
    System.out.println("rows deleted: " + deleteResult.rowsAffected() );
}

এই নকশাটি আপনার সিস্টেমকে বাড়ার অনুমতি দেয় এবং বিদ্যমান কোডটি পরিবর্তন না করেই নতুন কার্যকারিতা (প্রভাবিত সারিগুলি সম্পর্কে জেনে) অন্তর্ভুক্ত করে।

— AlfredoCasado
সূত্র

2

+1 "এই নকশাটি আপনার সিস্টেমকে বাড়ার অনুমতি দেয় এবং বিদ্যমান কোডটি সংশোধন না করে নতুন কার্যকারিতা (প্রভাবিত সারিগুলি সম্পর্কে জেনে) অন্তর্ভুক্ত করে" এই বিভাগের প্রশ্নের সম্পর্কে চিন্তা করার সঠিক উপায় এটি।

— অবহিত

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

— অবহিত

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

— ব্রায়ান এস

কেবল ওপিএসের উদাহরণটি দেখে, আমি যা ভাবতে পারি তা হ'ল ডিলিটবাইআইডি কিছু সময়ে 2 ফিরে আসবে :) তাই অবশ্যই একটি কাস্টম প্রকার, হ্যাঁ।

— মৃতদেহ

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

— হোয়াং ট্রান

12

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

কোনও প্রোগ্রামার আপনাকে দোষ দেবে না কারণ অপারেশন চলাকালীন কিছু পরিবর্তন হয়েছে কিনা তা পরীক্ষা করার জন্য তাকে এই লিখতে হবে:

if(affectedRows > 0) {
    // success
} else {
    // fail
}

তবে তারা আপনাকে দোষ দেবে যখন তাদের প্রভাবিত সারিগুলির সংখ্যা জানতে হবে এবং তারা বুঝতে পারে যে এই সংখ্যাটি পাওয়ার কোনও পদ্ধতি নেই।

বিটিডাব্লু: যদি "ব্যর্থতা" বলতে আপনার বোঝায় একটি সিনট্যাক্টিক্যাল ক্যোয়ারী ত্রুটি (যার ক্ষেত্রে প্রভাবিত সারিগুলির সংখ্যা অবশ্যই 0) তবে ব্যতিক্রম ছুঁড়ে দেওয়া আরও উপযুক্ত হবে।

— লালপাগড়ি
সূত্র

4

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

— আর্সেনী মরজেনকো

1

@ মাইনমা ওভারলোডেড পদ্ধতি তৈরির পথে দাঁড়ায় না। অতিরিক্ত হিসাবে, স্থানীয় ভাষায় (উদাহরণস্বরূপ সি পরিবার), সারিগুলির সংখ্যা সরাসরি যুক্তিতে ব্যবহার করা যায় (0 মিথ্যা, অন্য কিছু সত্য) true

— PTwr

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

— আর্সেনি মরজেনকো

1

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

— প্রকোসার

4

আপনার সর্বদা এখানে আক্রান্ত সারির সংখ্যাটি ফিরিয়ে দেওয়া উচিত !!! যেহেতু আপনি সম্ভবত জানতে পারবেন না যে সারি সংখ্যা = 0 ব্যর্থতা, বা সারি সংখ্যা = 3 যদি সাফল্য হয়? যদি কেউ 3 টি সারি সন্নিবেশ করতে চায় এবং কেবল 2 টি getোকানো হয় তবে আপনি সত্য ফিরে পাবেন, তবে এটি ঠিক নয়! এবং কেউ যদি update t set category = 'default' where category IS NULL0 টি প্রভাবিত সারিগুলিও করতে চান তবে এটি একটি সাফল্য হবে, কারণ এখন বিভাগ ছাড়া কোনও আইটেম নেই, এমনকি কোনও সারি প্রভাবিত না হলেও!

— ফ্যালকো

10

আমি তাদের কাউকেই সুপারিশ করব না। পরিবর্তে, সাফল্যে কিছুই (অকার্যকর) ফেরান এবং ব্যর্থতার ব্যতিক্রম নিক্ষেপ করুন।

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

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

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

— proskor
সূত্র

4

-1 আপনি অতিরিক্ত কিছু অপারেটিং প্রসঙ্গটি সরবরাহ করে এমন কোনও নেতিবাচক পার্শ্ব প্রতিক্রিয়া ছাড়াই যেখানে আপনি কিছু ফিরিয়ে দিতে পারবেন সেখানে কেন এমন কিছু কেন ফিরিয়ে দেবেন?

— ফ্রিএএসআইনবিয়ার

7

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

— প্রকোসার

1

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

— প্রকোসার

4

@ প্রসস্কর: ব্যতিক্রম ব্যতিক্রমী ক্ষেত্রে are এই পরিস্থিতিতে "ব্যর্থতা" একটি প্রত্যাশিত ফলাফল হতে পারে। যাইহোক, এটিকে সম্ভাব্য বিকল্প হিসাবে এগিয়ে রাখুন, তবে এখানে একটি সুপারিশ করার জন্য পর্যাপ্ত তথ্য নেই।

— নিক বার্নেস

1

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

2

"এটা কি এর চেয়ে ভাল?" যখন দুটি বিকল্প একই জিনিস না করে তখন কোনও কার্যকর প্রশ্ন নয়।

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

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

— কিলিয়ান ফথ
সূত্র

আমি সম্মত হই যে এটি অ্যাপের প্রয়োজনীয়তার উপর অনেক বেশি নির্ভর করে। তবে মনে হয় এই ধরণের পরিস্থিতি খুব অনন্য নয় এবং আমি রূপালী বুলেট খুঁজছি না তবে একই / একই জিনিস নিয়ে কাজ করার জন্য কেবল অন্যের অভিজ্ঞতা (সম্ভবত প্রশ্নটি কিছুটা বিভ্রান্তিকর, আমি এ ব্যতীত অন্য পরামর্শের মতোই করি) / বি)

— হোয়াং ট্রান

1

রক্ষণাবেক্ষণযোগ্য সফ্টওয়্যার ডিজাইনের দুটি গুরুত্বপূর্ণ নীতি হ'ল কেআইএসএস এবং ইয়াজিএনআই ।

KISS : এটিকে সরল রাখুন, বোকা
ইয়াগনি : আপনার দরকার নেই

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

আপনি কোনও প্রোগ্রামে যে কোনও জটিলতা যুক্ত করেন তা দীর্ঘমেয়াদে প্রদান করা মূল্যে আসে। প্রোগ্রামটি পড়া আরও কঠিন হয়ে ওঠে, পরিবর্তন করা আরও জটিল এবং বাগগুলি সহজেই কমতে সহজ হয় things "কেবলমাত্র" ক্ষেত্রে জিনিস যুক্ত করার ফাঁদে পড়বেন না। এটি সুরক্ষার একটি মিথ্যা ধারণা sense

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

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

— বেন লি
সূত্র

-1

পুরো সারি বা ত্রুটির স্থিতি

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

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

— পিটার হচ্ছে
সূত্র