এসকিউএল সার্ভার ডাটাবেসে একটি একক সারি কনফিগারেশন টেবিল ব্যবহার করা। খারাপ ধারণা?


145

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

এটি একটি রিলেশনাল ডাটাবেস সিস্টেমে একক সারিতে সঞ্চয় করার জন্য একটি সারণী তৈরি করা অত্যন্ত অনুচিত বলে মনে হয়।

এই তথ্য সংরক্ষণ করার উপযুক্ত উপায় কী?

দ্রষ্টব্য: আমার ডিবিএমএস এসকিউএল সার্ভার ২০০৮ এবং প্রোগ্রামিং স্তরটি এএসপি.নেট (সি # তে) এর সাথে প্রয়োগ করা হয়েছে।

উত্তর:


189

আমি অতীতে এই দুটি উপায়ে করেছি - একটি একক সারি সারণী এবং একটি / মান জোড় টেবিল - এবং প্রতিটি পদ্ধতির ইতিবাচক এবং নেতিবাচক রয়েছে।

একক সারি

  • ধনাত্মক: মানগুলি সঠিক প্রকারে সংরক্ষণ করা হয়
  • ধনাত্মক: কোড মোকাবেলা করা সহজ (উপরের কারণে)
  • ধনাত্মক: প্রতিটি সেটিংকে পৃথকভাবে ডিফল্ট মান দেওয়া যেতে পারে
  • নেতিবাচক: একটি নতুন সেটিং যুক্ত করতে একটি স্কিমা পরিবর্তন প্রয়োজন
  • নেতিবাচক: প্রচুর সেটিংস থাকলে টেবিলটি খুব প্রশস্ত হতে পারে

কী / মান জুড়ি

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

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

এই দৃষ্টিভঙ্গিটি ব্যবহার করে আমি যে বিষয়টি নিয়ে উদ্বিগ্ন ছিল তাতে "বিশেষ" একক সারি সেটিংস সারণীতে একাধিক সারি ছিল। আমি এটি (এসকিউএল সার্ভারে) দ্বারা কাটিয়ে উঠলাম:

  • 0 এর একটি ডিফল্ট মান সহ একটি নতুন বিট কলাম যুক্ত করা
  • এই কলামটির মান 0 রয়েছে কিনা তা নিশ্চিত করতে একটি চেক সীমাবদ্ধতা তৈরি করা creating
  • বিট কলামে একটি অনন্য বাধা তৈরি করে

এর অর্থ হ'ল টেবিলটিতে কেবল একটি সারি বিদ্যমান থাকতে পারে কারণ বিট কলামটির 0 মান থাকতে হবে, তবে অনন্য সীমাবদ্ধতার কারণে সেই মানটির সাথে কেবল একটি সারি থাকতে পারে।


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

17
একক সারি ইতিবাচক: কয়েকটি কলামে এফকে সংজ্ঞায়িত করা যেতে পারে!
wqw

8
কোন কলামের মান ধরণের মান রয়েছে তা নির্ধারণ করতে আপনি সর্বদা কোনও প্রকার শনাক্তকারী সহ একটি কী / মান জুটি করতে পারেন। এটি আপনাকে উভয় বিশ্বের সেরা দেয় এবং আপনি যখন প্রয়োজন হয় তখন মান পেতে আপনি একটি সঞ্চিত প্রকট ব্যবহার করতে পারেন।
Middletone

19
একক সারির সমাধানটি কার্যকর করার পরে একটি জিনিস যা আপনার দিনটিকে সত্যই নষ্ট করতে পারে তা হ'ল যখন আপনাকে পরে "প্রতিটি মান পরিবর্তন করা হয়েছিল এবং কে এটি পরিবর্তন করেছে সর্বশেষ
সময়টিও

6
একক সারি সমাধানের আর একটি সুবিধা, যা আমি এক ক্ষেত্রে আবিষ্কার করেছি: আমার কাছে একটি সেটিংস তৈরির জন্য একটি ক্লায়েন্টের জন্য একটি অ্যাপ্লিকেশন তৈরি হয়েছিল, "সেটিংস" এর জন্য একটি একক-সারি টেবিল with পরে আমি আরও দুটি ক্লায়েন্ট পেয়েছি যারা একই অ্যাপ্লিকেশনটি ব্যবহার করতে চেয়েছিল তবে বিভিন্ন সেটিংস চেয়েছিল: প্রতিটি ক্লায়েন্টের জন্য আলাদা আলাদা সেটিংস বজায় রাখার জন্য আমাকে কেবল টেবিলে একটি "ক্লায়েন্ট_আইডি" পিকে যুক্ত করতে হয়েছিল। (এটি যখন আপনি বুঝতে পারবেন যে এই "সেটিংস" সত্যই আপনি এমন কোনও উচ্চ-স্তরের সত্তার জন্য কেবলমাত্র বৈশিষ্ট্য যা আপনি এখনও মডেল করেননি))
জেফ্রি কেম্প

