Лучший метод хранения базы данных

Я бы выбрал несколько таблиц, но не именованные таблицы, что-то более общее.

Например. столы

resume_section
id,name
1,personal details
2,education
3,work history

resume_section_attributes
id,resume_section_id,name
1,1,name
2,1,phone
3,1,email
4,2,school_name
5,2,grad_year
6,3,company_name
7,3,number_of_years

user_resume
id,user_id,resume_section_attribute_id,value
1,99,1,My Name
2,99,2,12345678

Теперь, когда вы хотите создать резюме пользователей, вы можете перейти прямо к таблице резюме пользователей и получить все их данные и присоединиться к таблице атрибутов для имен атрибутов и т. Д. Вы можете изменить порядок отображения атрибутов, легко добавить новые. Установите их по мере необходимости или нет. Установите ограничения на количество телефонных номеров или что-то в этом роде. Возможности для расширения безграничны.

Вариант 2 явно и однозначно неверен. Если вы не собираетесь разбивать свои данные на строки и столбцы и следовать по крайней мере первой паре правил нормализации данных, то нет причин использовать реляционную базу данных (вы можете использовать XML-документы в файле системные папки).

Вариант 1, наверное, самый правильный. В случае, если ожидается, что все элементы будут присутствовать во всех резюме, и никакие элементы не будут повторяться в резюме, тогда вы можете фактически иметь одну таблицу для всего резюме, с каждым полем в своем собственном столбце. Поскольку я не думаю, что эти условия соблюдены (например, история работы и образование, вероятно, должны быть повторяемыми элементами), тогда правильным выбором будет разделение таблиц на каждый элемент.

Определенно выберите вариант 1. Хороший дизайн базы данных жизненно важен, а хороший дизайн базы данных включает в себя нормализацию ваших данных, что возможно только в том случае, если вы моделируете отдельные объекты с их собственными таблицами.

Взгляните на эту статью о нормализации базы данных, в котором есть хорошее обсуждение задействованных концепций.