Widening a Name Field for Hindi Results
St. Kabir Inter College is moving its Class 12 result register from paper to a single database file. The register has 1,500 students. Each record stores a roll number from 1 to 9999, a student name of up to 30 characters, marks in three subjects (0–100), and a section code (A–D). The existing data-entry form allocates 2 bytes for the roll number, 30 bytes for the name using ASCII, 1 byte per subject mark using 8-bit signed integers, and 1 byte for the section. A new government instruction says names must also be accepted in Hindi (Devanagari); the longest name in the pilot has 28 Devanagari characters. The programmer proposes simply widening the name field to 30 “characters” and keeping everything else unchanged. The clerk also uses the value -1 in a marks field to mean “absent”. The principal asks whether the proposed record design will actually work and how much storage it needs.
1. Explain why the 30-byte ASCII name field cannot store the Hindi names, calculate the space a 28-character Devanagari name needs in UTF-8, and recommend a practical field design.
Read the worked answer
ASCII defines only 128 code points (0–127). Devanagari letters occupy the Unicode range U+0900–U+097F, so no ASCII byte sequence can represent them; widening a single-byte field to 30 bytes does not help. UTF-8 encodes Devanagari characters in 3 bytes each, so 28 characters need 28 × 3 = 84 bytes. A fixed field of 90 bytes would cover 30 Devanagari characters (30 × 3 = 90) without truncation; a variable-length Unicode field such as NVARCHAR(30) in a Unicode database is also acceptable but must allow up to 90 bytes plus overhead. The key judgement is that “30 characters” is not the same as “30 bytes” once a multi-byte encoding is used. The database character set must be UTF-8/Unicode, and the form must be tested with a 28-character Hindi name before migration.
2. The clerk uses -1 as an “absent” sentinel in an 8-bit signed marks field. Evaluate whether this is correct: state the representable range, the two’s-complement form of -1, and one practical risk. Recommend a better design.
Read the worked answer
An 8-bit signed integer uses two’s complement and ranges from -128 to +127, so valid marks 0–100 fit comfortably. -1 is stored as 1111 1111, which is distinct from 0 (0000 0000), so the sentinel can technically be recognised. The risk is arithmetic contamination: if the program computes total = total + mark without first checking for -1, an absent student reduces the total by 1 and may still be counted in the average, producing a wrong result silently. It also cannot be distinguished from a data-entry error. A better design is to keep marks as 0–100 with a CHECK constraint and use a separate status column (for example, present/absent) or NULL for absent. If -1 is retained, every calculation must explicitly exclude it, and the value should be documented. The range itself is sufficient; the problem is the meaning attached to the value.
3. Calculate the old and revised record sizes and the total for 1,500 students if the name field is widened to 90 bytes. Also verify whether 2 bytes are enough for roll numbers 1–9999, showing the reasoning.
Read the worked answer
Old record: roll 2 + name 30 + three marks 3 + section 1 = 36 bytes. For 1,500 students: 36 × 1,500 = 54,000 bytes, about 52.7 KiB. Revised record with a 90-byte UTF-8 name field: 2 + 90 + 3 + 1 = 96 bytes. Total: 96 × 1,500 = 144,000 bytes, about 140.6 KiB. The increase is 90,000 bytes, entirely from the name field, which is small for a modern system. For the roll number, 2 bytes give 16 bits. Unsigned, the maximum is 2^16 − 1 = 65,535; signed, the maximum is 2^15 − 1 = 32,767. Both exceed 9,999, so 2 bytes are sufficient, although unsigned is the better semantic choice because roll numbers cannot be negative. The section code needs only 2 bits in principle, but 1 byte is a reasonable practical allocation.