10

তথ্যের ধরণ এবং তথ্যের মান (কমপক্ষে) জন্য আপনার একটি কলাম সহ একটি সারণী তৈরি করা উচিত। এভাবে প্রতিবার নতুন তথ্য যুক্ত হওয়ার সাথে সাথে আপনি নতুন কলাম তৈরি করা এড়াতে পারেন।


1
সহজ এবং ঝরঝরে। সেখান থেকে মূল মান জোড়ার একটি তালিকা নিয়ে কাজ করুন। আপনি ডিফল্ট মানগুলি সম্পর্কে কিছুটা ভাবতে চাইতে পারেন, এটি ব্যবহারের প্রসঙ্গে নির্ভর করে ...
পল কোহলার

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

6

একটি একক সারি ভাল কাজ করবে; এটির শক্তিশালী প্রকারগুলিও থাকবে:

show_borders    bit
admin_name      varchar(50)
max_users       int

একটি অসুবিধা হ'ল এর জন্য একটি স্কিমা পরিবর্তন প্রয়োজন (alter table একটি নতুন সেটিং যুক্ত করতে )একটি বিকল্প হ'ল সাধারণীকরণ, যেখানে আপনি টেবিলের মতো শেষ করবেন:

pref_name       varchar(50) primary key
pref_value      varchar(50) 

এতে দুর্বল প্রকার রয়েছে (সবকিছুই একটি বার্চর), তবে একটি নতুন সেটিং যুক্ত করা কেবল একটি সারি যুক্ত করছে, এমন কিছু যা আপনি কেবল ডাটাবেস লেখার অ্যাক্সেসের সাথে করতে পারেন।


4

ব্যক্তিগতভাবে, আমি এটি একক সারিতে সংরক্ষণ করব যদি এটি কাজ করে would একটি এসকিউএল টেবিলে এটি সঞ্চয় করার জন্য ওভারকিল? সম্ভবত, তবে এটি করার ক্ষেত্রে কোনও আসল ক্ষতি নেই।


4

আপনি যেমন অনুমান করেছেন এবং সহজ পরিস্থিতি ব্যতীত, সমস্ত কনফিগারেশন প্যারামিটারগুলিকে একক সারিতে রাখার ক্ষেত্রে অনেকগুলি ত্রুটি রয়েছে। এটি একটি খারাপ ধারণা...

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

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

EntityId     (foreign key to the "owner" of this attribute)
AttributeId  (foreign key to the "metadata" table where the attribute is defined)
StringValue  (it is often convenient to have different columns of different types
IntValue      allowing to store the various attributes in a format that befits 
              them)

যার দ্বারা অ্যাট্রিবিউটআইডি একটি টেবিলের জন্য একটি বিদেশী কী যেখানে প্রতিটি সম্ভাব্য অ্যাট্রিবিউট (আপনার ক্ষেত্রে "কনফিগারেশন প্যারামিটার") সংজ্ঞায়িত করা হয়েছে, বলার সাথে

AttributeId  (Primary Key)
Name
AttributeType     (some code  S = string, I = Int etc.)
Required          (some boolean indicating that this is required)
Some_other_fields   (for example to define in which order these attributes get displayed etc...)

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

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


