Реляционная база данных Путаница проектирования, есть ли лучший способ связать таблицы, то это?

Question

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

Идея заключается в том, что есть продавец услуг и покупатель обслуживания.

Продавец может предоставить более 1 услуги.

Покупатель может купить более 1 услуги (работа).

Задание может иметь более 1 продавца, работающего над ним.

Продавец может работать более чем на 1 работу.

Ниже представлен дизайн, который я придумал.

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

Так есть ли лучший способ связать эти таблицы вместе или это так, как это работает?

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

Answer 1

Ваш дизайн отлично подходит для реляционной базы данных.

Некоторые предложения по улучшению:

• Rename "services_provided_by_seller" в "сервис" просто. Предоставление продавцом определяется через таблицу продавцов. Не используйте множественную форму для имен.

• Вы можете удалить суффикс «_relationship», на мой взгляд, он не имеет никакой пользы.

• Вы можете упростить имена атрибутов внешнего ключа (FK): Поэтому в «seller_service» называть их «продавцом» и «службой» или «предоставленным_сервисом». В таблице рабочих мест достаточно «покупателя». Поскольку они являются внешними ключами (и декларативно отмечены как таковые в БД), это должен быть идентификатор (FK всегда ссылается на PK = первичный ключ).
  Назовите атрибуты FK, соответствующие роли, которую играет FK: например, в заказе стол может иметь три FK все одинаковые человек стол: заказчик, инвойс, получатель.

• Для таблиц отношения m: n (seller_services и seller_job) вы можете удалить суррогатный первичный ключ «id» - он не нужен с реляционной точки зрения - и использовать составной первичный ключ (id_seller + id_service, потому что каждый продавец может предложить услугу только один раз, я думаю).
  Но будьте осторожны, что некоторые структуры персистенции имеют плохую поддержку для такого первичного ключа.

Получение данных осуществляется с использованием SQL и соединений. Например, получить все услуги для покупателя («?"Является параметр):

select s.service_name 
    from service s 
    join seller_service ss on (ss.service = s.id) 
    join seller_job sj on (sj.seller = ss.seller) 
    join job j on (j.id = sj.job) 
where j.buyer = ? 
order by s.service_name 

Или просто с помощью WHERE-условие на сервис-объекте:.

select service_name 
    from service 
where id in (
    select ss.service 
     from seller_service ss 
     join seller_job sj on (sj.seller = ss.seller) 
     join job j on (j.id = sj.job) 
     where j.buyer = ?)