ত্রুটি কোড 1117 অনেক বেশি কলাম; টেবিলে মাইএসকিউএল কলাম-সীমা

37

1699 কলাম সহ আমার একটি টেবিল রয়েছে এবং যখন আমি আরও কলামগুলি সন্নিবেশ করানোর চেষ্টা করি,

ত্রুটি কোড: 1117. অনেক বেশি কলাম

এই টেবিলটিতে আমার কাছে মাত্র 1000 সারি রয়েছে। আমার জন্য সবচেয়ে গুরুত্বপূর্ণ বিষয় হ'ল কলামের সংখ্যা of টেবিলে কি কোনও সীমাবদ্ধতা রয়েছে? আমি 2000 কলাম তৈরি করতে চাই। এটা কি সম্ভব?

mysql table

— OH LA LA
সূত্র

22

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

— জোরডাচি

12

আপনার মনিটরের 90 ডিগ্রি ঘোরান। আরও গুরুতরভাবে, মাইএসকিউএল (বা প্রায় কোনও আরডিবিএমএস) অনেকগুলি কলামের জন্য ডিজাইন করা হয়নি।

11

এবং কেন 2000 সেন্সরকে 2000 কলামে নিয়ে যাওয়া উচিত? আপনার ডাটাবেসটিকে নতুন করে ডিজাইন করুন। একটি পৃথক সেন্সর টেবিল বা কিছু তৈরি করুন, তবে প্রতিটি সেন্সরকে একটি নতুন কলাম হিসাবে যুক্ত করবেন না। এটি করা কেবল অবিশ্বাস্যরকম ভুল কাজ।

6

সর্বাধিক টেবিল নম্বর ... হু! আপনার সম্ভবত কয়েকটি টেবিলের প্রয়োজন হবে। এমনকি 2000 কলামের পরিবর্তে 2000 সারণী তৈরি করার বিষয়টি বিবেচনা করবেন না!

2

দয়া করে, দয়া করে, ডাটাবেস নরমালাইজেশন সম্পর্কে পড়ুন !

35

আপনি কেন 20 টি কলাম সহ একটি টেবিল তৈরি করতে হবে, 2000 ছেড়ে দিন ???

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

যদি 2000 কলামের টেবিলটি নির্বাচন করুন থেকে নির্বাচন করুন ... যেখানে, আপনি প্রসেসিংয়ের সময় বড় বড় টেম্প টেবিলগুলি তৈরি করতে পারবেন, কলামগুলি অপ্রয়োজনীয় আনতে এবং এমন অনেক পরিস্থিতিতে তৈরি করেছেন যেখানে যোগাযোগের প্যাকেটগুলি ( সর্বোচ্চ_নিযুক্ত_প্যাকেট ) প্রতিটি ক্যোয়ারের প্রান্তে চাপ দেওয়া হবে।

বিকাশকারী হিসাবে আমার আগের দিনগুলিতে আমি 1995 সালে ফিরে এমন একটি সংস্থায় কাজ করেছি যেখানে ডিবি 2 প্রধান আরডিবিএমএস ছিল। সংস্থার কাছে একটি একক সারণী ছিল যার ২0০ টি কলাম, কয়েক ডজন সূচি, এবং ডেটা পুনরুদ্ধারে পারফরম্যান্স সংক্রান্ত সমস্যা ছিল। তারা আইবিএম-এর সাথে যোগাযোগ করেছিলেন এবং পরামর্শদাতারা তাদের এক সিস্টেমের নকশাগুলি সহ এটির নকশাগুলিও দেখতে পারেন। সংস্থাকে বলা হয়েছিল "আপনি যদি পরবর্তী 2 বছরে এই টেবিলটি সাধারণ না করেন, স্টেজ 2 প্রসেসিংয়ের প্রশ্নগুলিতে ডিবি 2 ব্যর্থ হবে (অন-ইনডেক্সড কলামগুলিতে বাছাইয়ের প্রয়োজনীয় কোনও প্রশ্ন)"। এটি একটি বহু ট্রিলিয়ন ডলার সংস্থাকে বলা হয়েছিল, একটি 270 কলামের টেবিলটি স্বাভাবিক করুন। আরও কত তাই 2000 কলামের টেবিল।