3
এটি কনফিগারেশন টেবিলের বেশিরভাগ ব্যবহারের জন্য ওভারকিলের মতো শোনাচ্ছে।
জেরিওল

আমি মনে করি এই পদ্ধতির পিছনে সাধারণ ধারণাটি দুর্দান্ত। তবে এক্সএমএল কেন? JSON বা YAML এর মতো একটি সাধারণ ডেটা ইন্টারচেঞ্জ ফর্ম্যাটটি চয়ন করুন এবং অন্যান্য বৈচিত্রগুলির উভয় থেকে আপনার সুবিধা থাকতে পারে।
schlamar

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

3

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

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


2

একটি কী এবং মান যুগলটি। নেট অ্যাপ.কনফিগের মতো যা কনফিগারেশন সেটিংস সঞ্চয় করতে পারে।

সুতরাং যখন আপনি যে মানটি করতে পারেন তা পুনরুদ্ধার করতে চাইলে:

SELECT value FROM configurationTable
WHERE ApplicationGroup = 'myappgroup'
AND keyDescription = 'myKey';

1

এটি করার একটি সাধারণ উপায় একটি বৈশিষ্ট্য ফাইলের সাথে একটি "বৈশিষ্ট্য" টেবিলের অনুরূপ হওয়া। এখানে আপনি আপনার সমস্ত অ্যাপের ধ্রুবক সঞ্চয় করতে পারেন বা এমন ধ্রুবক জিনিস নয় যা আপনার চারপাশে থাকা দরকার।

আপনার প্রয়োজন অনুসারে আপনি এই টেবিলটি থেকে তথ্য দখল করতে পারেন। তেমনি, আপনি যেমন সংরক্ষণের জন্য অন্য কিছু সেটিংস পেয়েছেন, আপনি এটি এতে যুক্ত করতে পারেন Here এখানে একটি উদাহরণ রয়েছে:

property_entry_table

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "COMPANY_INFO", "Acme Tools", "ADMIN"  
2, 0, 1, "SHIPPING_ID", "12333484", "ADMIN"  
3, 0, 1, "PAYPAL_KEY", "2143123412341", "ADMIN"   
4, 0, 1, "PAYPAL_KEY", "123412341234123", "ADMIN"  
5, 0, 1, "NOTIF_PREF", "ON", "ADMIN"  
6, 0, 2, "NOTIF_PREF", "OFF", "ADMIN"   

এইভাবে আপনি আপনার থাকা ডেটা এবং আপনার পরের বছর যে ডেটা থাকবে তা সঞ্চয় করতে পারবেন এবং এখনও জানেন না :)।

এই উদাহরণে, আপনার স্কোপ এবং রিফআইড আপনি পিছনের প্রান্তে যা চান তার জন্য ব্যবহার করা যেতে পারে। সুতরাং যদি সম্পত্তি টাইপ "অ্যাডমিন" এর সুযোগ 0 রিফাইড 2 হয় তবে আপনি কী পছন্দ তা জানেন।

সম্পত্তির ধরণটি যখন হাতে আসে তখন কোনও দিন আপনাকে এখানে অ-প্রশাসনিক তথ্যও সংরক্ষণ করতে হবে।

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

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

মুল বক্তব্যটি হ'ল আপনি এটি কার্টের সাথে সম্পর্কিত জিনিসগুলির জন্য ব্যবহার করতে চান না। আপনাকে ব্যবসায়িক যুক্তি ভাল সংজ্ঞাযুক্ত টেবিলগুলিতে রাখুন। বৈশিষ্ট্য সারণীটি কেবলমাত্র সিস্টেমের তথ্যের জন্য।


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

দ্রষ্টব্য: তিনি বলেছিলেন "সেটিংস এবং কনফিগারেশনগুলি সংরক্ষণ করুন", "আমাকে রিলেশনাল কার্টের ডেটা সংরক্ষণ করার দরকার নেই"
স্টেফানো

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

