মাইএসকিউএল ৫.7-তে নেটিভ জেএসওন সমর্থন: এমওয়াইএসকিউএলে জেএসএন ডেটা প্রকারের পক্ষে কি কি?

Question

মাইএসকিউএল ৫.7 এ মাইএসকিউএল টেবিলগুলিতে জেএসএন ডেটা সংরক্ষণের জন্য একটি নতুন ডেটা টাইপ যুক্ত করা হয়েছে। এটি স্পষ্টতই মাইএসকিউএলে একটি দুর্দান্ত পরিবর্তন হবে। তারা কিছু সুবিধা তালিকাভুক্ত

ডকুমেন্ট বৈধতা - কেবল বৈধ JSON ডকুমেন্টগুলি একটি JSON কলামে সংরক্ষণ করা যেতে পারে, তাই আপনি নিজের ডেটাটির স্বয়ংক্রিয়তা বৈধতা পান।

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

পারফরম্যান্স - JSON কলামের মধ্যে মানগুলিতে সূচি তৈরি করে আপনার ক্যোয়ারী পারফরম্যান্সকে উন্নত করুন। এটি ভার্চুয়াল কলামগুলিতে "ফাংশনাল ইনডেক্স" দিয়ে অর্জন করা যেতে পারে।

সুবিধা - JSON কলামগুলির জন্য অতিরিক্ত ইনলাইন সিনট্যাক্সটি আপনার এসকিউএল এর মধ্যে ডকুমেন্ট কোয়েরিগুলিকে একীভূত করা খুব স্বাভাবিক করে তোলে। উদাহরণস্বরূপ (বৈশিষ্ট্য। বৈশিষ্ট্যটি একটি JSON কলাম):SELECT feature->"$.properties.STREET" AS property_street FROM features WHERE id = 121254;

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

এখন আমি জেএসওএন ডেটার জন্য কিছু জিজ্ঞাসা করতে পারি

SELECT * FROM t1
WHERE JSON_EXTRACT(data,"$.series") IN 
( 
SELECT JSON_EXTRACT(data,"$.inverted") 
FROM t1 | {"series": 3, "inverted": 8} 
WHERE JSON_EXTRACT(data,"$.inverted")<4 );

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

Comments

ওহ দয়া করে আপনি যা বলছেন তা আমি বলি না। এখানে, এটি পড়ুন । ইতিমধ্যে একটি খারাপ ধারণা নিয়ে আপনার অন্য রূপ।

— ড্রিউ

@ ড্রু আপনি একটি বড় উত্তর দিয়েছেন। তবে এটি আমার প্রশ্ন নয়। আমি কেবল জানতে চাই যে আমরা যদি জসন ডেটার জন্য একটি কোয়েরি লিখি তবে আমরা স্কিলের নিয়মগুলি এড়িয়ে যেতে পারি। বীচুস আমাদের অনেকগুলি টেবিলের প্রয়োজন নেই

— ইমরান

আপনি বলেছেন Now it is possible to store more complex data in column। সাবধানতা অবলম্বন করুন

— ড্র করুন

জসন ডেটা টাইপ সমর্থন সূচক এবং এটির স্মার্ট আকার: 64৪ কে এবং ৪ জি। সুতরাং সমস্যা যদি আমি 2000 ডেটা সঞ্চয় করতে চাই এবং 5 টি টেবিলের পরিবর্তে 5 টি নেস্টেল লেবেল যুক্ত করি?

— ইমরান

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

— ফিলিপ্সি

Answer 1

SELECT * FROM t1
WHERE JSON_EXTRACT(data,"$.series") IN ...

এর মত একটি এক্সপ্রেশন বা ফাংশনের অভ্যন্তরে একটি কলাম ব্যবহার করা ক্যোয়ারীটিকে অনুকূল করতে সহায়তা করার জন্য একটি সূচক ব্যবহার করে ক্যোয়ারীর কোনও সম্ভাবনা নষ্ট করে। উপরে প্রদর্শিত ক্যোয়ারীটি একটি টেবিল-স্ক্যান করতে বাধ্য হয়।

"দক্ষ অ্যাক্সেস" সম্পর্কে দাবিটি বিভ্রান্তিকর। এর অর্থ হল যে কোয়েরিটি কোনও JSON নথির সাথে একটি সারি পরীক্ষা করার পরে, এটি JSON সিনট্যাক্সের পাঠ্যকে পার্স না করেই একটি ক্ষেত্রটি বের করতে পারে। তবে সারিগুলির সন্ধানে এটি এখনও একটি টেবিল-স্ক্যান নেয়। অন্য কথায়, ক্যোয়ারিতে অবশ্যই প্রতিটি সারি পরীক্ষা করা উচিত।

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