মাইএসকিএলের ক্ষেত্রে, আপনাকে ডিবি 2 স্টেজ 2 প্রসেসিংয়ের সাথে তুলনীয় বিকল্পগুলি সেট করে এমন খারাপ নকশার ক্ষতিপূরণ দিতে হবে। এই ক্ষেত্রে, সেই বিকল্পগুলি হবে

কয়েক ডজন উপস্থিতি তৈরি করতে এই সেটিংসটিকে টিকিয়ে দেওয়া, কয়েকশ কলাম কলাম ছেড়ে দিন, যদি আপনার র‌্যামের টিবি থাকে।

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

উপসংহার

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

— RolandoMySQLDBA
সূত্র

1

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

— Gqqnbig

25

সঠিকভাবে সাধারণীকরণযোগ্য টেবিলটিতে ডেটা মডেল বৈধভাবে 2000 কলাম থাকতে পারে এমন কোনও কিছু কল্পনা করতে আমার সমস্যা হচ্ছে।

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

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

CREATE TABLE master (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields that really do relate to the
    master records on a 1-to-1 basis>
);

CREATE TABLE sensor_readings (
    id INT PRIMARY KEY AUTO_INCREMENT,
    master_id INT NOT NULL,   -- The id of the record in the
                              -- master table this field belongs to
    sensor_id INT NOT NULL,
    value VARCHAR(255)
);

CREATE TABLE sensors (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields relating to sensors>
);

তারপরে প্রদত্ত "মাস্টার" রেকর্ডের সাথে সংযুক্ত সমস্ত সেন্সর এন্ট্রি পেতে, আপনি ঠিক করতে পারেন SELECT sensor_id,value FROM sensor_readings WHERE master_id=<some master ID>। আপনার যদি masterসেই রেকর্ডের জন্য সেন্সরের সমস্ত ডেটা সহ টেবিলে একটি রেকর্ডের জন্য ডেটা পেতে প্রয়োজন হয় , আপনি একটি যোগদান ব্যবহার করতে পারেন:

SELECT master.*,sensor_readings.sensor_id,sensor_readings.value
FROM master INNER JOIN sensor_readings on master.id=sensor_readings.master_id
WHERE master.id=<some ID>

এবং তারপরে প্রতিটি সেন্সর কী তার বিশদ প্রয়োজন হলে আরও যোগদান করে।

— womble
সূত্র

18

এটি 2000 সেন্সর সহ একটি পরিমাপ সিস্টেম

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

যদিও আপনি মাইএসকিউএল হার্ড সীমাটিকে আঘাত করছেন না , লিঙ্কে উল্লিখিত অন্য কারণগুলির মধ্যে একটি সম্ভবত আপনাকে উচ্চতর হতে বাধা দিচ্ছে

অন্যরা যেমন পরামর্শ দেয়, আপনি শিশু সারণী রেখে id, sensor_id, sensor_valueবা আরও সহজভাবে এই সীমাবদ্ধতার আশেপাশে কাজ করতে পারেন , কেবলমাত্র কলামগুলি প্রথমটিতে উপযুক্ত হবে না তা রাখতে আপনি দ্বিতীয় সারণী তৈরি করতে পারেন (এবং একই পিকে ব্যবহার করুন)

— জ্যাক ডগলাস
সূত্র

1

এটা সত্য. ডেটা পরিচালনা এবং এসকিউএলকে দুর্দান্ত যত্ন সহকারে পরিচালনা করার সময়, আপনার উত্তরটি আরও বেশি দাঁড়িয়ে আছে !!!

— রোল্যান্ডোমাইএসকিউএলডিবিএ 16

3

চাইল্ড টেবিল ব্যবহার করা কোনও "কার্যনির্বাহী" নয়। প্রতিটি সেন্সরের জন্য একটি কলাম থাকা কেবল খারাপ (ভুল) নকশা। এটি এইচআর সিস্টেমে প্রতিটি কর্মচারীর জন্য একটি কলাম বা গাড়ীর মডেলগুলি পরিচালনা করে এমন কোনও ডিবির জন্য প্রতিটি গাড়ি প্রস্তুতকারকের জন্য একটি কলাম থাকার মতো।

— a_horse_with_no_name

11

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

— জ্যাক ডগলাস

2