আমার প্রথম প্রবৃত্তিটি কেবল একটি ফ্ল্যাট ফাইলে এই ডেটা যুক্ত করা। এবং আপনি সঠিক, পরিবর্তে একটি টেবিল ব্যবহার করার এই প্রক্রিয়া সত্যিই DBMS এর সীমাবদ্ধতা ব্যবস্থা নষ্ট করবে। তবে, আমি বলব যে আপনি যদি সঠিক ডাটাবেস কৌশলগুলি অনুসরণ করতে খুব চেষ্টা করেন তবে আপনি বিষয়টিটি অনুপস্থিত। প্রথম উত্তরটি দেখুন; এসও-তে সবচেয়ে বেশি ভোট দিয়েছেন: stackoverflow.com/questions/406760/…
স্টেফানো

2
আমি কী মান জোড়ায় যাব, এটি শুরুতে একটি অভিধানে ফেলে দিতে এবং আপনার বাছাই করা।
পল ক্রেসি

0

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

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


0

আপনি প্রতিটি বড় ধরণের জন্য একটি কলাম এবং ডেটা কোন কলামে রয়েছে তা জানিয়ে একটি কলাম যুক্ত করে কোনও রূপান্তর ছাড়াই কী / মান জুটি করতে পারেন।

সুতরাং আপনার টেবিলটি দেখতে এমন কিছু লাগবে:

id, column_num, property_name, intValue, floatValue, charValue, dateValue
1, 1, weeks, 51, , ,
2, 2, pi, , 3.14159, , 
3, 4, FiscYearEnd, , , , 1/31/2015
4, 3, CompanyName, , , ACME, 

এটিতে আরও কিছু ঘর ব্যবহার করা হয়েছে তবে বেশিরভাগ ক্ষেত্রে আপনি কয়েক ডজন বৈশিষ্ট্য ব্যবহার করছেন। আপনি সঠিক ক্ষেত্রটি টানতে / যোগদান করতে কলাম_নাম মানের বাইরে কেস স্টেটমেন্ট ব্যবহার করতে পারেন।


0

দুঃখিত, আমি এখানে এসেছি তবে যাইহোক, আমি যা করি তা সহজ এবং কার্যকর। আমি কেবল তিনটি () কলাম সহ একটি টেবিল তৈরি করেছি:

আইডি - ইনট (11)

নাম - বারচার ()৪)

মান - পাঠ্য

একটি নতুন কনফিগার কলাম তৈরি করার আগে, আপডেট করা বা পড়ার আগে আমি যা করি তা হল "মান" সিরিয়ালাইজ করা! এই ধরণের বিষয়ে আমি নিশ্চিত (ভাল, পিএইচপি হল :))

এই ক্ষেত্রে:

খ: 0; জন্য বি OOLEAN ( মিথ্যা )

খ: 1; জন্য বি (OOLEAN সত্য )

I: 1988; জন্য আমি NT তে

গুলি: 5: "কাদের"; একটি জন্য এস 5 অক্ষরের দৈর্ঘ্যের Tring

আশা করি এটা কাজে লাগবে :)


1
শুধু টাইপের জন্য একটি নতুন কলাম তৈরি করবেন না কেন? i:1988দেখে মনে হচ্ছে আপনি একক কলামে তথ্য দুটি টুকরো টুকরো টুকরো করার চেষ্টা করছেন।
maksymiuk

@ ম্যাকসিমিউক সিম্পলি কারণ যে একবার অনিয়ালাইজড হয়ে গেলে আপনি (যদি বা স্যুইচ) পরে লুপ ব্যবহার না করে সঠিক ধরণটি পেয়ে যান ... ইত্যাদি
কাদের বোয়াকুব

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

echo (int) $varকোনও পূর্ণসংখ্যার জন্য এবং অন্য ধরণের জন্য অন্যদের মতো কিছু করার মাধ্যমে আপনার গড় ?
কাদের বোয়াকৌব

0

ভারচর হিসাবে একটি মূল কলাম এবং জেএসএন হিসাবে একটি মান কলাম রয়েছে। 1সংখ্যাযুক্ত যেখানে "1"একটি স্ট্রিং হয়। trueএবং falseউভয় বুলিয়ান। আপনার পাশাপাশি অবজেক্টও থাকতে পারে।

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