На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! информация о разделе
user posted imageДанный раздел предназначается для обсуждения вопросов использования баз данных, за исключением составления запросов на SQL. Для этого выделен специальный раздел. Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ.

Модераторы: Chow, Bas, MIF, JoeUser
  
> Архитектура базы данных, прошу помощи))
    Добрый день! У меня в базе есть 3 таблицы:
    1-я таблица - users (таблица пользователей, предоставляющих определенные услуги);
    2-я таблица - categories (список категорий, каждый пользователь может выбрать категорию, под которую подходит его услуга);
    3-я таблица - prices (для каждой категории есть свой прайс-лист, по задумке каждый пункт прайс-листа будет выполнен в виде отдельного поля таблицы, т.к. каждый пользователь будет выставлять свою цену на услугу);

    Я пришел к выводу, что необходимо будет создать общую таблицу users_categories_prices, которая будет содержать следующие поля:
    - user_id;
    - category_id;
    - price_id;
    - cost (Стоимость услуги конкретного пользователя).

    Есть ли какой-нибудь более гибкий вариант решения задачи? Возможно ли связать 3 таблицы со связью "многие ко многим"?
      Выполните анализ предметной области. И сразу определится, что является сущностями, а что - их атрибутами, что с чем и как связано, какие бизнес-процессы происходят и т.п.
      Есть претензии ко мне как к модератору? читайте Правила, разделы 5 и 6, и действуйте соответственно.
      Есть претензии ко мне как к участнику? да ради бога.
      Не нравятся мои ответы? не читайте их.
      В общем, берегите себя. Нервные клетки не восстанавливаются.
        Akina ПОзволю добавить:
        И составьте модель Сущности-Связи...
          Цитата Лев @
          Есть ли какой-нибудь более гибкий вариант решения задачи?

          Чем характеризуем "гибкость"? И нужна ли "гибкость", или можно без нее? (см. Бритва Оккама)

          Цитата Лев @

          Возможно ли связать 3 таблицы со связью "многие ко многим"?


          Конечно возможно. Но вопрос - а надо ли?
          Скрытый текст
          (см. ответы Akina и Павла Калугина)
          Сообщение отредактировано: JoeUser -
          Мои программные ништякиhttps://majestio.info
            Цитата Лев @
            Есть ли какой-нибудь более гибкий вариант решения задачи? Возможно ли связать 3 таблицы со связью "многие ко многим"?

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

              price_id вещь сомнительная, и вообще смысл таблицы prices близок к нулю.
                Цитата p1qb0d @
                price_id вещь сомнительная, и вообще смысл таблицы prices близок к нулю.


                Цитата Лев @
                т.к. каждый пользователь будет выставлять свою цену на услугу

                Далеко не сомнительна.
                Цель - ничто , процесс - все.
                  Цитата Bas @
                  Цитата p1qb0d @
                  price_id вещь сомнительная, и вообще смысл таблицы prices близок к нулю.


                  Цитата Лев @
                  т.к. каждый пользователь будет выставлять свою цену на услугу

                  Далеко не сомнительна.


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

                  Вот указанная агрегирующая таблица - да, полезна, но в ней поле price_id является лишним полем.

                  Если планируется прикрутить какую-то мултивалюту, тогда да, самостоятельная таблица prices получит смысл, а price_id будет указывать на тип валюты - тогда это будет иметь смысл.

                  Но в постановке задачи это не озвучено. Так что пока price_id излишен.
                    Цитата p1qb0d @
                    Вот указанная агрегирующая таблица - да, полезна, но в ней поле price_id является лишним полем.

                    Ой ли лишним....
                    Цитата Лев @
                    1-я таблица - users (таблица пользователей, предоставляющих определенные услуги);2-я таблица - categories (список категорий, каждый пользователь может выбрать категорию, под которую подходит его услуга);3-я таблица - prices (для каждой категории есть свой прайс-лист, по задумке каждый пункт прайс-листа будет выполнен в виде отдельного поля таблицы, т.к. каждый пользователь будет выставлять свою цену на услугу);

                    ТО есть Исполнитель, услуга и прайс по услуге
                    остается их связать и получить прайс по пользователю по всем услугам, что и делает автор
                    Вот зачем он добавляет cost не понятно. Хотя в случае "спец предложений" это может пригодится. Но тогда разумнее вести в связи период актуальности (связь актуальна с .. .по ...)
                    А вообще описание предметной области и ER модель крайне упростили бы ответ на вопрос автора
                    1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
                    0 пользователей:


                    Рейтинг@Mail.ru
                    [ Script Execution time: 0,1111 ]   [ 15 queries used ]   [ Generated: 28.02.20, 07:44 GMT ]