Форум MySQL

Вообщем задача такая.
Есть бд, есть данные, которые туда заношу, потом вытаскиваю.
Проблема состоит в том, что когда заношу, то не которые данные могут быть написаны по два раза.
Тоесть когда человек заполняет резюме, Высших образований может быть несколько.
Надо сделать так, чтобы 2-ое высшее образование было в новой строке в бд и id был такой же как и у первого высшего образования. Просто автоикремент подставляет ему новый id и при вытаскивании резюме на сайт, по id, получается, что 2-ое высшее образование сюда не подставиться.
Вот такая вот проблема, кто не особо понял, могу попробывать еще понятнее объяснить, с картинками :))

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

На одном сайте видел, при создании резюме, а именно при заполнении графы высшее образование, есть такая кнопочка сбоку, "добавить еще таблицу" и она сразу подставляеться, наверно на JS сделано, но каким образом заноситься в бд не понятно...
Может сделать те данные у которых возможны несколько вариантов (высшее образование, иностраные языки) по отдельной таблице им? Но опять же если отдельная таблица им, то id должен совпадать с id из главной таблицы, что при вынесении они вместе подставлялись.
Вообщем пока я не могу решить..

Естественно записи об образовании (если требуется представить подробности) поместить в отдельную таблицу.

>Но опять же если отдельная таблица им, то id должен совпадать с id из главной таблицы, что при вынесении они вместе подставлялись.

только не id . В смысле - не первичный ключ, а другое поле. Чужой ключ в таблице образований, полученный из первичного ключа в таблице соискателей.

Схема окажется нормализованной, и работать с ней будет легко и удобно.

Писать несколько значений через разделитель в одно поле, вытащив данные обрабатывать их как массив.

Первая нормальная форма

Понял, буду знать. Спасибо.

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

CREATE TABLE `applicants`  (    `app_id` INT(11) NOT NULL DEFAULT NULL AUTO_INCREMENT,    `app_name` VARCHAR(100),    `birthday` DATE,    PRIMARY KEY (`app_id`) ); INSERT INTO `applicants`   (`app_id`,`app_name`,`birthday`)  VALUES   (1, 'Вася Суриков',  '1848-01-24'),  (2, 'Петя Столыпин', '1862-04-02'),  (3, 'Коля Романов',  '1868-05-06'); CREATE TABLE `education`  (    `id_app` INT(11) NOT NULL,    `descr`  VARCHAR(255) NOT NULL ); INSERT INTO `education`   (`id_app`,`descr`)  VALUES   (1,'ЦПШ г.Красноярска, 2 класса'),                     (1,'уездное училище, 1 класс'),                        (2,'Виленская гимназия, классы 2-6'),                  (2,'Орловская гимназия, классы 7-8'),                  (2,'ФизМат Императорского Университета СПб'),          (3,'Гимназический курс, 8 лет'),                       (3,'Военное дело, Юриспруденция, Экономика, 5 лет ');

>В случае хранения в той де таблице отпадает вопрос трансацкии при удалении данных о человеке

DELETE applicants, education   FROM applicants a      LEFT JOIN education e ON e.id_app = a.app_id   WHERE app_name LIKE 'Коля%'

Сколько здесь запросов?


>и уменьшается количество запросов к базе при выборке.

SELECT *    FROM applicants a      LEFT JOIN education e ON e.id_app = a.app_id

а здесь?

SELECT a.app_name, GROUP_CONCAT(e.descr SEPARATOR '; ')    FROM applicants a      LEFT JOIN education e ON e.id_app = a.app_id   GROUP BY a.app_id

а здесь?

ваши аргументы, как всегда, бесспорны. Но я писал "как мне кажется", "В некоторых случаях"... В данном случае запросы упростились бы, если бы данные были в 1 таблице. Но я не стану настаивать, что хранение в 1 таблице и упрощение запроса дает экономию больше, чем потеря при необходимом разделении данных средствами ПХП. Думаю, при различных данных скорость и объем (в памяти, на диске), могут быть различны. Приверно, как preg_math и ereg. preg_math обычно работает раза в 2 быстрее. Но если в тексте нет искомого, ereg оказывается быстрее в несколько раз (это результат ряда тестов, возможно в другой ситуации результат был бы иной).

Не перестаю поражатся изящности кода... Прям, как из учебника... Ну, ничего, будет и у меня столько опыта ;)