মাইএসকিউএল 5.7 আপনাকে সারণীতে একটি ভার্চুয়াল কলাম সংজ্ঞায়িত করতে এবং তারপরে ভার্চুয়াল কলামে একটি সূচক তৈরি করতে দেয়।

ALTER TABLE t1
  ADD COLUMN series AS (JSON_EXTRACT(data, '$.series')),
  ADD INDEX (series);

তারপরে আপনি যদি ভার্চুয়াল কলামটি জিজ্ঞাসা করেন তবে এটি সূচকটি ব্যবহার করতে এবং টেবিল-স্ক্যান এড়াতে পারে।

SELECT * FROM t1
WHERE series IN ...

এটি দুর্দান্ত, তবে এটি JSON ব্যবহারের বিন্দুটিকে মিস করে না। JSON ব্যবহারের আকর্ষণীয় অংশটি হ'ল এটি আপনাকে ALTER TABLE না করে নতুন বৈশিষ্ট্য যুক্ত করতে দেয়। তবে দেখা যাচ্ছে যে আপনি যদি কোনও সূচকের সাহায্যে জেএসওএন ক্ষেত্রগুলি অনুসন্ধান করতে চান তবে আপনাকে অতিরিক্ত (ভার্চুয়াল) কলামটি নির্ধারণ করতে হবে।

তবে আপনাকে জেএসওএন ডকুমেন্টের প্রতিটি ক্ষেত্রের জন্য ভার্চুয়াল কলাম এবং সূচী সংজ্ঞায়িত করতে হবে না those কেবলমাত্র আপনি অনুসন্ধান বা বাছাই করতে চান। জেএসএনে অন্য বৈশিষ্ট্য থাকতে পারে যা আপনাকে কেবল নীচের মত বাছাই-তালিকায় বের করতে হবে:

SELECT JSON_EXTRACT(data, '$.series') AS series FROM t1
WHERE <other conditions>

আমি সাধারণত বলব যে এটি মাইএসকিউএলে জেএসএন ব্যবহার করার সর্বোত্তম উপায়। কেবলমাত্র নির্বাচন-তালিকায়।

আপনি যখন অন্যান্য অনুচ্ছেদে কলামগুলি রেফারেন্স করেন (যোগ করুন, যেখানে, গ্রুপ দ্বারা গ্রাহক হবেন, অর্ডার), তখন JSON নথির মধ্যে ক্ষেত্র নয়, প্রচলিত কলামগুলি ব্যবহার করা আরও দক্ষ।

আমি এপ্রিল 2018 এ পেরকোনা লাইভ সম্মেলনে মাইএসকিউএল র্রংয়ে জেএসএন কীভাবে ব্যবহার করব নামক একটি বক্তব্য উপস্থাপন করেছি I'll আমি শরতের পরে ওরাকল কোড ওয়ান-এ আলাপটি আপডেট করব এবং পুনরাবৃত্তি করব।

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

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

যখন জেএসএন আপনার প্রশ্নগুলি আরও দক্ষ করে তোলে তখন আপনার জেএসএন ব্যবহার করা উচিত।

কোনও প্রযুক্তি কেবলমাত্র নতুন বা ফ্যাশনের স্বার্থে চয়ন করবেন না।

---

সম্পাদনা: মাইএসকিউএলে ভার্চুয়াল কলাম বাস্তবায়ন সূচকটি ব্যবহার করবে বলে মনে করা হয় যদি আপনার WHERE ধারাটি ভার্চুয়াল কলামের সংজ্ঞা হিসাবে ঠিক একই অভিব্যক্তি ব্যবহার করে। এটি হ'ল ভার্চুয়াল কলামটি সংজ্ঞায়িত হওয়ায় নিম্নলিখিত ভার্চুয়াল কলামে সূচি ব্যবহার করা উচিতAS (JSON_EXTRACT(data,"$.series"))

SELECT * FROM t1
WHERE JSON_EXTRACT(data,"$.series") IN ...

আমি এই বৈশিষ্ট্যটি পরীক্ষা করে দেখেছি যে অভিব্যক্তিটি JSON- নিষ্কাশন ফাংশন হলে এটি কোনও কারণে কাজ করে না। এটি কেবল JSON ফাংশন নয়, অন্যান্য ধরণের অভিব্যক্তির জন্য কাজ করে।

Comments

স্লাইডগুলির লিঙ্কটি অনুসরণ করা ভাল

— পল ক্যাম্পবেল

গুড পয়েন্ট 2 টি প্রযুক্তি দুটি নিজস্ব উপায়েই ভাল আমরা সিদ্ধান্ত নিই যে কোনটি আমাদের প্রয়োজনীয়তার সাথে খাপ খায় এবং কী আমাদের সুরক্ষা এবং কার্য সম্পাদনের ক্ষেত্রে আরও বেশি সুবিধা দেয়।

