Разрабатываете схему базы данных для сайта со списком вакансий?

Question

Для школьного проекта я делаю простой сайт по списку вакансий в ASP.NET MVC (нам нужно выбрать фреймворк).

Я думал об этом некоторое время, и это моя первоначальная схема:

JobPostings
+ --- JobPostingID
+ --- Идентификатор_пользователь
+ --- Компания
+ --- JobTitle
+ --- JobTypeID
+ --- JobLocationID
+ --- Описание
+ --- HowToApply
+ --- CompanyURL
+ --- LogoURL

JobLocations
+ --- JobLocationID
+ --- Город
+ --- Государство
+ --- Zip

JobTypes
+ --- JobTypeID
+ --- JobTypeName

Примечание. Идентификатор пользователя будет связан с таблицей участников, созданной с помощью MembershipProvider.

Теперь, я крайне новичок в реляционных базах данных и SQL, так что не обращайте на меня внимание.

А как насчет имен? Должно ли это быть просто «Описание» в таблице JobPostings или «JobDescription» (то же самое с другими столбцами в этой основной таблице). Должно ли это быть "JobPostingID" или просто "ID"?

Общие советы также приветствуются.

Edit: JobTypes исправлены для нашего проекта, будет 15 категорий вакансий. Я сделал это вики-сообществом, чтобы люди могли оставлять посты.

Answer 1

Схема работы http://gfilter.net/junk/JobSchema.png

Я отделил Компанию от публикации вакансий, поскольку это облегчает ведение компаний.

Я также добавил таблицу XREF, которая может хранить отношения между компаниями и местоположениями. Вы можете настроить строку для каждого офиса компании, и у вас есть очень простой способ найти «Альтернативные места работы для этой компании».

Это должен быть веселый проект ... удачи.

РЕДАКТИРОВАТЬ: я бы добавил Created и LastModifiedBy (ссылаясь на идентификатор пользователя). Это отличные колонки для общего ведения хозяйства.

Answer 2

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

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

Answer 3

Несколько мыслей:

• Если вы априори не знаете, что список типов работ ограничен, не разбивайте его на отдельную таблицу;
• Просто используйте «ID» в качестве первичного ключа в каждой таблице (мы уже знаем, что это JobLocationID, потому что он находится в таблице JobLocations ...);
• Я бы удалил префикс 'Job' из полей в JobPostings, так как он немного избыточен.

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

Answer 4

Я бы рекомендовал свернуть данные, которые вы собираетесь хранить в JobLocations, в основную таблицу. Можно иметь таблицу для штатов и другую для стран, но я сомневаюсь, что вам нужна таблица, содержащая каждую пару город / штат / страна, вы действительно ничего не получите от нее. Что произойдет, если кто-то войдет и отредактирует свое местоположение? Вам нужно проверить, чтобы другие списки вакансий не указывали на местоположение и редактировали его, иначе создайте новое местоположение и укажите на него вместо этого.

Мой обычный шаблон - это адрес и город в виде текста с записью и FK в таблице состояний.

Answer 5

А как насчет имен? Должно ли это быть просто «Описание» под JobPostings таблица, или она должна быть JobDescription (то же самое с другими колонками в этом главном Таблица). Должно ли это быть "JobPostingID" или просто "удостоверение личности"?

Лично я задаю общие по звучанию поля, такие как "ID" и "Описание" с префиксами, как вы предлагаете. Это позволяет избежать путаницы в отношении того, к чему относится идентификатор / описание, когда вы пишете запросы позже (и избавляет вас от необходимости навязывать им псевдонимы).