2014-09-03 2 views
0

Я работаю над дизайном базы данных, где ищущие работу должны перечислить свой предыдущий опыт работы.Хранение объектов в mysql

Опыт работы является классом, который имеет:

  • Работодатель
  • Положения провела

Я хотел бы, чтобы смоделировать классы и показать связь между ищущим и их предыдущей работой опыт.

Я думал о создании таблицы для предыдущего опыта работы и ссылки на нее ищущему работу, но каждый ищущий работу может иметь несколько записей для работы, и это может стать беспорядочным.

Другой способ сделать это - сохранить весь опыт работы пользователей в виде списка в таблице рабочих мест.

Я не уверен, с кем идти и хотел бы, чтобы некоторые советы были приемлемыми, а какие нет. Любые другие альтернативы приветствуются и фактически запрашиваются. Спасибо

ответ

0

Я бы выбрал что-то вроде этой настройки.

Это будет держать всех пользователей прошлый опыт

CREATE TABLE `positions` (
    `position_id` int(11) NOT NULL AUTO_INCREMENT, 
    `position_name` varchar(50) DEFAULT NULL, 
    PRIMARY KEY (`position_id`) 
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=latin1 

Это будет держать пользователей персональных данных

CREATE TABLE `users` (
    `user_id` int(11) NOT NULL AUTO_INCREMENT, 
    `user_firstname` varchar(20) NOT NULL, 
    `user_lastname` varchar(20) DEFAULT NULL, 
    PRIMARY KEY (`user_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=latin1 

Это будет удерживать пользователей опыт работы - "средний" стол для positions и users.

CREATE TABLE `work_experience` (
    `seeker_id` int(11) NOT NULL AUTO_INCREMENT, 
    `seeker_position` int(11) NOT NULL, 
    `seeker_employer` varchar(20) NOT NULL, 
    `seeker_user` int(11) NOT NULL, 
    PRIMARY KEY (`seeker_id`), 
    KEY `positon_id` (`seeker_position`), 
    KEY `user_id` (`seeker_user`), 
    CONSTRAINT `user_id` FOREIGN KEY (`seeker_user`) REFERENCES `users` (`user_id`), 
    CONSTRAINT `positon_id` FOREIGN KEY (`seeker_position`) REFERENCES `positions` (`position_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=latin1 

Это будет функционировать как;

SELECT users.* FROM users; 
+---------+----------------+---------------+ 
| user_id | user_firstname | user_lastname | 
+---------+----------------+---------------+ 
|  1 | bob   | bob   | 
+---------+----------------+---------------+ 
1 row in set 

SELECT positions.* FROM positions; 
+-------------+-------------------+ 
| position_id | position_name  | 
+-------------+-------------------+ 
|   1 | stackoverflow guy | 
+-------------+-------------------+ 
1 row in set 

SELECT work_experience.* FROM work_experience; 
+-----------+-----------------+-----------------+-------------+ 
| seeker_id | seeker_position | seeker_employer | seeker_user | 
+-----------+-----------------+-----------------+-------------+ 
|   1 |    1 | StackExchange |   1 | 
+-----------+-----------------+-----------------+-------------+ 
1 row in set 

пользователя "1" (боб) имеет опыт работы в "StackExchange" быть "StackOverflow парень"

enter image description here

  • work_experience.seeker_user ссылки users.user_id
  • work_experience.seeker_position ссылки positions.position_id
+0

Мне нравится этот дизайн. Считаете ли вы, что это подходит, даже если позиции будут указаны пользователями самой системы? они не фиксированы. Также я хотел бы знать, добавляет ли пользователь другую позицию, как мы теперь добавляем это к его опыту. –

+0

Да. Причиной таблицы позиций является то, что вы не храните одни и те же данные дважды. Например, «Администрирование системы» и «Администратор Sys» одинаковы; но они заняли бы 2 записи. Я бы разрешил пользователям указывать позиции, но давал им список текущих сохраненных позиций, которые похожи на позицию, которую они пытаются и вводят. –

+0

Я вижу. Но скажите, что мы знаем, что каждый ищущий работу имеет уникальную возможность, мы теперь просто избавимся от таблицы позиций и положим позицию в поле work_experience, в сущности получим структуру, предложенную @ peter-m? –

0

Ваша оригинальная идея - это распространенный способ справиться с этой ситуацией «много-к-одному».

Используйте одну таблицу для хранения лиц, ищущих работу, другую, чтобы сохранить предыдущий опыт работы, причем каждая PWE имеет внешний ключ для лица, ищущего работу. (например, поле «jobseekerId».)

+0

чем ks для вашего ответа. Я также думаю, есть ли способ иметь всю историю работы ищущего работу в одной записи? Чтобы все предыдущие позиции были представлены в этой записи. Или это представление «один ко многим» - лучший способ сделать это? –

+0

Ну, вы можете как-то сериализовать (например,JSON) всю эту информацию в одно поле varchar в таблице jobseeker ... Но по существу таблицы базы данных представляют собой списки информации. Итак, все, что есть список (особенно список переменной длины), лучше всего подходит в своей таблице. Таким образом, вы можете решить свою проблему в обоих направлениях, но использование двух таблиц лучше соответствует структуре, которую предоставляют базы данных. –

Смежные вопросы