@ জ্যাক ডগলাস: এমনকি যদি আপনার সমস্ত অনুমানগুলি সত্য হয়ে থাকে (যা আমি খুব সন্দেহ করি) প্রতিটি সেন্সরের মান নিজস্ব কলামে সংরক্ষণ করা দীর্ঘমেয়াদে সমস্যা সৃষ্টি করবে। "গতকাল এবং আজকের মধ্যে 10 থেকে 50 এবং 25 থেকে 100 এর মধ্যে সেন্সরগুলির গড় মূল্য কী" এর মতো প্রশ্নের কী? বা "গত সোমবার সেন্সরটির সর্বাধিক পঠনের মান ছিল?"। 2000 কলাম দিয়ে এর জন্য প্রশ্নগুলি লেখার চেষ্টা করুন। একটি সাধারণীকৃত টেবিল ব্যবহার করা 2000 কলামের সমাধানের চেয়ে দীর্ঘমেয়াদে আরও সমস্যার সমাধান করবে।

— a_horse_with_no_name

2

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

— জ্যাক ডগলাস

15

মাইএসকিউএল 5.0 কলাম-গণনা সীমা (জোর দেওয়া):

প্রতি টেবিলে 4096 কলামের হার্ড সীমা রয়েছে , তবে প্রদত্ত টেবিলের জন্য কার্যকর সর্বাধিক কম হতে পারে। সঠিক সীমাটি বিভিন্ন ইন্টারেক্টিভ ফ্যাক্টরের উপর নির্ভর করে।

প্রতিটি টেবিলের (স্টোরেজ ইঞ্জিন নির্বিশেষে) সর্বাধিক 65,535 বাইট সারি আকার থাকে। স্টোরেজ ইঞ্জিনগুলি কার্যকর সর্বাধিক সারি আকার হ্রাস করে, এই সীমাটিতে অতিরিক্ত বাধা রাখতে পারে।

সর্বাধিক সারি আকার কলামগুলির সংখ্যা (এবং সম্ভবত আকার) সীমাবদ্ধ করে কারণ সমস্ত কলামের মোট দৈর্ঘ্য এই আকারটি অতিক্রম করতে পারে না।

...

পৃথক স্টোরেজ ইঞ্জিনগুলি অতিরিক্ত সীমাবদ্ধতা আরোপ করতে পারে যা সারণী কলামের গণনা সীমাবদ্ধ করে। উদাহরণ:

InnoDB 1000 কলাম পর্যন্ত অনুমতি দেয়।

— lg_
সূত্র

7

প্রথমে আরও কিছু জ্বলজ্বল, তারপরে একটি আসল সমাধান ...

আমি ইতিমধ্যে আপনার উপর ফেলে দেওয়া শিখাগুলির সাথে বেশিরভাগ ক্ষেত্রে একমত।

আমি কী-মান স্বাভাবিককরণের সাথে একমত নই। অনুসন্ধানগুলি ভয়াবহ হতে শুরু করে; পারফরম্যান্স আরও খারাপ।

তাত্ক্ষণিক সমস্যা (কলামগুলির সংখ্যার সীমাবদ্ধতা) এড়ানোর একটি 'সহজ' উপায় হ'ল ডেটা উল্লম্বভাবে বিভাজন করা। বলুন, প্রতিটি 4০০ কলাম সহ 5 টি টেবিল। তাদের সকলের কাছে একই প্রাথমিক কী থাকবে, যদি এটির স্বতঃসংশ্লিষ্ট হওয়া না থাকে তবে except

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

আপনি কি কোনও মানকে সূচক দিচ্ছেন? আপনার কি তাদের অনুসন্ধান করার দরকার আছে? সম্ভবত আপনি ডেটটাইমে অনুসন্ধান করেন?

আপনার যদি প্রচুর কলাম-প্যান্টের সূচী করতে হয়।

আপনার যদি কয়েকটি সূচকের প্রয়োজন হয় - এগুলি 'প্রধান সারণীতে রাখুন।

এখানে আসল সমাধানটি (এটি যদি প্রয়োগ হয়) ...