— ক্রিস্টোফার পেলাও

সমস্যার ত্রুটিটি হ'ল জেএসএনের প্রতিটি নতুন কী এর জন্য উত্পন্ন কলামে একটি সূচক ব্যবহারের জন্য অল্টার টেবিলে এখনও প্রয়োজন। এটি দেখানো হয়েছে খুশি।

— ব্যবহারকারী1454926

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

— বিল কারভিন

স্লাইডগুলির লিঙ্কটি ভেঙে গেছে, @ বিলকারভিন।

— লাক্সারে

Answer 2

মাইএসকিউএল ৫.7 থেকে নিম্নলিখিতটি JSON এর সাথে সেক্সি ফিরে এনেছে আমার কাছে ভাল লাগছে:

মাইএসকিউলে জেএসএন ডেটা টাইপ ব্যবহার করা একটি পাঠ্য ক্ষেত্রে জেএসএন স্ট্রিংগুলি সঞ্চয় করার চেয়ে দুটি সুবিধা সহ আসে:

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

...

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

নথিটির বৈধতা সম্পর্কে ভাষাটি নোট করুন কারণ এটি একটি গুরুত্বপূর্ণ উপাদান। আমার ধারণা, দুটি পদ্ধতির তুলনার জন্য পরীক্ষাগুলির ব্যাটারি করা দরকার। এই দুটি সত্তা:

1. JSON ডেটাটাইপগুলি সহ MySQL
2. MySQL ছাড়া

নেট আমি এখন যা দেখছি তা থেকে মাইএসকিএল / জেএসএন / পারফরম্যান্সের বিষয়ে অগভীর স্লাইডশারগুলি রয়েছে।

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

Comments

এক কন; JSON ডেটা টাইপ মাইএসকিএল মেমরি টেবিলগুলি যেমন ডেটা প্রকারের মতো, টেক্সট এবং বিএলওবি সমর্থন করে না। এর অর্থ যদি অস্থায়ী টেবিলের প্রয়োজন হয় তবে এটি একটি ডিস্ক ভিত্তিক টেবিল তৈরি করবে যা মেমরি নয়। কিছু ক্ষেত্রে যখন অস্থায়ী টেবিলটি এখানে বর্ণিত হয়: dev.mysql.com/doc/refman/5.7/en/intern-temporary-tables.html

— রাইজ মিডিয়া

@ ইরাইজমিডিয়া আপনি কী দয়া করে ডিস্ক ভিত্তিক টেবিলটি মেমরি বনাম একটি সমস্যা কেন তা নির্ভর করে বলতে পারেন (ভিত্তিক টেবিলটি আমি অনুমান করি)?

— ল্যাপিন

@ ল্যাপিন সম্ভবত গতির সীমাবদ্ধতার কারণে।

— লিটল সহায়ক

@ লিটিলহেল্পার আপনি এটি এড়াতে পারবেন যদি আপনি পিসিআই 4x 40 জিবি / এস এম 2 স্লট ব্যবহার করেন এবং 40 জিবি / গুলি সমর্থিত ড্রাইভ .োকান। এটি স্মৃতি হিসাবে দ্রুত কাজ করে। আপনি অ্যালোস সেই ড্রাইভে একটি বিশেষ ফর্ম্যাট প্রয়োগ করতে পারেন যা স্মৃতি ফর্ম্যাট করতে ব্যবহৃত হয়।

— সের্গে রোমানভ

@ সের্গেইরোমনভ, [citation required]আপনি কি ড্রাইভ বনাম র‌্যাম বেঞ্চমার্ক করেছেন?

— বিল কারভিন

Answer 3

আমি সম্প্রতি এই সমস্যায় পড়েছি এবং আমি নিম্নলিখিত অভিজ্ঞতাগুলি সংক্ষিপ্ত করছি:

1, সমস্ত প্রশ্ন সমাধানের উপায় নেই। 2, আপনার JSON সঠিকভাবে ব্যবহার করা উচিত।

একটি কেস:

আমার নামযুক্ত একটি টেবিল রয়েছে: CustomFieldএবং এটিতে অবশ্যই দুটি কলাম: name, fields। nameস্থানীয়করণের স্ট্রিং, এটির সামগ্রীটি পছন্দ করতে পারে:

{
  "en":"this is English name",
  "zh":"this is Chinese name"
   ...(other languages)
}

এবং fieldsএই মত হওয়া উচিত:

[
  {
    "filed1":"value",
    "filed2":"value"
    ...
  },
  {
    "filed1":"value",
    "filed2":"value"
    ...
  }
  ...
]

আপনি দেখতে পাচ্ছেন, জেএসওএন হিসাবে nameএবং উভয়ই fieldsসংরক্ষণ করা যায়, এবং এটি কার্যকর হয়!

তবে, আমি যদি nameএই টেবিলটি খুব ঘন ঘন অনুসন্ধান করতে ব্যবহার করি তবে আমার কী করা উচিত? ... JSON_CONTAINS, ব্যবহার করবেন JSON_EXTRACT? একথাও ঠিক যে, এটি একটি ভাল ধারণা আর JSON হিসেবে চিহ্নিত করে সংরক্ষণ করুন না, তখন আমরা একটি স্বাধীন টেবিলে এটি সংরক্ষণ করা উচিত: CustomFieldName।

উপরের ঘটনাটি থেকে, আমি মনে করি আপনার এই ধারণাগুলি মাথায় রাখা উচিত:

1. MYSQL কেন JSON সমর্থন করে?
2. আপনি JSON ব্যবহার করতে চান কেন? আপনার ব্যবসার যুক্তি কি কেবল এটির দরকার ছিল? নাকি অন্য কিছু আছে?
3. কখনও অলস হবেন না

ধন্যবাদ

Comments

আপনি ভার্চুয়াল কলামটি ব্যবহার করতে আগ্রহী হতে পারেন। percona.com/blog/2016/03/07/…

— বেল

Answer 4

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

{ "name": "value" }

ধরা যাক আমাদের এটিকে এমন কিছুতে রূপান্তর করতে হবে:

{ "name": "value", "newName": "value" }

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

আমার কাছে 40 মিলিয়ন সারি টেবিল রয়েছে এবং পাইথন স্ক্রিপ্ট এটিকে 3-4 ঘন্টা আপডেট করে।

এখন আমাদের মাইএসকিএল জেএসএন রয়েছে, সুতরাং আমাদের আর পাইথন বা পিএইচপি দরকার নেই, আমরা এরকম কিছু করতে পারি:

UPDATE `JsonTable` SET `JsonColumn` = JSON_SET(`JsonColumn`, "newName", JSON_EXTRACT(`JsonColumn`, "name"))

এটি সহজ এবং দুর্দান্ত দেখায়। যাইহোক, এর গতি পাইথন সংস্করণের তুলনায় 10-20 গুণ বেশি ধীর এবং এটি একক লেনদেন, সুতরাং অন্যান্য অ্যাপ্লিকেশনগুলি সমান্তরালে টেবিলের ডেটা পরিবর্তন করতে পারে না।

সুতরাং, আমরা যদি 40 মিলিয়ন সারি টেবিলের মধ্যে কেবল JSON কীটি নকল করতে চাই তবে আমাদের 30-40 ঘন্টা সময় টেবিলটি ব্যবহার করা উচিত নয়। এর কোনও বোধ নেই।

মাধ্যমে, ডাটা পড়া তাদেরকে JSON মাঠে আমার অভিজ্ঞতা সরাসরি প্রবেশাধিকার সম্বন্ধে JSON_EXTRACTমধ্যে WHEREএছাড়াও extremelly ধীর (অনেক ধীর করে TEXTদিয়ে LIKEনা সূচীবদ্ধ কলাম তে) খুলুন। ভার্চুয়াল উত্পন্ন কলামগুলি আরও দ্রুত সঞ্চালিত হয়, তবে, আমরা যদি আমাদের ডেটা কাঠামো আগে জানতাম তবে আমাদের জেএসওএন লাগবে না, পরিবর্তে আমরা traditionalতিহ্যগত কলামগুলি ব্যবহার করতে পারি। যখন আমরা জেএসএন ব্যবহার করি যেখানে এটি সত্যই কার্যকর, যেমন যখন ডেটা স্ট্রাকচারটি অজানা থাকে বা প্রায়শই পরিবর্তিত হয় (উদাহরণস্বরূপ, কাস্টম প্লাগইন সেটিংস) কোনও সম্ভাব্য নতুন কলামের জন্য নিয়মিত ভিত্তিতে ভার্চুয়াল কলাম তৈরি করা ভাল ধারণার মতো লাগে না।

পাইথন এবং পিএইচপি জেমসকে বৈধতা হিসাবে আকর্ষণীয় করে তোলে, তাই এটি মাইএসকিউএল পক্ষের জেএসএন বৈধতা যা আমাদের প্রয়োজন তা প্রশ্নবিদ্ধ able এক্সএমএল, মাইক্রোসফ্ট অফিসের নথি বা বানান পরীক্ষা করে কেন বৈধতা দেয় না? ;)