আপনার যদি সেন্সরগুলির সূচকযুক্ত বিস্তৃত অ্যারের প্রয়োজন না হয়, তবে কলামগুলি তৈরি করবেন না! হ্যাঁ, আপনি আমার কথা শুনেছেন। পরিবর্তে, এগুলি JSON এ সংগ্রহ করুন, JSON কে সংক্ষেপ করুন, এটি একটি BLOB ক্ষেত্রে সংরক্ষণ করুন LO আপনি এক টন জায়গা বাঁচাতে পারবেন; আপনার কেবলমাত্র একটি টেবিল থাকবে, কলাম সীমাতে সমস্যা নেই; ইত্যাদি। আপনার অ্যাপ্লিকেশনটি সঙ্কোচিত করবে এবং তারপরে একটি কাঠামো হিসাবে JSON ব্যবহার করবে। কি অনুমান? আপনার কাঠামো থাকতে পারে - আপনার অ্যাপ্লিকেশনটি যেমন চান সেন্সরগুলিকে অ্যারে, মাল্টিলেভেল স্টাফ ইত্যাদিতে ভাগ করে নিতে পারেন। অন্য একটি 'বৈশিষ্ট্য' - এটি উন্মুক্ত is আপনি যদি আরও সেন্সর যুক্ত করেন তবে আপনার টেবিলটি বদলানোর দরকার নেই। JSON যদি সেভাবে নমনীয় হয়।

(সংকোচন alচ্ছিক; যদি আপনার ডেটাসেটটি বিশাল হয় তবে এটি ডিস্ক স্পেসে সহায়তা করবে, সুতরাং সামগ্রিক কর্মক্ষমতা)

— রিক জেমস
সূত্র

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

— BoB3K

@ BoB3K - আমার বৃহত্তর অনুচ্ছেদটি কী করা উচিত তা বলেছে , যেমন সমস্যার বিষয়ে উপলভ্য তথ্য হিসাবে বলা হয়েছে given JSON"অনেক বেশি কলাম" এড়ানো হয়; নির্বাচিত কলামগুলি সূচীকরণ কার্য সম্পাদনে সহায়তা করে।

— রিক জেমস

3

আমি এটি বড় ডেটার বিশ্বে একটি সম্ভাব্য দৃশ্য হিসাবে দেখছি, যেখানে আপনি traditionalতিহ্যবাহী সিলেক্ট * প্রকারের প্রশ্নের সন্ধান করছেন না। আমরা ভবিষ্যদ্বাণীপূর্ণ মডেলিং বিশ্বে একটি গ্রাহক স্তরে এটি মোকাবিলা করি যেখানে আমরা কয়েক হাজার মাত্রা জুড়ে গ্রাহককে মডেল করি (তাদের সকলেরই 0 বা 1 এর মান রয়েছে)। স্টোরেজ করার এই পদ্ধতিটি ডাউন স্ট্রিম মডেল বিল্ডিং কার্যক্রম ইত্যাদি সহজ করে তোলে যখন আপনার একই সারিতে ঝুঁকির কারণ এবং একই সারিতে ফলাফল পতাকা থাকে .. এটি পিতামাতার সন্তানের কাঠামোর সাথে স্টোরেজ স্ট্যান্ড পয়েন্ট থেকে সাধারণ করা যেতে পারে, তবে ভবিষ্যদ্বাণীপূর্ণ মডেল ডাউন স্ট্রিমটিকে এটিকে আবার ফ্ল্যাট স্কিমে রূপান্তর করতে হবে। আমরা রিডশিফ্ট ব্যবহার করি যা কলামার স্টোরেজ করে, তাই আপনার 1000+ কলামগুলি যখন আপনি ডেটা লোড করবেন তখন আসলে কলামার ফর্ম্যাটে সংরক্ষণ করা হবে ...

এই নকশার জন্য একটি সময় এবং জায়গা রয়েছে। একেবারে। সাধারণকরণ প্রতিটি সমস্যার সমাধান নয়।

— BigDataGuy
সূত্র

মন্তব্যের জন্য ধন্যবাদ. যদি কেউ চিত্র সহ বিশ্লেষণ করতে চান, এমনকি 16x16 পিক্সেলের একটি সামান্য রঙের চিত্রের জন্য 0 থেকে 255 এর মধ্যে 16 * 16 * 3 পূর্ণসংখ্যার প্রয়োজন হয় (আরজিবি রঙগুলি ব্যবহার করে 16x16 পিক্সেলের মধ্যে একটিতে বর্ণটি বর্ণনের জন্য 3 সংখ্যা)) এটি কেবলমাত্র ডেটার জন্য 768 কলাম, যাতে একটি কী যুক্ত করা দরকার।

— ভিক্টর জুরকোভস্কি